FinOps for AI agents: What a coding session really costs
Most teams do not budget for AI coding agents in a way that survives contact with reality.
They think in subscriptions, seats, or rough monthly caps. What they actually have is a new compute-consumption pattern running inside engineering delivery, and it behaves more like an operational workload than a normal software subscription.
That is why the bill often feels surprising.
Not because the pricing was hidden, but because the unit economics were never made visible in day-to-day work.
Why agent spend is easy to underestimate
When a developer uses an AI coding agent, the final output can look deceptively small.
The session may have consumed:
- large input contexts
- repeated assistant turns
- retries after tool failures
- cache writes and cache reads
- more than one model
- extra loops caused by vague prompts or weak constraints
None of that is obvious when the only artifact you inspect is the resulting code change.
So teams misread the cost structure. They assume the value is tied to the final patch size. In reality, the cost is tied to the interaction path.
The four token buckets people need to understand
If you want to manage agent spend sanely, start with the underlying token categories.
1. Input tokens
This is the prompt plus the context sent to the model.
For coding agents, input cost grows quickly because the model is often given repository files, prior messages, tool results, system instructions, and intermediate reasoning context. Long-running sessions push this number up fast.
2. Output tokens
This is the model's response back to the harness.
In many cases output is not the dominant cost, but it still matters, especially when the model is verbose, retries are frequent, or the harness keeps asking for detailed plans and explanations.
3. Cache creation tokens
Some platforms charge separately when prompt context is written into cacheable form.
Teams often forget this category entirely. It is invisible in everyday conversation and material in real usage.
4. Cache read tokens
These are cheaper than fresh input on many pricing models, but they are not free. If sessions are large and repeated often, cache reads add up.
This is one reason a workflow can feel efficient to the user while still becoming expensive at team scale.
Model choice matters more than teams think
A second source of confusion is model mix.
Many teams talk about "using AI agents" as if that were a single operational mode. It is not. Spend depends heavily on which models are being invoked, how often, and for what class of task.
A team might be:
- using a premium model for broad exploration work
- falling back to another model for retries
- mixing fast and slow models across different harnesses
- unintentionally sending simple tasks through expensive paths
Without per-model visibility, the finance conversation turns from data driven decisions to guessing very quickly.
The real cost driver is session shape
The most useful way I have found to think about agent spend is not per seat and not even primarily per request. It is per session shape.
A session becomes expensive when several conditions combine:
- large context windows
- multiple tool loops
- broad repository scanning
- repeated failed attempts
- expensive model selection
- poor prompt discipline
This is why two sessions that both end in a small code change can have wildly different costs.
One was direct. The other was a wandering expedition through your codebase and model budget. If you do not capture that difference, you cannot improve it.
What a useful cost view should show
For AI-agent FinOps to be actionable, the cost view has to map to how engineering organizations actually work.
At minimum, I want to see:
- cost by harness
- cost by project
- cost by session
- cost by model
- daily and monthly trends
- warnings for models that have no mapped pricing
If possible, I also want the ability to correlate cost with session quality signals. Expensive sessions are not automatically bad. Some of them produce a lot of value. But high-cost sessions with repeated retries, weak outputs, or elevated risk findings deserve attention.
That is where FinOps becomes engineering management.
The mistakes I expect teams to make
The first mistake is treating token spend as too small to matter.
At single-user scale, that can be true. At team scale, it stops being true surprisingly quickly.
The second mistake is focusing only on total monthly spend.
Totals matter, but they do not tell you why the spend happened. Without per-session and per-model visibility, there is no path to improving it.
The third mistake is assuming that cost optimization means using weaker models.
Sometimes it does. Often it means reducing waste instead:
- shrinking unnecessary context
- tightening prompts
- reducing retries
- separating exploratory work from execution work
- using different models for different phases intentionally
That is a much healthier optimization path.
Why this belongs with governance
I do not think cost should sit in a different mental bucket from security and control.
It is part of the same operational question: "What are these agents doing in our environment, and is that behavior acceptable?"
Sometimes unacceptable means risky, sometimes it means wasteful, usually it means both.
Once teams can see agent sessions clearly, they realize that governance is not just about preventing catastrophic mistakes. It is also about making agent usage legible enough to manage.
The practical takeaway
If your organization is already using AI coding agents, pull one week of activity and answer four questions:
- Which projects consumed the most spend?
- Which models drove that spend?
- Which individual sessions were outliers?
- How much of the cost came from productive work versus avoidable churn?
Most teams cannot answer all four cleanly yet.
That is normal. The category is still early.
But the teams that answer them first will manage adoption much better than the teams that rely on end-of-month surprises and intuition.
We help teams get that visibility in place as part of a self-hosted AI-agent risk review: not just what the agents did, but what they cost, where the spend sits, and what workflow changes will improve it. If you want to see the mechanics, start with the live demo. If you want the readout for your own environment, book a risk review with us.
