An AI agent's cost is not a fixed line item — it's a variable, self-inflicted number set by how many steps it takes, how much context it drags along, and how many tools it calls before stopping. A single ambiguous prompt can make an agent loop 40 times instead of 4, turning a $0.02 task into a $2 one. Budgeting tokens, steps, and latency ceilings up front is what keeps that variance bounded.
Quick Answer: Agent cost = (steps × tokens per step × model price) + tool-call overhead, and steps are the multiplier that runs away unless you cap them. Set a hard step limit, a token budget per step, and a model-tier ceiling before deployment — not after the first bill.
Most teams treat agent cost like API cost: a per-call price you can look up. That's wrong. A single-call LLM feature has a fixed cost per request — you know it before you ship. An agentic workflow has a distribution of costs, because the agent itself decides how many calls it makes. Anthropic's own guidance on building agents notes that multi-step, tool-using agents can consume "an order of magnitude more tokens" than single-turn tasks — and that's before accounting for a reasoning loop that stalls.
Where Agent Cost Actually Comes From
Agent cost comes from four multiplicative factors: loop length (how many steps it takes), context size (how much history and retrieved data rides along each step), tool calls (each with its own token overhead and possible retries), and model tier (frontier models cost 10-20x more per token than smaller ones). Multiply all four together and small increases compound fast.
Each factor deserves separate scrutiny because they fail independently, and a fix for one doesn't touch the others.
Loop length: the multiplier that runs away
An agent re-plans after every observation. If it doesn't converge — because the goal is ambiguous, a tool returns an unexpected format, or the model second-guesses its own prior step — it keeps looping. This is the core distinction covered in our guide to agent vs. workflow non-determinism: a fixed workflow has a known number of steps; an agent's step count is a random variable, and unbounded randomness is unbounded cost.
- A well-scoped agent task might average 3-6 steps.
- A poorly-scoped one, or one hitting a tool it can't parse, can silently climb past 20-30 steps.
- Each additional step re-sends the accumulated conversation history, so step N costs more in tokens than step 1 — the loop doesn't just add cost, it compounds it.
Context size: every step re-pays the tax
Most agent frameworks resend the full running transcript — prior reasoning, tool outputs, retrieved documents — with every new call, because the model has no persistent memory between calls. That means a 10-step agent with a 4,000-token context isn't a 4,000-token cost; it's closer to 40,000+ cumulative tokens once you sum every step's re-sent history.
Bloated context comes from three habits: dumping entire documents instead of relevant excerpts, keeping full tool-output payloads (like an entire API response) instead of a parsed summary, and never trimming completed sub-tasks out of the running transcript. Each is fixable independently, and none require touching the model or the loop logic.
Tool calls: overhead you don't see in the prompt
Every tool call has its own token cost — the tool definition schema sent to the model, the arguments the model generates, and the result returned — plus latency for the round trip itself. An agent with 8 tools available pays a "which tool, if any" tax on every single step, even steps that don't end up calling one. This is one reason agent action guardrails matter as much for cost as for safety: fewer, better-scoped tools reduce both blast radius and token overhead per decision point.
Retries compound this. A tool call that fails and gets retried by the agent's own error-handling logic silently doubles that step's cost — and if the agent doesn't recognize the failure pattern, it can retry the same broken call several times before giving up.
Model tier: the lever with the biggest single-step impact
Model choice is the most visible cost lever because it's a static, known multiplier — you don't have to wait for runtime behavior to see it. Frontier reasoning models are commonly priced at 10-20x the per-token rate of smaller, faster models. The catch: a cheaper model that loops twice as long to reach the same answer can end up costing more in aggregate than the pricier model that converges in half the steps.
A Simple Cost Model You Can Actually Use
A usable agent cost model doesn't need to be precise — it needs to make the variable inputs visible so you can set limits on them. The formula below treats an agent run as steps times per-step cost, plus tool overhead, which is close enough to reality to plan a budget against.
Estimated Run Cost = steps × (input_tokens_per_step + output_tokens_per_step) × model_rate
+ (tool_calls × avg_tool_overhead_tokens × model_rate)
Walk it with realistic numbers: a support-triage agent averaging 5 steps, 3,000 input tokens and 400 output tokens per step (context grows as it goes), on a mid-tier model at roughly $3/million input and $15/million output tokens, plus 2 tool calls averaging 500 overhead tokens each.
| Component | Value | Approx. cost |
|---|---|---|
| Input tokens (cumulative across 5 steps) | ~15,000 tokens | ~$0.045 |
| Output tokens (5 steps × 400) | ~2,000 tokens | ~$0.030 |
| Tool call overhead (2 calls × 500 tokens) | ~1,000 tokens | ~$0.003 |
| Estimated cost per run (converged) | — | ~$0.08 |
| Same task, agent loops to 25 steps | — | ~$0.40-$0.60 |
That five-to-eight-fold spread between a converged run and a looping one is the entire argument for capping steps. The model rate matters, but it's the step count variance that turns a predictable per-task cost into an unpredictable one — which is exactly the property a fixed workflow doesn't have, per our complete guide to AI agents.
Build this as a spreadsheet, not a precise simulator: log actual step counts and token usage from a pilot batch of runs, take the median and the 90th percentile, and use the gap between them as your real budgeting signal — not the average.
Cost-Control Levers and Their Quality Tradeoffs
Every lever that reduces cost also removes some capability the agent had — the job is picking which capability you can afford to lose for a given task, not finding a free lunch. The table below lays out the common levers side by side so the tradeoff is explicit before you flip any of them.
| Lever | Cost impact | Quality tradeoff |
|---|---|---|
| Hard step limit (e.g. max 8 steps) | High — caps worst-case runaway loops | Agent may terminate before solving a genuinely hard task |
| Token budget per step | Medium — bounds context bloat per call | Truncated context can drop relevant history the agent needed |
| Downgrade model tier | High per-token, but can raise loop count | May need more steps to reach the same answer, partially offsetting savings |
| Reduce available tools | Medium — less "which tool" decision overhead | Agent can't handle edge cases needing the removed tool |
| Summarize/compact context between steps | Medium-high — flattens cumulative re-send cost | Summarization can lose nuance from earlier steps |
| Cache stable context (system prompt, docs) | Medium — avoids re-billing static tokens | Requires framework/provider support for prompt caching |
| Early-exit confidence threshold | Medium — stops once agent is "confident enough" | Risk of premature termination on ambiguous cases |
Numbered checklist for setting your first budget, in the order to decide them:
- Set a hard step cap based on your pilot's 90th-percentile converged run, plus a small margin — not an arbitrary round number.
- Set a per-step token ceiling, trimming tool outputs and stale sub-task history rather than truncating blindly.
- Choose the cheapest model tier that meets your accuracy bar on a held-out test set — validate this, don't assume.
- Define an early-exit condition (a confidence signal or a "no new information" check) so converged runs stop early instead of running to the cap.
- Log every run's step count, token use, and outcome so the budget can be recalibrated as real usage data accumulates.
Latency Is a Cost Too, Just Denominated Differently
Latency isn't separate from token cost — it's the same runaway-loop problem denominated in user-perceived time instead of dollars. Every extra step is another round trip to the model and possibly a tool, and those add up sequentially unless the architecture explicitly parallelizes independent sub-tasks.
A user-facing agent with no latency budget will feel broken long before it's expensive. A 25-step loop that costs $0.50 might also take 40+ seconds wall-clock time — well past the point where most users assume something has failed. Treating step limits as a user experience constraint, not just a finance one, tends to get budgets approved faster internally, since the "agent hung" complaint lands on product before the invoice does.
This is also where autonomy level matters: an agent given full latitude to explore and retry will trade latency and cost for a marginal accuracy gain a human might not even want. Our agent autonomy levels framework is useful here for matching how much independent looping you actually allow to how much the task warrants — a low-stakes classification task rarely justifies the same autonomy budget as a multi-system remediation agent.
Budgeting by Job, Not by Feature
The right budget isn't a single number for "the agent" — it varies by the job the agent is actually being hired to do, which is why treating cost as a per-feature line item undercounts it. A support-triage agent and a research-synthesis agent have wildly different acceptable step counts and token footprints even if they share a codebase.
Mapping the underlying customer job — using something like the jobs-to-be-done framework — helps set a budget that matches the actual value at stake rather than an engineering default copied from another agent. A job worth $50 in saved analyst time can absorb a $2 agent run; a job that fires 10,000 times a day at $0.01 margin cannot. Similarly, mapping where in the customer journey the agent sits — a pre-purchase question versus a post-incident escalation — should inform how much latency and cost variance is tolerable before it damages trust rather than saving it.
Where Prodinja Fits
Budget decisions are easiest to get right when they're set at design time, not discovered after a production bill spikes. Prodinja's Agentic Workflows tool is designed to let you set step and tool constraints directly in the spec — the same levers covered above — so an agent's cost is bounded by the design itself rather than left to whatever the model decides to do at runtime. It's a way to make the budgeting conversation happen before the agent ships, not after the invoice.
Key Takeaways
- Agent cost is variable, not fixed — it depends on loop length, context size, tool calls, and model tier, all of which the agent itself influences at runtime.
- Loop length is the multiplier that runs away, since unresolved ambiguity or unparseable tool output can push step counts from single digits into the dozens.
- Context re-sends compound cost across steps — a 10-step run with a 4,000-token context can add up to 40,000+ cumulative tokens billed.
- Model tier is a known, static lever, but a cheaper model that loops longer can cost more overall than a pricier model that converges fast.
- Every cost-control lever trades away some capability — step caps, token budgets, and reduced tool access all have a quality cost that should be chosen deliberately, not defaulted into.
- Latency is cost denominated in user-perceived time — a runaway loop breaks the experience before it breaks the budget.
- Budget by job and journey stage, not by feature, since the value at stake — not engineering convenience — should set the ceiling.
Frequently Asked Questions
How much does it cost to run an AI agent per task?
It depends heavily on step count and model tier, but a converged multi-step agent task commonly runs from a few cents to under a dollar; the same task looping to its worst case can run 5-10x higher. There's no fixed per-task price — only a distribution shaped by your step and token budgets.
Why do AI agents cost more than a single LLM API call?
Because an agent re-sends accumulated context and reasoning history on every step, and each step is a full model call rather than one. A 5-step agent run isn't 5x a single call — it's closer to 15-20x once cumulative context re-sends and tool-call overhead are counted.
What's the best way to set a token budget for an agent?
Start from real pilot data — log the step counts and token usage of a batch of actual runs, then set your hard step cap and per-step token ceiling near the 90th-percentile converged run, not the average or an arbitrary round number.
Does using a cheaper model always reduce agent cost?
Not necessarily. A smaller model can require more steps or retries to reach the same outcome, and the extra steps can offset or exceed the per-token savings. Validate on a held-out test set before assuming a downgrade saves money in aggregate.
How do step limits affect agent quality?
A hard step limit caps worst-case runaway cost, but it can also cut off a genuinely hard task before it's solved. The fix is usually an early-exit confidence check paired with a generous-but-bounded cap, so easy tasks finish fast and hard tasks fail predictably instead of looping indefinitely.