How Much Is an AI Agent Allowed to Spend?

Separate the forecast from the permission

Before choosing a tool, I would put three questions beside the task:

A good forecast can still be exceeded. A spending limit can be respected while the work remains incomplete. A perfectly reconciled bill can describe an unsuccessful process.

Here, the task is one contract submitted for review against an agreed checklist. The initial run, additional agents, retries and rework all belong to it. Execution status needs its own record, separate from whether the responsible specialist has accepted the findings.

Otherwise, the accounting boundary can move every time the system starts again.

Count the work behind the answer

A two-page report tells us little about the computation that produced it.

For token-priced services, the rates can differ between ordinary input, cached input and output. Anthropic also prices cache creation separately. Paid tools can add other charges. The applicable schedule may depend on the model, service mode and purchasing arrangement. Anthropic pricing

Some consumed tokens never appear in the final prose. OpenAI documents that reasoning tokens are billed as output tokens; its generation limits also cover non-visible generated tokens. OpenAI reasoning guide

For token-priced calls, add the charges for every call attached to the task, including retries and subagents. Then add any separately billed services:

The outer sum adds the task's J model calls. The inner sum adds the Kⱼ non-overlapping billing categories within call j. Tⱼₖ is the token count in category k for that call, and rⱼₖ is its applicable dollar rate per million tokens. Other usage covers separately charged services, such as a paid search or execution environment, counted once. Fixed fees and human work sit outside this metered-cost calculation.

The token categories must not overlap. If a provider reports reasoning inside total output, adding reasoning again will inflate the result. The same problem occurs when cached input is included in a provider's input total but is added again as a separate bucket. Langfuse's documentation explicitly explains this normalisation issue. Langfuse token and cost tracking

Consider two invented execution paths, using assumed rates of $3 per million ordinary input tokens, $0.30 per million cache-read tokens and $15 per million output tokens. These are arithmetic examples, not quotations or measurements of a product. Assume no separately charged cache writes in these totals.

For Path A, the calculation is $0.15 + $0.03 + $0.15 = $0.33. For Path B it is $1.50 + $0.45 + $1.80 = $3.75.

Both paths could produce a report of the same length. The second might have found a material defect the first missed. Or it might have repeated work without improving the answer. We need the quality evidence before treating either path as the better purchase.

Follow the task into the bill

For the contract review, the record needs to connect:

Business task → runs and agents → model and tool calls → attributed cost → execution status and acceptance outcome.

A run can finish while its findings are rejected or still awaiting review.

A provider can supply useful usage dimensions. OpenAI's administrative usage API, for example, exposes grouping by project, API key and other supported fields. Linking those records to the contract being reviewed remains an application responsibility. OpenAI usage reference

The task identifier, parent-run relationship, model and configuration version, usage categories, rate basis and outcome belong together. A reference to a sensitive document can be sufficient; cost attribution does not require copying the contract into the billing log.

Two records then need to agree: the operational ledger used during execution, and the supplier's billing record under the relevant contract. Discounts, credits and other adjustments need explicit treatment. Reconciliation can validate the recorded consumption and charges; it does not independently measure the provider's underlying physical compute.

The purchasing model matters here. Claude Code describes its local dollar figure as an estimate and directs API users to the Console for authoritative billing. It also says that the session cost figure is not a bill for Pro and Max subscribers whose usage is included in their subscription. Separately enabled paid usage needs its own treatment. Claude Code cost documentation

A seat subscription, metered API and provisioned-capacity agreement need different financial models. With paid capacity, utilisation matters even when an additional request does not create an additional token-priced charge. FinOps Foundation discusses these deployment and costing differences. Cost estimation of AI workloads

The counter can be accurate while our interpretation of the money is wrong.

We also need to know what it cost to produce the accepted results:

The numerator includes unsuccessful and stopped attempts. Define its scope: a variable run-cost metric and a full-cost investment appraisal serve different decisions. Development, integration and human review belong in the fuller appraisal, with explicit allocation assumptions. FinOps Foundation's lifecycle costing includes people, licences and third-party components. Forecasting AI services costs

For a separate arithmetic example, suppose 100 cases incur $600 of total attributable cost and 75 pass the agreed acceptance criteria by the measurement cut-off. The cost per accepted result is $8. Report that 75% were accepted by the cut-off, and distinguish rejected cases from those still unresolved. Update the figures as those cases progress. If none are accepted, the ratio is undefined. Changing the acceptance threshold changes the meaning of the metric.

