Assignment, not ambition

One plan, several models: choosing an executor per task

Most coding agent setups pick one model when the session opens and then live with it. An auth refactor where a wrong line is expensive, a README update, a fixture rename and a config migration all run on that same choice, at the same thinking effort, with the same permission mode, 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 it before the work runs. If it does not, you are still making the choice, you are just making it invisibly.

Where the choice usually lives

Model selection is a decision, and in most setups it is made in one of three places, none of them reviewable.

In the prompt. You type "keep it cheap for the boring parts" into a message. That 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, which means you find out what it chose after the fact, if you find out at all.

In a relaunch. You close the session, start another one with a different model, and re-explain the work. The explanation is now the expensive part, and you have paid it twice.

The alternative is to make the assignment an item in an artifact. That is what a plan first setup buys: the work is decomposed before it executes, and each task carries its executor as data.

What a task carries

In Ordewell the plan is an ordered list of tasks, and every task names four things, plus its dependencies:

The planner assigns all four across the whole plan, shows you every assignment before anything runs, and each one is a line you can change. Completed work survives the edits, and nothing runs until you say go.

The commands

Assigning is four subcommands, one per field, and there is a TUI picker of the same name for each of them. Omit the value and you get the options instead of a change.

bash
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 page that will be stale the moment a provider ships something. The listing looks like this:

ordewell task-model 4
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 deliberately coarser than changing the model. When you set a runner, its model, effort and mode are re-derived from that runner's catalog, because a model that the new runner cannot spawn is not a useful thing to persist:

ordewell task-runner 2 opencode
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.

First, a model is validated against the task's runner, not against the global catalog. Set something the runner does not serve and you get told, rather than a task that dies at spawn time.

Second, 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 instead of leaving you to guess:

effort falling back
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 only: nothing has executed yet. Once a session is running, correcting the executor means losing the context you built, and 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 can 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. A coding agent you already pay for can be the planner, strictly read-only, so the plan can be written by the same subscription that will execute it. More than twenty providers are also recognised through their own *_API_KEY variables if you would rather plan that way.

What this does not fix

The whole loop

Install, plan, adjust the assignments, run. Nothing executes until the last line.

bash
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

Whole plan visible on one screen in the TUI, every task showing its runner, model, effort and mode. If you mostly want five agents on five independent things at once, that is a different tool and this page explains when fan out wins. If you want the verdict side too, how a task gets proven done is the other half.