Every coding agent setup I have watched, including mine, picks one model when the session opens and then lives with it. An auth refactor where a wrong line is expensive, a README update, a fixture rename, a config migration. Same model, same thinking effort, same permission mode for all four, because they happened to land in the same project.
Disclosure: I build Ordewell, and assigning an executor per task is something it does. The feature is not the interesting part. The interesting part is that the choice has to live somewhere you can read before the work runs. If it does not, you are still making the choice, just invisibly.
Where the choice usually lives
Three places, none of them reviewable.
In the prompt. "Keep it cheap for the boring parts" is a sentence about a decision, not the decision. Nothing downstream can read it, and it decays as the conversation grows.
In a coordinator's head. When one agent supervises others, the assignment gets made inside a model's reasoning. You find out what it chose after the fact, if at all.
In a relaunch. Close the session, start another one with a different model, re-explain the work. The explanation is now the expensive part, and you paid it twice.
What a task carries in a plan
In Ordewell the plan is an ordered list of tasks, and every task names four things plus its dependencies.
The runner: Claude Code, Codex or OpenCode, mixed freely inside one plan. Anything else is a plugin manifest rather than a code change. The model that runner will spawn for this task, validated against what that runner can actually serve. The thinking effort the model exposes, when it exposes one. The mode, the runner's permission posture for this task.
A separate read-only planner assigns all four across the whole plan and shows every assignment before anything runs. Each one is a line you can change. Completed work survives the edits, and nothing runs until you say go.
The commands
Four subcommands, one per field, and a TUI picker of the same name for each. Omit the value and you get the options instead of a change.
ordewell plan --goal "Add rate limiting to the public API"
# read the plan, then retarget individual tasks before running
ordewell task-runner 2 opencode
ordewell task-model 4
ordewell task-effort 4 high
ordewell task-deps 4 1,2
ordewell task-model 4 with no value prints the models discovered for that task's runner, with the current one starred, so you are choosing from a real catalog rather than a list I typed into a post:
Model · #4 Constrain the limiter to the public route (claude-code)
* <model-id>
<label> (<provider>, 5 effort levels)
<model-id>
<label> (<provider>, runner default effort)
Changing the runner is coarser on purpose. Setting a runner re-derives its model, effort and mode from that runner's catalog, because persisting a model the new runner cannot spawn is not useful:
Task #2 runner set to opencode. Its model, effort and mode were re-picked for it.
Two behaviours are worth knowing before you hit them.
A model is validated against the task's runner, not against the global catalog. Set something the runner does not serve and you are told, instead of getting a task that dies at spawn time.
Effort levels do not survive every model change. Some models expose five levels and some expose none, so switching can quietly drop the effort you set. It says so on the same line:
Task #5 model set to <label>.
<label> does not expose "high", so the effort went back to the runner default.
Why the assignment has to happen before, not during
Editing a plan is cheap for one reason: nothing has executed yet. Once a session is running, correcting the executor means losing the context you built. Once files are written, correcting the decomposition means undoing work instead of rewriting a line.
There is a second effect that matters more than the first. A plan you can read is a plan you can disagree with. When the assignment is visible per task, you see the pattern the planner chose, and you overrule the parts you know better than it does, because you know which two of these twelve tasks are load bearing.
Planning needs no API key either. A coding agent you already pay for can be the planner, strictly read-only, so the same subscription writes the plan and then executes it.
What this does not fix
The choice is judgement, not measurement. There is no published benchmark behind my opinion that one model suits one task, and I am not going to invent a number for you. Per task assignment hands you the decision. It does not make the decision right.
A good assignment does not rescue a bad plan. If the decomposition is wrong, retargeting executors is polishing the wrong artifact.
Effort is not portable. As above, moving between models can drop a level you set.
A cold catalog gives you nothing to choose from. If a runner has not been discovered yet, the model listing comes back empty, and ordewell refresh is the fix.
Manual tasks have no executor at all. A step for you to do by hand carries no runner, and that is deliberate.
Ordered execution means fewer concurrent sessions than a fan out board: three by default, five at most.
The whole loop
npm install -g ordewell
AI_PROVIDER=claude-code ordewell plan --goal "Migrate the config loader from JSON to TOML"
ordewell task-model 3
ordewell task-runner 5 codex
ordewell task-effort 5 high
ordewell task-deps 5 1,2
ordewell run
Free and Apache-2.0, no paid tier, source at github.com/ordewell/ordewell. If you mostly want five agents on five independent things at once, that is a different tool, and I wrote the comparison rather than pretending otherwise.
Top comments (0)