This is consistent with FinOps Foundation's progression from token-level metrics towards useful units of work. It still does not establish ROI: accepted output needs a value assessment and an appropriate comparison with the existing process. FinOps unit economics

Forecast a defined kind of work

The known input is the easiest place to start. Anthropic offers a token-counting endpoint and describes its result as an estimate. OpenAI also provides an endpoint for counting the input to a Responses request. Neither tells us how many further calls an open-ended agent task will need. Anthropic token counting, OpenAI token counting

The range depends on how much of the work we can define in advance:

For a pilot, I would include ordinary and difficult cases, and repeat a subset to measure variation between runs. The record needs cost alongside quality, elapsed time and human involvement. Workload estimates need the expected case mix: extra difficult cases and repeated runs should not give those cases more weight than they have in the planned workload.

The configuration needs to be identifiable. A baseline collected under one model, retrieval strategy or retry policy should not silently become a forecast for another. FinOps Foundation's optimisation guidance connects architecture choices to both cost and forecast accuracy. Effect of optimisation on AI forecasting

For fixed planned volumes, the starting calculation is straightforward:

F contains the fixed costs included in this planning scope. n is the planned number of business tasks in class c, including tasks that stop incomplete. μ̂ is the estimated mean cost per task under the specified retry and stopping policy, including its component runs. The same expense must not appear in both F and the per-task cost.

This period estimate assumes the counted tasks incur their costs within the period. Work carried in or out needs separate timing adjustments. A review started in September may still incur costs in October.

This is a point forecast. If volume and task difficulty vary together, the joint scenarios matter; multiplying an overall average volume by an unrelated average unit cost can hide the relationship.

A supplier can still offer a fixed commercial price. The contract determines who bears the cost when actual usage varies. It does not make the underlying consumption deterministic.

Read P95 without turning it into a promise

The mean helps estimate aggregate spending. The median describes the middle case. P95 is a cost threshold at or below which at least 95% of the distribution falls. Here I use the inverse-CDF definition: the smallest threshold that meets that condition.

In a pilot, we estimate that distribution from observations. Sample size, representativeness and the quantile method matter. NIST notes that software can use different interpolation methods for sample percentiles. A P95 estimated from a small pilot deserves much less confidence than the decimal places in a spreadsheet suggest. NIST on percentiles

P95 also leaves the severity of the remaining tail unspecified. I would inspect the expensive cases and report the observed maximum, while keeping clear that a sample maximum is not an upper bound on future cost.

There is another trap: multiplying a task-level P95 by the number of tasks does not generally produce the P95 of the total.

Here is a deliberately simple probability model, setting all other expenses aside. Each task costs $1 with 90% probability and $10 with 10% probability. Its mean is $1.90, median $1 and P95 $10.

What changes if the expensive cases arrive together?

Each task has the same cost distribution in both rows, and the expected total is unchanged. In the second workload, the expensive tasks arrive together, raising the P95 of total cost.

In the independent case, K is the number of expensive tasks. It follows a binomial distribution with 100 trials and probability 0.1. Total cost is $100 + $9K. The smallest K for which the cumulative probability reaches at least 95% is 15. Total cost at that point is $235. These are exact calculations under invented assumptions, not a forecast of an actual AI workload.

Real tasks can share cost drivers: a model change, a failed dependency causing retries, or a batch of unusually difficult documents. Where the exposure warrants it, I would model volume, task mix and shared shocks together. Monte Carlo simulation can repeatedly draw those inputs, calculate a period total, and show the resulting distribution. It cannot repair unsupported assumptions. Distributional forecasting and simulation are established statistical methods; applying them to this workload requires an appropriate model. Hyndman and Athanasopoulos, forecasting distributions

Budget-stopped tasks also belong in the pilot record. Their observed cost is the cost of a stopped attempt. The cost of completing that work remains unknown. Excluding them changes the population being forecast; treating them as completed at the cap overstates completion.

P95 can inform a spending decision. It cannot make that decision for us.

Give each tool a specific job

These distinctions help us choose tools for a defined job. The examples below describe documented capabilities; they are not a comparative benchmark or a tested reference stack.

LiteLLM documents a reservation mechanism for supported token-priced routes. It also documents limitations for some image/audio routes and batch jobs. Its budget controls need a database; stronger enforcement during Redis failure or stale state requires the documented fail-closed configuration. I would check the version actually deployed and test failures both when reading spend and when writing the reservation. LiteLLM budgets and reservation

