A 30-step agent run does not cost thirty times what one step costs. It costs closer to fifteen times more than that — and the reason is the single most important piece of arithmetic in this entire category, which almost no vendor page explains.
Agents are stateless underneath. The model does not remember step 4 when it runs step 5; the framework re-sends the entire conversation — system prompt, every tool call, every result, every intermediate thought — on every single step. The transcript grows, and you pay for all of it again each time. Cost does not scale linearly with steps. It scales with roughly the square of them.
That is why teams budget for an agent and get a bill an order of magnitude larger. The per-token price was never the problem. The re-sending was.
The four things you are actually paying for
- Input tokens. Everything you send the model — dominated by the accumulated transcript, not by your prompt.
- Output tokens. Everything the model generates. Priced substantially higher than input across essentially every provider, and on reasoning models the internal reasoning bills as output too, even though you never see it.
- Tool-call overhead. The APIs it calls, the vector DB it queries, the browser it drives, the server it runs on. Small per call; agents make a lot of calls.
- Retries and failures. The most under-budgeted line by a distance. An agent that dies on step 18 has paid for eighteen steps and delivered nothing. Failed runs bill exactly like successful ones.
The mechanic: why cost grows with the square of the steps
Algebra, rather than invented prices. Say each step adds roughly t tokens to the transcript — the model's reasoning, the tool call it emitted, the result that came back. On step 1 the model reads the system prompt. On step 2, the system prompt plus step 1. On step 10, everything from steps 1 through 9.
Total input tokens across n steps is therefore proportional to t × n(n−1)/2, not t × n.
The intuitive budget — "each step sends about one step's worth of context" — gives you t × n. The real number is larger by a factor of (n−1)/2:
- 10 steps: about 4.5× the naive estimate.
- 30 steps: about 14.5×.
- 50 steps: about 24.5×.
Nothing about the model changed. No price went up. The agent simply took more steps, and each one carried everything before it. It is also why agents get slower as they run: the context they read keeps growing.
The silent multiplier: fat tool results
The biggest cost bomb is a verbose tool. An agent calls an API that returns a 40,000-token JSON blob. That blob now lives in the transcript and is re-sent on every subsequent step. One careless tool, twenty remaining steps, and you have paid for that payload twenty times.
Nobody notices, because it does not look like a cost. It looks like a function returning data.
Output tokens, and the reasoning you never see
Output is the expensive side of the ledger — commonly several times the input rate, though the multiple varies by provider and moves often enough that you should check current pricing rather than trust a number in a blog post.
Reasoning models add a wrinkle: the chain of thought produced before the answer bills as output. A model that "thinks" for two thousand tokens and answers in fifty bills you for both. Often an excellent trade on a hard problem; pure waste on "extract the date from this string."
What actually lowers the bill
Cache the prefix
Every major provider offers some form of prompt caching: the unchanging front of your context — system prompt, tool definitions, few-shot examples, the long document being reasoned over — is cached and billed at a steep discount on subsequent reads. Agents are near the ideal case, because that prefix is identical on every step of a run.
The catch: caching only works on a stable prefix. Put a timestamp or rotating session ID near the top of your system prompt and you invalidate it on every call. Order your context most-static-first. This is frequently the largest single saving available.
Truncate what goes back into the transcript
Do not put raw tool output into the context. Summarise it, filter it, take the fields you need. If a search returns twenty results, feed the model three. The agent needs the answer from the tool, not the tool's entire response body.
Compact the history
Long-running agents should periodically summarise the earlier transcript and drop the raw version. You lose fidelity on old detail; you break the quadratic. Usually a straightforward trade.
Route by difficulty
Most steps in an agent run are trivial: parse this, pick a tool, format that. They do not need a frontier model. Use a small, cheap model for routine steps and escalate only for hard reasoning. Both Claude and ChatGPT ship model families spanning a wide price range precisely so you can do this, and the cheap tier is more capable than people assume.
Cap the loop
Every agent needs a maximum step count and a budget guard that kills the run past a token threshold. Without one, a stuck agent will retry a failing tool call until your credit card notices. Not an optimisation — a seatbelt, and it belongs in place before the first production run.
Ask whether it should be an agent at all
The cheapest agent is the one you did not build. If the workflow is deterministic — when X happens, do Y, then Z — that is a script, or an automation in Make or Zapier AI, running at a fraction of the cost with none of the nondeterminism. Agents earn their price when the path is genuinely unknown in advance. If you can draw the flowchart, you do not need one. Our piece on AI agents: hype vs reality makes the longer version of this argument.
| Cost driver | Why it grows | How it shows up on the bill | The fix |
|---|---|---|---|
| Transcript re-sending | Every step re-reads all prior steps | Input tokens far above expectation | Prompt caching; compact the history |
| Fat tool results | A big payload is re-sent every later step | One workflow costs 10× a similar one | Summarise tool output before it enters context |
| Reasoning tokens | Chain of thought bills as output | Output cost dwarfs input on "simple" tasks | Cheap model for routine steps |
| Retries and stuck loops | Failed runs bill in full | Spikes with no completed work behind them | Max-step cap and a hard budget guard |
| Per-seat platform credits | Priced per task or per action | Predictable — until volume arrives | Re-price against raw API above a threshold |
Swipe the table sideways to see every column →
Platforms that hide the tokens
Tools like Lindy price in tasks, credits, or actions rather than tokens. That is a real feature: predictable billing, no surprises, no engineering time spent on caching strategy. You are paying a markup for someone else to absorb the volatility above.
The economics flip with volume. At low volume a credit-based platform is usually cheaper in total cost than raw API access, because your engineering time is not free. At high volume the markup compounds and the raw API wins decisively. The mistake is not picking one — it is never re-checking after volume changes. Vendors do not email you when you cross the line where their pricing stops being a good deal.
Watch for credits that are not equal: a "task" may mean one action or one entire multi-step run depending on the vendor's definition, and those definitions are where the margin lives. The glossary covers the terminology these pricing pages lean on.
A budgeting rule of thumb
Before you build, estimate typical steps × average transcript size × price per million input tokens, then multiply by three — a rough allowance for retries, for runs that go long, and for the tool result that turns out far bigger than your happy-path example.
Then run a hundred real tasks with logging on and replace every estimate with a measured number. Agent cost is not something you can reason about from a pricing page. Set the budget cap before, not after.
FAQ
How much does it cost to run an AI agent?
There is no single figure, because cost depends on how many steps the agent takes and how much context it accumulates, not on a per-message price. The mechanic that matters: the full transcript is re-sent on every step, so a 30-step run costs roughly fifteen times a naive per-step estimate. Budget by measuring real runs, not by reading a pricing page.
Why are my AI agent costs so much higher than expected?
Almost always context re-sending, compounded by a verbose tool. Each step re-reads the entire conversation so far, so input tokens grow with the square of the step count, and any large tool response gets re-billed on every subsequent step. Check for a tool returning a big raw payload into the transcript — that single issue explains most surprise bills.
Does prompt caching really reduce agent costs?
Substantially, when your context has a stable prefix — and agents usually do, because the system prompt and tool definitions are identical on every step of a run. Cached input is billed at a steep discount by the major providers. The common mistake is putting a timestamp or session ID near the top of the prompt, which invalidates the cache on every call.
Is it cheaper to use a platform like Lindy or Zapier, or the raw API?
At low volume, the platform, once you count your own engineering time. At high volume, the raw API, because the platform's per-task markup compounds. The failure mode is choosing once and never revisiting it — re-run the comparison when your volume changes materially.
Can I use a cheaper model to save money on agents?
Yes, and it is one of the highest-leverage changes available. Most steps in an agent run are routine — pick a tool, parse a result, format output — and do not need a frontier model. Route those to a small model and escalate only the hard reasoning steps. Just measure the failure rate, because a cheap model that retries three times is not cheap.
The teams that keep agent costs sane are not the ones with the best negotiated rate. They are the ones who cap the loop, cache the prefix, and stop the transcript from swallowing their budget. Compare what is out there in the AI agents and AI automation tools categories, check the AI tools buying guide before you commit, and if you are costing this out for a young company, the startups use-case page is the place to start.