Cutting model cost on routine work
Pay frontier prices for the decisions, not for the summaries
Move the routine turns of an agent workflow onto the cheapest models that can do them, and keep the expensive ones where being wrong is expensive — with a recorded reason for every route decision.
What actually goes wrong today
Stated plainly, because the approach below only makes sense as an answer to something specific.
- 01
Most of what an agent does in a day is classification, extraction, summarisation and routing. Every one of those is a small model job, and every one of them is routinely billed at a frontier price because the workflow has one model configured.
- 02
The reverse mistake costs more: downgrading the architecture decision to save four cents produces a confident wrong plan, and then every implementation turn built on it is wasted.
- 03
Cost intuition is unreliable. Without per-turn prices attached to the turn, "this run was expensive" is a feeling rather than a number, and there is nothing to argue with.
- 04
Prices go stale. If a price or a tier were baked into the program, correcting it would mean a code change and a redeploy — which is why nobody corrects it.
How the hierarchy and the router do it
Concretely, stage by stage: which mode the stage uses, who owns it, and why the router prices it the way it does.
- 01
Every role declares a ModelPolicy: a default tier, per-task-class overrides, hard minimum and maximum bounds, and an escalation threshold. The router cannot exceed the band, so a role cannot be talked into a frontier call by a clever prompt.
- 02
The installation posture is one control — cheap, balanced or quality — and switching it changes the whole office on the next turn. Cheap is a posture rather than a rewrite.
- 03
Complexity is estimated deterministically from observable things: the stage kind, how much text the turn must digest, whether it touches files, how many revision passes have already failed, and whether the brief names a known-hard problem. The estimate only has to be ordered correctly, and it says so.
- 04
Routing rules contributed by a plugin reorder the candidates the router already considers, scoped by task class. A rule is a preference, never an override, so a scoped rule for intake cannot touch the plan stage.
- 05
Models and their per-million prices are overridable in Settings → Models, and the registry reads the overrides on every use, so a correction changes routing and cost reporting on the next turn instead of at the next deploy.
- 06
Providers with no key are catalogued so the UI can show them, but excluded from the routing pool in live mode — a missing key cannot silently send every turn into a guaranteed failure.
What you actually end up with
Artifacts, not assurances. Every one of these is something you can open, diff, review or throw away.
A spend figure that is attributable per turn, with the router recording the reasoning for the models it rejected, so the cost conversation is about specific decisions.
Routine turns priced at the cheap tier while planning and review keep the stronger models, because the band is a policy rather than a habit.
Corrections that ship immediately: a stale price is a settings write, not a release.
Which part of the company is involved
Six of the thirteen roles, four of the eight departments. The rest of the office stays idle, and that is what keeps the run affordable.
Stays on a nano-tier model in every posture, because there is nothing to save by upgrading the cheapest call in the run.
The band is a policy the prompt cannot override: a minimum, a maximum, an escalation threshold and per-task-class overrides.
Switches the installation posture, or corrects a tier and a price in Settings → Models, which takes effect on the next turn.
A routing rule reorders candidates inside one task class. It is a preference and never an override, so it cannot force a model that cannot do the job.
Modes used
Intake runs single, research runs parallel, contested decisions run as a debate, and anything that produces files ends in a review-loop.
Where the money goes
Reading and summarising sit on cheap bands. The plan, the implementation turns and the review escalate, because those are the turns where being wrong is the expensive mistake.
What is recorded
Per-turn cost, the route decision and the models the router rejected, the files touched, and the debate ruling including the position that lost.
Two other jobs in the same shape
Legacy codebase modernisation
Understand the seams before you start cutting along them
A migration of a service nobody fully remembers — a framework upgrade, a module split, a runtime change — cut into reviewable steps that each land as real files and are checked by someone other than the author.
Read itA feature in a service nobody on the team owns
Add the endpoint without first reading the whole service
Land a feature in a codebase you have not worked in — where the real risk is not writing the code, it is putting it in the wrong layer and inventing an abstraction that does not match the house style.
Read itRun this in mock mode first
Node 24, one install, no API keys. The pipeline, the stages, the file writes and the review loop all run against scripted employees, so you can watch the shape of the work before it costs anything.
Nothing in the orchestrator authenticates, so bind it to localhost. The tools are confined to the run workspace, but that workspace is a normal directory on the machine and the orchestrator is not inside an operating-system sandbox — give it a checkout you would be willing to lose.