Skip to content

ADR 0067: each task chooses its model - #1239

Open
Maya-Kid wants to merge 1 commit into
deeplethe:devfrom
Maya-Kid:fix/adr-each-task-chooses-its-model
Open

Maya-Kid wants to merge 1 commit into
deeplethe:devfrom
Maya-Kid:fix/adr-each-task-chooses-its-model

Conversation

@Maya-Kid

Copy link
Copy Markdown
Contributor

The record #470 asked for before any code: the six tasks and the fallback chain.

Why

Cut 1 of #470 was accepted on 2026-10-04 with "A short ADR first (the next free number is 0067) with the task list and the fallback chain, then the code." 0067 was held for #470 on #1130. #1213, which also wrote 0067, is moving to another number.

What changes

  • docs/decisions/0067-each-task-chooses-its-model.md covers:
    • the problem and what a profile holds;
    • the six tasks, with the calls each one covers;
    • the chain that model_for(kb, task) follows, and model_for as the only way to a model;
    • the migration, in two sentences;
    • the cuts, what was not chosen, and three open questions.
  • The index row under chat-and-mcp, with status Proposed.

No code, schema or behaviour changes. The two code PRs of cut 1 follow:

  1. every call site goes through model_for, still reading today's row;
  2. the profiles and the migration.

Open questions in the record

  • Where profiles live. One model does every job in every base #470 says the deployment level, but each workspace has its own row and keys today.
  • implication::read_phrases. Does it go under alignment?
  • A base's unset tasks in cut 2. Do they follow the defaults, or does a base's own chat override cover them?

Signed-off-by: dada-yan <BinjunYann@gmail.com>

@WaylandYang WaylandYang left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you, this records what we agreed on #470 and the chain is clear. embedding never falling back to chat, and a set-but-not-ready link ending the search, are both right: data should never reach an endpoint nobody chose for that task.

Answers to the open questions:

  • Profiles stay per workspace. Keys and admins are per workspace today, and a deployment-level profile would let one workspace's data go to another's endpoint.
  • implication::read_phrases goes under alignment.
  • A base's unset tasks follow the task defaults, as #470 writes it.

Please fold those into the decisions. Two small additions while you're there: in decision 5, say that chat_reasoning_effort moves onto the migrated chat profile and what happens to embed_dim; in decision 4, note the one exception, the connection test, which builds a client from the profile being edited. Then the status can be Accepted and I'll merge it.

@WaylandYang

Copy link
Copy Markdown
Contributor

Still waiting on the changes from the 2026-10-19 review: fold the three open-question answers into the decisions, add chat_reasoning_effort and embed_dim to decision 5 (an embedding profile needs its dimension, 0035), note the connection-test exception in decision 4, then mark the record Accepted here and in the README index. The numbering is fine: 0067 is reserved for #470, 0068 is #1222, 0072 is #1213. No commits since 2026-10-15.

@WaylandYang

Copy link
Copy Markdown
Contributor

Friendly ping on the 2026-10-19 review: the record still has the three open questions that were answered (per-workspace profiles, read_phrases under alignment, unset base tasks follow the defaults), decision 5 needs chat_reasoning_effort and embed_dim (0035), and decision 4 the connection-test exception. With those folded in and the status set to Accepted in the record and the index, this can merge. 0067 is still free; if you can't get to it this week, say so and we'll make the edits on the branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants