The right resource for each step. Proof that it was.

No single model wins every task, and most steps in an agentic coding job don’t need the most expensive one. The Router will run each step of a task on the cheapest resource that holds quality: your local models for the routine work, a frontier model on your key when it earns its price. What it chose, and why, will be on the Waybill either way.

Planned — not in the Stage A build.

What you control

Five policies. Pick one globally, or per project in the policy file.

  • Balanced (default). Cost and quality both count. Most tasks stay local; the ones that need a frontier model get one.
  • Cheapest. Minimizes spend inside the acceptance floors. The floors still hold, which is what makes this different from simply routing everything local.
  • Best Quality. Skips cost optimization entirely; when the stakes are high, you shouldn’t have to wonder.
  • Fastest. Optimizes for wall-clock time. On a busy local runtime that will sometimes mean a frontier call, and the Waybill will say so.
  • Local Only. Never leaves the machine, and the ledger shows what that choice costs in escalations forgone.

Settings live in a plain policy file — routing mode, protected paths, budget caps — at user scope and in the repository, so a team’s routing posture is reviewable in a pull request like code. The dashboard edits the file; the file is the truth.

Floors, not vibes

Every task class carries an acceptance floor. When locally routed work on a class slips below it, that class de-routes to stronger models automatically, and you see a notice saying so. No silent downgrades in either direction. If you’ve watched a cost optimizer slowly get worse while its dashboard stayed green, this section is for you.

Chart: task-class acceptance running above a dashed acceptance floor; one dip crosses the floor and is marked de-routed to stronger models in violet. A route change is not an error.
Chart: task-class acceptance running above a dashed acceptance floor; one dip crosses the floor and is marked de-routed to stronger models in violet. A route change is not an error.

Acceptance against the floor, and one de-route. Illustrative.

Escalation on evidence

The router escalates when verification fails or confidence is low, and the Waybill records why. You can read the reason on every task that cost money: which check failed, what got retried, where the frontier call happened.

waybill #4127

WAYBILL #4127 — "add org column migration"       (illustrative)

plan local $0.00 ok
implement local $0.00 tests: 2 failed
diagnose local $0.00 retry
implement #2 frontier $0.19 tests: 23 passed
review you — accepted

Method: an illustrative Waybill, not a measurement. Per-leg prices are whatever your provider charged, read at the time of the call and recorded with the row.

A model that stops answering is a routing problem, not your problem

Local runtimes fall over. Providers rate-limit. Endpoints go quiet mid-task. When a route stops answering, Haybox retries it, then takes it out of the running for a cooldown period, then fails over to the next route in the chain — and the Waybill says that is what happened, so a task that cost more than usual has a reason next to it rather than a shrug. A route sidelined by cooldown reads as sidelined, not as absent.

Questions

Can I force a specific model?

Yes: per task in the agent, or by policy.

Can I cap frontier spend?

Yes: budget caps with alerts and a hard stop, set in the policy file.

What decides “cheapest that holds quality”?

Measured outcomes per task class, updated by the routing service. The floors section above covers the guarantee; the benchmarks page covers the measurements.

Shadow Mode · Ledger · Benchmarks methodology · All features

See what your own traffic says.

Shadow Mode reports on the traffic you already have. Before that exists for you, the calculator will estimate it from your GPU and your monthly spend, and show you every assumption it used to get there.