Matching the model to the task
Model choice is an economic decision, so the product refuses to make it for you. The ladder of actors, what earns each rung, and how predictions get calibrated from your own record.
Start with the stance, because it frames everything else: the model is an explicit input of every dispatch.
--modelis required for every model-driven backend. It is never taken from a session default.- The vendor option that lets a request silently fall back to a different model is forbidden on a composed command.
- A written order's stated model is read verbatim. ⛔ A missing one composes nothing — it does not compose a default.
⇒ There is no path through this product that picks a model on your behalf. That is deliberate, and it is a cost decision rather than a purist one: model choice is the single most consequential price input in the system, and a price input that gets set by a default is a price nobody chose.
The ladder
Four rungs, and the vocabulary is closed — there is no fifth tier that arrives without being declared. Every rung lands in the same ledger and passes the same gates.
| Rung | What it costs |
|---|---|
| Deterministic acts | Zero. Ordinary code, no model call |
| A model you host yourself | Electricity, and the host's time |
| A flat-rate account | Nothing marginal inside the plan's window |
| A metered API | Per token, from the first token |
Placement by measured capability, then by price
When machine selection is left automatic, candidates are filtered before they are ranked:
- Filtered by proven capability. Confirmed by a probe at minimum. ⛔ A declared claim never wins work — a machine that says it can do something and has never demonstrated it is not a candidate.
- Then ranked by capability rung, then by free slots, then by declared price per hour.
⇒ The cheapest capable candidate wins the placement. The order of those two steps is the whole design: price is a tie-breaker among candidates that have already proven they can do the work, never a reason to send work somewhere it will fail.
Predictions calibrated from your own record
A prediction for a class of work is derived from the highest measured actual for that class, rounded up. ⛔ Never from a published list price — a list price predicts what a token costs, not what your work of this shape costs.
A class nobody has measured yet borrows the most conservative row in the table, and the borrowing is stamped on the record, so a stand-in figure can never later be mistaken for a measurement. Every prediction-and-actual pair feeds back into the same table, which is how a tier choice gets re-priced by a human reading real pairs rather than re-argued.
What earns each rung
⚠ A starting point, not a rule the product enforces. Nothing here is checked by the engine; the tier is your decision, and this table is the shape that decision usually takes.
| Class of work | Tier that earns it | Why |
|---|---|---|
| Formatting, linting, document validation, running the build and the tests | Deterministic | The answer is computable. A model adds cost and adds a surface that can be talked out of the right answer — and asking for one here is refused outright |
| Repetitive, tightly scoped code generation; single-file test authoring behind a deterministic check | A model you host yourself | The check, not the author, carries correctness — so the cheapest author that passes it wins. Isolating the test author from the implementation plan is a quality property as much as a saving |
| Ordinary implementation work with a clear order | A flat-rate account, mid-tier model | Flat-rate capacity absorbs the bulk of the volume, and the order's test plan plus an independent review hold the quality regardless of who authored it |
| Planning, adjudication, adversarial review of a non-trivial return | The strongest reasoning tier available | A flawed plan rejected at the plan gate costs a plan. The same flaw found downstream costs an implementation run, a review round and a re-dispatch |
| Long-form prose: documentation, briefs, narrative records | The strongest family available, by explicit decision | Prose is the deliverable rather than a means to one, so the cheapest-capable rule yields to a stated decision |
Three disciplines that keep the table honest
Escalation is an act, not an automatism. Nothing silently retries on a stronger model — substitution is refused by construction. When work fails on a cheaper tier, re-dispatching it on a stronger one is a new recorded decision with a new prediction, and the failed attempt stays on the books as the measured price of finding where the tier boundary is. Over time those boundaries stop being guesses. ⚠ The corollary is worth stating for a budget holder: a cheap tier that fails is not free, so "try the cheap one first" is itself a priced bet, not an obviously safe default.
Drift diagnoses the tier. When a run comes in near or over its ceiling, the record distinguishes which of three things was actually wrong, because each has a different remedy:
| What was wrong | The remedy |
|---|---|
| The multiplier was too tight for a prediction that was itself well calibrated | Fix the rule that derives the ceiling |
| The prediction was wrong by a whole class of work | Fix the table the predictions come from |
| The prediction was wrong for this run while the ceiling held fine | Re-price this class |
A routing claim is refutable. A tier assignment is a standing claim that this rung is the cheapest capable one for this class of work. It is held to the same standard as any other claim in the record: a measurement that contradicts it wins, and re-pricing is the expected outcome rather than an embarrassment.
Next
- Cheap by planning — the lever that moves the total more than any of the above.
- Worked examples — the commands, in the order the money moves.
One yardstick across many vendors
Running several backends is a cost instrument, not a preference — because the same order can be given to two actors and judged by the same tests.
Cheap by planning: the biggest lever
The largest cost control in agent development is not the model price list. It is where in the process a defect gets discovered, and the method is arranged around that.