Estimate and cap LLM costs before a run

Count the model calls a job needs, turn them into a low, likely and high cost, and stop for approval. Then hold a spending cap by reserving each call's worst case before it is sent.

An LLM app that spends someone else's money needs two things before it runs: an estimate good enough to approve, and a cap that still holds when calls run in parallel. The method below works for any pipeline whose steps you can count.

Why estimate before the first call

Every token is somebody's money, and on a free tier every request comes out of a daily allowance. If people learn the cost only afterwards, the first surprise bill is often the last time they run your tool. So make one rule and keep it: nothing is spent before the person paying has seen a number and said yes.

Work you can count is work you can estimate. When code decides the steps, the size of the input fixes the number of calls. When a model chooses its own next step, estimate the parts you can count and put a hard cap around the rest.

Count the work, not the tokens you hope for

Start from an inventory of the input, before any model call. List each kind of call the job makes, how many of each the input implies, and a token budget for each one's input and output. If you have no tokeniser, approximate input tokens from character counts. Code packs more tokens into each character than prose does, so count the two separately.

Then give a range rather than one number. Input is predictable and output much less so, and a model that thinks before it answers bills its reasoning as output. Scale the likely figure down for a low estimate and up for a high one, with the widest spread on a thinking model's output. The high figure is the one to show next to the approve button.

Recalibrate after the first batch

A count based on characters can be wrong for unusual code. After the first real calls, compare the tokens the provider reported with what you estimated for those calls. If they differ by more than a small margin, recompute the rest of the estimate. Keep the approved figure as it was and show the new one beside it, so the record of what the person agreed to stays intact.

Prices you can trace

An estimate is only as good as the price behind it. Look prices up in a fixed order: one the user entered, then a list you maintain with a source and a review date, then a community catalogue clearly labelled as unverified. If none of them has the exact model, say "price unknown" and never borrow a neighbour's price. Without a price no cap can hold, so stop before spending.

Compute each call's cost from the usage the provider returns, with uncached input, cache reads, cache writes and output each at its own rate. Then test that sum against what the provider actually bills.

Approval is a pause in the workflow

Make the approval a real stop. In a graph framework that means an interrupt after the estimate: the job waits, at no cost, until a person approves and sets a cap. Let people choose a threshold below which small jobs approve themselves. On a command line a cap flag can double as the approval: when the high estimate is over the cap, stop and say which cap would be enough.

Enforce the cap with reservations

A cap checked against money already spent fails as soon as calls run in parallel. Four calls can each see room under the cap and together overshoot it. Keep a ledger of calls instead:

1. Before each call, record a reservation for its worst case: the estimated input plus the full output allowance, reasoning included, at the price of the dearest model that might answer.
2. Refuse the call if settled spend, open reservations and calls of unknown outcome together would pass the cap.
3. When the answer arrives, settle the reservation to the real cost.

A call that was in flight when the process crashed has an unknown outcome. Keep counting it at its full reservation, because the provider may have billed it.

Reservations are pessimistic on purpose, so near the cap they can block calls that would have fitted. Let a call that finds no room wait for the calls in flight to settle, and refuse it only when nothing is in flight and there is truly no room.

Across many agents the same question becomes a company budget, which we cover in pricing each agent task across a company.

Keep money for the part people read

Running out of money halfway is worse than spending less. Set aside a write reserve: what the final writing steps cost at their maximum output, never more than a fixed share of the budget. Once the reading stages reach it, they stop, the writing uses the reserve, and the result is published as partial, with the reason. Retries and repairs go through the same ledger, so the cap holds even for calls the estimate never counted.

Say plainly what the cap is: a guard inside your app, not a billing limit at the provider. The provider's invoice is the authority.

How Nehemvix does it

Nehemvix writes documentation guides from Git repositories on the user's own model key, and it follows this method step by step. Its orchestration is a LangGraph graph rather than a model choosing tools, so the files, folders and sections of a repository fix the number of calls.

The budgets

Input is counted at about 3.2 characters a token for code and configuration and 4 for prose, and the caps on synthesis and sections were calibrated on live runs. Files the cache already holds are not counted, and what they save is shown separately. The range then scales the likely figure:

More thinking or longer sections raise the output factors. Each extra audience adds only its own sections, because the analysis is shared. The expected duration comes from the call count, in waves of four parallel calls at 6, 12 or 20 seconds a call.

Recalibration and prices

After the first map batch, Nehemvix recomputes the estimate when real input differs from the estimate by more than 10%, and shows it as "estimate updated from actual usage" beside the approved one. Prices come from the user, then Nehemvix's own verified list, then LiteLLM's community catalogue marked "not verified". A live test recomputes each provider's bill from its raw usage. On 21 October 2026 it caught Claude cache writes being charged at the plain input rate, which was then fixed.

Approval and the cap

In the web app, the graph's estimate node calls LangGraph's interrupt() and the job waits at $0 for approval. On the command line the cap is the approval, $1.00 a job unless you pass --cap, and a run whose high estimate is over it stops before spending:

estimate: $0.018 to $0.038 (likely $0.024), about 19 model calls, about 2 min
Run again with --cap 0.04 or more

The reservation rule above came from a real run. On Gemini 3.8 Flash each section reserved about $0.036 but spent about $0.003, so four parallel sections under a $0.10 cap blocked each other and only 2 of 7 were written. Waiting for calls in flight to settle fixed it. The write reserve is never more than half the cap, and every cost report says the cap "is a best-effort app guard, not a provider billing limit".

How close the estimates came

Two techniques moved the actual cost more than any tuning of the estimate. Explicit prompt-cache breakpoints on OpenAI are the difference between the two October runs: the second used them and cost 16% less. And remembering file summaries by content let a second run of jonschlinkert/is-odd reuse 12 of 12 files, for $0.0054 instead of $0.0065.

Checklist

1. Count the calls the work needs before the first one, and give each kind a token budget.
2. Show a low, likely and high range, widest for thinking models.
3. Recalibrate after the first real batch, and keep the approved figure.
4. Price from a source you can name, and refuse to guess a model's price.
5. Reserve each call's worst case in a ledger before sending it.
6. Count calls of unknown outcome as spent.
7. Keep part of the budget for the output people read.

Where prices come from and how to keep a run cheap are in costs. How a paused run continues without paying twice is in pause and resume an AI agent pipeline, and the other places a person stays in control are in human in the loop for AI agents.

Learning this to build your own agent? AELSHA™ can help you design it.