TL;DR
Last month's cost data showed one clear habit: most of the work went to the most expensive model, and half the time nobody had chosen it. I measured 205 work hand-offs inside my own sessions — in 101 of them, no model was chosen at all, so the most expensive one did the job by default. My agent framework, ai-badger, now fixes this with three changes: every helper role names its own model, a hand-off with no model named is refused, and a new "delegator" role leads long sessions and hands work out instead of doing it. The before is measured. The after is not yet — that will be the next article.
What the bill actually said
Part 2 of this series read one month of my agent usage: about $10,400 in estimated API prices. Nobody billed me that — the number is rebuilt from token counts, and Part 2 explains how. Two findings mattered more than the total.
First, a small number of long sessions carried most of the money — 5% of sessions held 61% of the cost. Second, the split between models was strange. The most expensive model took over half the money in just six days of use. The mid-size model did a similar amount of work for about a third of the price. The smallest model worked on twelve days and cost $67 in total — close to free.
So the cheap models were doing fine. They were just not getting the work.
Who chose the expensive model? Nobody.
My sessions run like a small team. There is a main session — the one I talk to — and it hands packages of work to helper agents: review this, write that, find out why the test fails. Each hand-off can say which model should do the job. Big model for hard thinking, mid model for writing code from a plan, small model for simple mechanical work.
I pulled the records of 205 real hand-offs from six days of sessions and counted.
| Hand-offs | Count |
|---|---|
| A model was chosen | 104 |
| No model was chosen | 101 |
When no model is chosen, the work silently goes to the same model the main session runs on — the expensive one. That happened 82 times. Not once in 205 hand-offs did anyone pick the smallest model. And the specialist roles I had carefully defined for this team — a reviewer, a planner, a test writer — were used exactly zero times. Every job went to a generic helper instead.
Here is the uncomfortable part. The rule "hand work to cheaper models" was already written down. Twice. In two documents that every session reads. The measurement shows both were ignored, 205 times in a row.
A written rule changes intentions. It does not change behavior.
Three changes, cheapest first
So instead of writing the rule a third time, I built it into the machinery. Three changes, ordered by cost of building them.
1. Every role card now names its model. Each helper role in the framework — the reviewer, the planner, the code writer — now carries a default model, chosen to match the job. Deep thinking roles get the big model. Roles that follow a written plan get the mid one. Nobody has to remember anything: sending work to the reviewer now automatically uses the right model, even at 2 a.m. in a session that has been running for two days.
2. A hand-off with no model named is refused. The framework now checks every hand-off before it leaves. If no model is chosen, and the target role has no default of its own, the hand-off is rejected with a short message that says how to fix it. Like a form that cannot be submitted while the price field is empty. This closes the 101-hand-offs hole with machinery, not with a third document: silence no longer means "expensive by default", it means "try again and choose".
3. A new role: the delegator. The first two changes fix how work is handed off. They cannot make a session split its work into packages in the first place. That is judgment, so it became a role. The delegator is a team lead for long sessions. Its job description is short: break the task into packages, hand each one to the right role and model, check the results, and never do the work itself. It starts every session by reading a one-page map that lists which helpers exist in this project, what each one is for, and how the work will be verified. If the delegator is writing code, it has already failed.
why refuse instead of choosing for you
The tempting version of change 2 was to fill in a cheap model automatically instead of refusing. I rejected that on purpose. In the platform's rules, a model chosen at hand-off time beats the role's own default — so an automatic fill-in would silently override change 1 on every single hand-off. The refusal keeps the role defaults in charge and pushes the choice back to whoever is handing off the work, which is where it belongs.
What I expect, and what I do not know yet
Before the changes, roughly 15% of the output work was done by the cheaper models. The target I wrote down is 45%, with zero unchosen hand-offs — that second number is now enforced by the machinery, so it is the one I am sure about.
The honest part: the "after" is not measured yet. The plan says at least ten full working sessions on each side of the change before comparing, because this month's own data showed single days swinging by a factor of 84 — a two-day comparison would be noise, not an answer. When the numbers exist, they go in this series, whether they say the changes worked or not.
One thing I can already report: the refusal blocked one of my own hand-offs the same evening it was built, minutes after it went live. Not for the designed reason — it turned out to be a bug in how the check was installed, which I then fixed. That is still the argument in miniature. A document fails silently, 205 times in a row. Machinery fails loudly, once, and gets repaired the same night.
Part 2: What AI Coding Agents Actually Cost, Part 2 — the month of data these changes came from. Part 1: What AI Coding Agents Actually Cost — three agents, two weeks.