Tool
Agent Run Budget Simulator
An agent that loops does not cost the same on every turn. This tool simulates a run turn by turn, shows where the total lands, and tells you which turn crosses your budget cap.
Tool results and replies the next turn re-sends.
The prices shown are example prices, not any vendor's. Enter your model's current prices; we remember them in this browser.
Result
- Expected total: $1.33
- Worst-case total: $2.19
- Cap not reached
Worst case assumes context grows twice as fast per turn.
| Turn | Input tokens | Cumulative | Share of total |
|---|---|---|---|
| 1 | 4,000 | $0.024 | |
| 2 | 5,500 | $0.053 | |
| 3 | 7,000 | $0.086 | |
| 4 | 8,500 | $0.12 | |
| 5 | 10,000 | $0.17 | |
| 6 | 11,500 | $0.21 | |
| 7 | 13,000 | $0.26 | |
| 8 | 14,500 | $0.32 | |
| 9 | 16,000 | $0.38 | |
| 10 | 17,500 | $0.44 | |
| 20 | 32,500 | $1.33 |
Why agent cost is not linear
A chat model has no memory. To continue a conversation, the agent sends the whole history again on every turn: the original prompt, every earlier response, every tool call and every tool result. So turn one sends a small input, turn ten sends ten turns of accumulated history, and turn thirty sends thirty.
Input grows by roughly the same amount each turn, which means the total tokens sent across a run grows roughly with the square of the number of turns. Twice the turns costs about four times the input. This is why a run that looked cheap at ten steps can hurt at forty.
What the inputs mean
Initial context is what the first turn sends: system prompt, tool definitions and the task. Added tokens per turn is how much the history grows each turn, which is the model's output plus whatever the tools return. Output tokens per turn is what the model writes each time, and it is billed at the output price.
Turns is how many loop iterations you expect. The two prices are the per-million rates you are quoted, entered by you so the page never holds stale numbers. The budget cap is the most you are willing to spend on one run.
How the cap turn is found
The simulator adds up the cost of each turn as it goes and records the first turn where the running total is above your cap. That is the turn at which a guard should have stopped the run. If the total never passes the cap, or the cap is zero, no turn is reported.
A worked example
Illustrative numbers only, with example prices of 2 dollars per million input tokens and 10 per million output. Start with 2,000 tokens of context, add 1,000 per turn, produce 300 output tokens per turn, and run 20 turns. Total input is 230,000 tokens, so about 46 cents, plus 6,000 output tokens for 6 cents. The run costs about 52 cents.
With a cap of 25 cents, the running total passes it on turn 14, where 13 turns have cost just under the limit. Now double the growth, as if tool results came back twice as large as you assumed. Total input becomes 420,000 tokens and the run costs about 90 cents. Same task, same turn count, and the bill is almost twice as large.
Why the worst case doubles growth
The weakest guess in any estimate is how much each turn adds, because tool output is unpredictable: a search returns a page, a file read returns a file. The worst case doubles that growth and leaves everything else alone. It is not an upper bound, it is a way to see how sensitive your budget is to that one guess.
Stopping a runaway
Three controls cover most failures. A hard turn limit ends any loop that is not converging. A token budget tracks cumulative tokens sent and stops the run, or asks for help, when it is exceeded. An approval gate pauses before expensive or irreversible steps and waits for a person.
Also trim what you carry. Truncate large tool results, summarize old turns, and drop content the model no longer needs. Shrinking the history shrinks every later turn, which is where the money is.
What the model ignores
It assumes one model call per turn. Parallel tool calls, sub-agents and retries each add cost it does not see. It also ignores prompt caching, which can make the repeated history cheaper when a provider supports it. Treat the output as a shape, not a quote.
Frequently asked questions
Why does doubling the turns more than double the cost?
Every turn re-sends all earlier history. Later turns are larger than earlier ones, so total input tokens grow roughly with the square of the turn count, not in a straight line.
How do I choose added tokens per turn?
Log a few real runs and average the growth in input size from one turn to the next. If you have no logs, take the typical output length plus the typical tool result size.
Does prompt caching change the answer?
It can lower the effective price of the repeated history, which is most of the cost in a long run. The simulator does not model it directly, so lower the input price you enter if you want an approximation.
Is this a hard limit on spend?
No. It is an estimate for planning. To enforce a limit, put a turn limit and a token budget in the agent itself.
Related tools
- Token Counter
Count tokens for any text, exactly for OpenAI models and estimated for Claude, in your browser.
- Claude Token Counter
Estimate Claude tokens and input cost for a prompt, with the limits of estimating spelled out.
- OpenAI Token Counter
Exact o200k_base token counts for GPT-style prompts, computed locally.
- Agent Framework Picker
Five questions to decide between a plain loop, an SDK, or a framework.
- LLM Cost Calculator
Estimate what an LLM feature costs per request, per day and per month from your own token counts and prices.
- JSON to Zod
Paste a JSON sample or a JSON Schema and get a Zod schema and TypeScript types, in your browser.
- Tool Schema Validator
Check an OpenAI, Anthropic or MCP tool definition for common mistakes and convert it to the other two formats.