The first time an AI agent surprised me on cost, it was not a big task. It was a small one that got stuck, retried itself in a loop, and quietly ran a heavy model in circles until I happened to look. The work it produced was worth about two minutes of a cheap engine. The tokens it burned were not.
That is the shape of the problem. Token spend is invisible while it happens and obvious a month later, when the invoice lands and the decision that caused it is already history. You cannot manage a cost you only see after it is spent.
Controlling AI cost is not about hunting for a cheaper subscription. It is about moving the decision to where it belongs: the individual task, with a number in front of you, before the tokens are gone.
Cost is a per-task fact, not a monthly one
Your bill is one number. Your work is a thousand tasks, and they are wildly unequal. A one-line copy fix and a database migration both show up as “AI usage” on the statement, but one of them should cost a rounding error and the other earns its price.
When you only see the monthly total, you cannot tell those apart. You cannot find the task that looped for an hour. You cannot see that half your spend went to trivial edits routed, by default, to your most expensive engine. The aggregate hides exactly the information you would need to act.
So the first move is not a limit. It is visibility at the task level. What did this run cost in tokens. Which engine did it use. How much of that was the real work and how much was retries. Until you can answer that per task, every cost conversation is a guess.
A budget the task cannot quietly exceed
Once you can see per-task cost, you can cap it.
A budget per task is a simple idea that most setups do not have. Before a run starts, you decide the ceiling: this kind of work gets a light profile and a low cap, that kind gets a strong profile because it earns it. The task runs inside that envelope. If it blows through, it stops and tells you, instead of silently spending your month on an agent that got confused.
The reason this matters is the failure mode I opened with. Agents do not overspend on the tasks you were watching. They overspend on the one that went sideways at 2am, retried itself, and had no ceiling to hit. A budget is not there to squeeze the good runs. It is there to catch the run that lost the plot before it costs you a dinner out.
Profiles make this livable instead of tedious. You do not price every task by hand. You define a few tiers, cheap, balanced, strong, and the task inherits a sensible ceiling from its tier. The manual decision happens once, at the tier, not once per task.
The cap also changes how an agent behaves when it is stuck, which is the whole point. Without a ceiling, a confused run keeps trying, because nothing tells it to stop. With one, hitting the limit is a signal. It surfaces the task that needs a human instead of quietly grinding through your budget in the dark. A budget is as much an alarm as it is a wallet.
Route cheap work to cheap engines
The largest, most boring source of waste is sending trivial work to a frontier model because that is what the tool defaulted to.
A copy edit does not need your strongest engine. Neither does a rename, a comment, a small refactor the tests already cover. If all of that goes to the same expensive model as your risky migrations, you are paying frontier prices for work a light model finishes just as well. Routing by cost is the fix: the task’s profile decides which engine picks it up, and cheap work lands on cheap engines by default.
This is the same argument as routing every task to the right engine, read through the cost lens. There the point was fit and availability. Here it is the bill. They are the same mechanism. Once the task, not the model, is the unit you route, cost control stops being a separate feature and becomes a property of how work is dispatched — which matters most when you are running several agent sessions in parallel and each one is quietly spending.
The engine you never pay for at all is the local one. Work that can run on an open-source model through Ollama costs you electricity and nothing else. For a large slice of routine tasks, that is the right answer, and a factory that treats local engines as first-class lets you take it.
The cost you forget to count
The obvious cost is the token price of a successful run. The one that eats budgets is everything around it.
Retries. An agent that fails, retries, fails again, and does it three times before anyone notices has paid four times for one task. Drift. Work that quietly went off-spec and has to be redone is not a discount, it is a second full run. Verification loops that re-execute the whole thing to check it. Context you resend on every turn because the tool has no memory and reloads the world each time.
None of that shows up as a line called “waste.” It shows up as normal usage, which is exactly why it survives. The way you find it is the same visibility from before: if you can see that a task was run four times, or that a run cost triple its neighbors, you can go fix the cause. If all you have is the monthly total, the waste is load-bearing and invisible and it stays.
This is also where cost control and verification meet. An agent that credibly proves it finished is an agent you do not re-run to be sure. Cheap and correct are not in tension here. The system that makes a model prove completion is the same system that stops you paying twice for the same work.
Where PaellaDoc fits
PaellaDoc treats cost as a property of the task, not a surprise at the end of the month. Each task carries a profile, cheap, balanced, strong, frontier, and that profile decides the engine and the ceiling. Cheap work routes to cheap engines, or to a local model through Ollama for the price of electricity, and the expensive engine is reserved for the task that earns it.
Because the local software factory is local and the work is bounded, you can see what a run actually cost and how much of that was retries or recovery instead of first-pass work. And because a task closes only when the evidence says it did, you are not paying again just to convince yourself it worked. The leverage is not a cheaper model. It is a system that spends deliberately and lets you watch it do so.
Do you know what your last ten tasks cost, one by one? If the real answer is “the monthly total, roughly,” that is the gap worth closing first.
Frequently asked questions
How do I control AI coding costs?
Move the decision from the monthly bill to the individual task. First get visibility at the task level: what a run cost in tokens, which engine it used, how much was retries. Then cap it with a per-task budget and route cheap work to cheap engines by default. Cost stops being a surprise at the end of the month and becomes a property of how each task is dispatched, with the number in front of you while you can still act.
Why did my AI agent burn so many tokens?
Usually it is not the task you were watching. Agents overspend on the one that went sideways — got stuck, retried itself in a loop, and ran a frontier model in circles with no ceiling to hit. The rest hides in costs you forget to count: retries, drift that has to be redone, verification loops, and context resent every turn because the tool has no memory. None of it shows up as “waste”; it looks like normal usage.
How do I set a token budget per task?
Define a few tiers — cheap, balanced, strong, frontier — instead of pricing every task by hand. Each task inherits a sensible ceiling and engine from its tier, so the manual decision happens once, at the tier. When a run blows through its cap it stops and tells you, instead of silently spending your month. The budget is as much an alarm that surfaces a confused run as it is a wallet.
Should I route cheap tasks to cheaper models?
Yes; it is the largest, most boring source of waste. A copy edit, a rename, a comment or a small refactor the tests already cover does not need your strongest engine. Let the task’s profile decide which engine picks it up, so cheap work lands on cheap engines by default. Routine work that can run on a local open-source model through Ollama costs only electricity, which is often the right answer.