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.
The product drives more than one kind of actor: vendor agent backends, models behind an endpoint you run yourself, and ordinary deterministic tooling. That plurality is usually described as flexibility. It is more useful than that. It is a measuring instrument, and the reason is that the yardstick does not move when the actor does.
The same work, two actors, one standard of proof
Prices differ per vendor and per model. The standard the result is held to does not: the same test suite and the same human gates judge every return, whoever produced it, and both costs are booked to the cent in the same column.
⇒ So "which actor should do this class of work" stops being a matter of taste and becomes an experiment you can actually run: give the same order to two actors, put both returns through the same gates, and read both rows.
⚠ The result of that experiment is almost never "use the cheaper one". What it produces is more valuable and less obvious: a known price for a known difference, per class of work. A more expensive actor that reliably produces a better plan is worth its premium at some sizes of work and not at others — and once the premium is a figure rather than a reputation, that judgement can be made by whoever holds the budget, and revisited when prices change.
The floor of the ladder is aggressively cheap
Whole classes of work are mechanical: formatting, validation, checking that documents are well formed, running a build and a test suite. Those run as deterministic acts at zero, and they are recorded rather than merely omitted — so the share of the work that never touched a model is visible in the account.
⇒ No per-token discount competes with a class of work that makes no model call at all. This is the reason "deterministic first" is a design rule and not a cost-saving tip: no model call where ordinary code suffices. Every class of engine work states its tier, and defaulting to the strongest available model is treated as a design error rather than a safe choice.
What keeps the comparison honest
Two guarantees do the load-bearing work here, and without them every per-model figure in the books would be unreliable:
| Guarantee | What it prevents |
|---|---|
| No silent substitution | The booked model is the model that ran. A dispatch refuses to compose a fallback-model option at all, so nobody gets a different model than the one they named — and a per-model cost report stays meaningful. |
| No silent resumption | A dispatch refuses to quietly continue a previous session. The run you predicted is the run you get, rather than a continuation carrying an unknown amount of prior context — and context size is one of the largest inputs to what a run costs. |
⛔ Both are refusals, not warnings. A system that substitutes a model and books the substitution honestly is still a system whose comparisons are worthless, because the experiment above would no longer be comparing what it claims to compare.
Why this matters more over time
Model prices move, new models arrive, and the ratio between "cheapest" and "most capable" changes several times a year. An organisation whose routing choices are habits has to re-litigate them by argument each time. An organisation whose routing choices are recorded prices against recorded outcomes re-runs a measurement instead.
Next
- Matching the model to the task — the ladder, and what earns each rung.
- The dimensions of cost — per model and per vendor, alongside the other axes.
Before a dollar is spent
Capacity checks, usage windows, the refusals that happen before a run spawns, and an honest statement of which ceiling is enforced by whom.
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.