Budgeting agent capacity and cost

Agent spend is the first engineering cost in a while that behaves like a utility bill: it is variable, it is driven by usage patterns most people cannot see, and it can move sharply without anyone signing anything. Finance teams are not used to that from a development tool, and engineering leaders are often asked to explain a number they have not been given the data to explain.

What actually drives the cost

Three things, in order of size.

Context volume per attempt. Every request carries the conversation, the files read, and the command output. A session that has read forty files is paying for those forty files on every subsequent step. This is why managing context matters: Anthropic's own guidance treats the context window as the most important resource to manage, and recommends clearing between unrelated tasks and using subagents so exploration does not consume the main context [1].

Number of attempts. A task that succeeds on the first try costs once. A task that succeeds on the fourth costs four times, plus the review time on three failures. Most cost overruns we see are attempt counts, not model prices, and the fix for high attempt counts is a better specification and a check the agent can run, which is the whole argument in what done means when an agent writes the code.

Unbounded exploration. An agent told to investigate something without a scope reads hundreds of files. Anthropic names this as a failure pattern and recommends scoping investigations narrowly or delegating them to subagents [1]. It is also the single easiest thing to fix.

Model choice matters, but less than these three, and choosing a cheaper model that needs three attempts is a false saving.

How to budget it

Treat it as variable delivery cost, in the same conversation as infrastructure, and review it monthly against delivery output rather than in isolation.

The number worth tracking is cost per delivered change, meaning total agent spend divided by changes that reached production, plotted over time. It is simple and it measures the right thing: it goes down when the process improves, and it goes up when the team keeps failing and retrying, which is exactly the behaviour you want a budget line to reveal.

Two things to set up early. Attribute spend to a team or a repository rather than to individuals, so the number describes work rather than a person's habits. And set an alert on the rate of change rather than only on the total, since the failure mode is a loop that runs all weekend rather than a slow increase.

Controls that work

Four, with the most effect per hour of setup first.

A hard limit that stops work. A budget cap that stops work rather than sending a notification. Anything that only warns will be exceeded on the day something goes wrong, which is exactly when a loop runs out of control.

Scoped tasks. Small, well-specified units cost less because they need less context and fewer attempts. Everything in decomposing work for coding agents is also a cost control, which is a useful match: the practices that improve quality also reduce spend.

Checks the agent can run itself. An agent that can test its own work can retry and fix it without waiting for a human. Waiting for a human costs a person's attention, which is far more expensive than tokens, and it usually adds a day of delay.

Managing context as a habit. Clearing between unrelated tasks, using subagents for exploration, and keeping the always-loaded instruction file short [1]. Nobody sees this habit, but its effect on the bill is clear.

Do not optimise the wrong number

The most common budget mistake is optimising the model bill while ignoring the two costs that rise when it falls.

The first is engineer time. If a cheaper configuration produces work that takes a senior engineer an extra hour to correct, it is not cheaper by any measure a business cares about. Engineer time remains the dominant cost in almost every team we work with, and agent spend is small next to it.

The second is defect cost. A configuration that releases more defects costs incident time, customer trust and rework, none of which appears on the tool invoice. Compare configurations on delivered outcomes, using the numbers in measure delivery, not generated output, rather than on spend alone.

Comparing against what it replaced

Leaders are frequently asked to show the saving. Two honest positions are available, and a third one that is not.

The honest positions: report cost per delivered change against your own historical baseline, or report the total engineering cost of a comparable piece of work before and after, stating clearly what else changed in between. Both are defensible and both are approximate, because the work is never identical.

The position that is not honest is quoting a percentage saving from a vendor, or extrapolating from one project to a company-wide figure. There is a reason we describe our own pricing as a mechanism rather than a number: we use AI instead of hiring more engineers, so the same build takes a smaller team, and that saving goes into the client's price. That is a description of how it works, and it is stated without a percentage because no percentage has been measured.

When the bill jumps

It will, and the response is usually the same four checks in the same order.

Look at attempts before anything else. A jump is far more often a task that ran twenty times than a price change, and the twenty attempts have a cause: a specification that was not checkable, a check the agent could not run, or a goal it could not reach because something in the environment was broken. Fixing that cause is cheaper than any configuration change.

Then look for the unbounded run. An investigation with no scope, a loop with no exit condition, or a job that retried all weekend produces a sudden jump in the bill rather than a slow rise. This is what the hard limit is for, and if the jump happened it means the limit only warned.

Then look at context. A session that reads the whole repository before every task pays for it every time, and the fix is managing context: clearing between unrelated tasks, delegating exploration, and keeping the always-loaded file short [1].

Only then look at model choice and pricing, which is where most people start. It is the smallest of the four in almost every case we have examined, and changing it while the first three are unaddressed just moves the same waste to a cheaper unit price.

The forecasting problem, stated plainly

Agent spend is hard to forecast twelve months out, and anyone who tells you otherwise is guessing. Prices change, model efficiency changes, and your own usage patterns change as the team learns. What you can do is limit the risk: set a hard limit that stops work, review monthly, and keep the spend attributable so a jump can be explained rather than simply paid.

That is a less satisfying answer than a spreadsheet, and it is the accurate one.

The question to bring to a budget conversation

Finance does not need to understand tokens. It needs to know three things, and they are all answerable.

What is the limit, and what happens when it is reached. If the answer is that work stops, the risk is limited and the conversation is short. What drives the number up, in business terms rather than technical ones: more projects running at once, and work that was specified badly enough to need several attempts. And what is being bought, expressed as cost per delivered change against the same figure six months ago.

Framed that way, agent spend is an ordinary variable cost with an unusual name. The mistake is presenting it as a strategic technology investment that cannot be measured, which invites either an unlimited budget nobody controls or a cap set low enough to slow the team down for no saving worth having.

Where this connects

Cost follows from practice. Well-scoped work with checks the agent can run is cheaper, faster and better, which is the argument running through decomposing work and the definition of done. The delivery numbers that tell you whether spend is buying anything are in measure delivery, not generated output, and the broader question of what software costs to build this way is the software development cost guide. The main guide has the full model.