Provider controls have their own boundaries. OpenAI distinguishes spend alerts from optional hard monthly limits at both organization and project level. Alerts leave traffic running; enforced limits reject affected requests, although enforcement delays can allow some overshoot. This is still different from reserving a bounded amount for each business task. OpenAI spend limits

Claude Code provides another concrete example. Its --max-budget-usd option applies in print mode; the CLI reference says subagent spend counts towards the cap and describes stopping background subagents and rejecting further spawning once the cap is reached. Those enforcement behaviours require version 2.1.217 or later. This does not establish an exact ceiling on every component of the final invoice. Claude Code CLI reference

Execution settings also need to be distinguished from spending controls. Claude Code's ultracode setting combines xhigh reasoning effort with automatic workflow orchestration. Its workflow-size setting is guidance to the model rather than a hard agent-count cap; the runtime has separate caps. The large-workflow warning is advisory and is not shown with ultracode enabled. These settings describe how work can be organised. They do not, by themselves, specify how many dollars the task is authorised to spend. Claude Code workflows

A closed SaaS product may expose only part of this chain. Before designing a process around it, I would ask which records and controls the purchased plan actually provides.

Put the limit before the next commitment

Return to the $2 remaining in our contract review.

Suppose ten agents each check that balance before any new spending is recorded. Each submits a $1 request. Every local check passed, but together they committed $10.

Before a worker sends a request, the system needs to reserve enough to cover its maximum possible charge within the budget's scope. Checking the balance and reserving that amount must happen together, as one atomic operation across workers. Otherwise, another worker can spend the same remaining dollar.

The design condition is:

S is recorded spend, R is the outstanding reservation for admitted work, B is the authorised budget, and the final term bounds the proposed next request within the costs this control covers. A P95 estimate is not a maximum. If the next charge cannot be bounded, this formula cannot establish a strict ceiling. The owner must decide whether to accept that exposure or block that route.

Once actual usage is known, the system reconciles the reservation with the charge. Moving a charge from the reservation into recorded spend must be atomic and applied once. Reservations must continue to cover calls whose charges remain unresolved. A timeout alone must not release the hold, and each potentially billable retry needs budget coverage.

For an actual deployment, I would test concurrent requests near exhaustion, delayed usage reports, counter failure and retries through another route. Every paid route covered by the budget must pass through this check. A restarted task should retain its spending history. A cancellation should not be assumed to erase charges already incurred.

The test also needs a decision for an unavailable or untrustworthy balance: pause paid work, or use a separately authorised and bounded fallback. In either case, the unfinished review needs a clear status.

Decide what a stopped task is allowed to claim

The budget is exhausted. The contract review still has an unchecked attachment.

The system needs to preserve completed findings, identify the missing check and mark the task as incomplete. Further work would need approval from the authorised person or under a pre-authorised rule. The decision may allow another check, narrow the agreed scope or hand the remaining work to a person. Any model-generated handoff also needs budget, so saving progress and reserving room to close the task should happen before exhaustion.

There is a serious argument against an inflexible per-task cap. It may stop the difficult cases precisely where further investigation is most valuable. Stopping can also cause operational harm. A low-risk drafting experiment and a time-critical service need different exhaustion policies.

I would therefore distinguish an exploration allowance, escalation thresholds and an absolute boundary for the costs being controlled. Shared pools can be appropriate. So can a pre-authorised, bounded continuation policy. The decision should follow the consequence and the value of further work; cost control should not silently lower the agreed quality standard.

For this contract, I would set the initial allowance using the pilot's cost and acceptance results, the available budget and the consequences of stopping. The approval needs to state which model and tool charges it covers, what is reserved for saving and handing over the findings, and which role may authorise further work. A request for more budget should identify the unchecked item, the bounded cost of the next step and what remains unresolved if the review stops.

The agent may request an extension. It must not be able to expand its own spending authority or rewrite the policy that grants it. Any increase should record the approver or pre-authorised rule, amount and task scope.

Before this contract review becomes routine, the evidence and the spending authority need to be in one record. The process owner defines the task and acceptance criteria. Engineering implements and tests the control. Finance and FinOps reconcile the economics; procurement clarifies the commercial terms. The person or team authorised to commit the budget approves the allowance and the terms for continuation.

Then I would test a controlled case with $2 remaining, an attachment still unchecked, and a next request requiring a $3 reservation. The test needs to show that the request is blocked, the findings are saved and a named person can authorise continuation.

I would want the person relying on the review to know exactly what remained unchecked.