Pick one model for your whole organisation and you have chosen how to waste money. Choose the strong one and you pay top rates to bump a dependency. Choose the cheap one and a cross-repo refactor fails three times before someone escalates it by hand — which costs more than starting high would have.
The unit that should decide the model is the task, not the account.
Rules first, because they can be explained
Before a run starts we already know several useful things: what kind of task it is, the size estimate from grooming, how many repositories are in play, and whether a bug report arrived with a stack trace. That is enough for a baseline.
A chore stays on the cheapest tier until it is large. A feature starts mid-tier and moves up with size. A refactor jumps a tier earlier than a feature of the same size, because a refactor that goes wrong is expensive in review time even when the model was cheap. Work spanning more than one repository escalates. And a bug that arrived with a stack trace goes down a tier at small sizes — the hard part of a bug is locating it, and the stack trace already did that.
Then a correction, per project
Rules are a starting point, not the truth about your codebase. So per project, per combination of task type and size, we count how often each model got it right first time — meaning the run finished with no iteration, because an iteration costs a whole extra run and that is the thing worth optimising.
A bucket needs ten runs before it is allowed to override a rule; below that the sample says nothing. Past that, a model landing under half its runs first-time-right in that bucket gets escalated, and one clearing ninety per cent on the tier below gets demoted to the cheaper option. Thresholds deliberately far apart, so a project does not oscillate between tiers on noise.
The ladder is ordered cheapest to strongest and the router only ever steps along it. "Escalate" and "demote" therefore have exact meanings and cannot land on some unrelated model because a rule was written badly.
Every choice comes with a reason
Each run records why its model was chosen. This is not a nicety. A router that cannot explain why a run cost what it did is one nobody will trust with the budget, and the first surprising invoice ends with it being switched off.
Failure escalation is recorded too: a run that failed on a cheaper model is retried one tier up, and that outcome feeds the next similar task so it starts where it should have.
A limit that actually stops
Routing controls the rate of spend. It does not bound it, and per-token pricing with no ceiling is how people end up afraid of their own tools.
So spend draws from prepaid credit, and at zero new runs are refused outright rather than throttled or queued. Runs already in flight are allowed to finish — killing one at ninety per cent discards work you have already paid for, which is worse than the small overshoot of letting it land.
Bring your own model key and none of this applies: the spend is between you and the provider, and charging you for it would be billing twice.
One scope note, since it would be easy to overclaim. Everything above describes routing across the Claude tiers. A run can also be dispatched to Grok or the OpenAI Codex CLI, and those use the single model you configure for them rather than being routed per task. The prepaid ceiling still applies regardless of which agent ran.