Agent cost control and loop limits
Agents cost much more than chat because every step is a model call that resends the instructions, tool definitions and growing history, and a single task can take dozens of steps. Control cost by design: hard limits on steps, tokens, money and time per task, routing simple requests to cheaper models or no model at all, caching, trimming tool results and history, giving each agent only the tools it needs, and tracking cost per task and per user from day one. Most runaway bills come from loops nobody limited.
Why agents are expensive
A chat answer is one model call. An agent task is many: plan, call a tool, read the result, decide the next step, call another tool, and so on. Each call sends the system prompt, every tool definition and everything that has happened so far in the task, so the input grows on every step.
Anthropic reported that in their data, agents typically used about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more. That is fine when the task is worth it, like replacing an hour of a person's work, and wasteful when an agent does what a script or a single call could do.
Where the money goes
- The model: input and output tokens on every step, with reasoning tokens if you use a reasoning model.
- Context growth: history and tool results resent on every step.
- Tool definitions: sent with every call, whether used or not.
- Retries and failures: steps that fail and repeat.
- Loops: the agent repeating the same action without progress.
- Tools themselves: paid APIs, search, compute for code execution.
The pricing page shows the math for history and agents.
Hard limits
Every agent needs limits that code enforces, not the model.
- Maximum steps per task.
- Maximum tokens or money per task.
- Maximum time per task.
- Maximum tool calls of each type, for expensive tools.
- Per-user and per-day budgets, so one user or one bug can't spend everything.
When a limit is hit, the agent stops, saves its state, and returns what it did and what's left, instead of failing silently.
class Budget:
def __init__(self, max_steps: int, max_usd: float) -> None:
self.max_steps, self.max_usd = max_steps, max_usd
self.steps, self.spent = 0, 0.0
def charge(self, cost_usd: float) -> None:
self.steps += 1
self.spent += cost_usd
if self.steps > self.max_steps:
raise RuntimeError(f"step limit {self.max_steps} reached")
if self.spent > self.max_usd:
raise RuntimeError(f"budget ${self.max_usd} exceeded (${self.spent:.4f})")
budget = Budget(max_steps=10, max_usd=0.05)
try:
for step_cost in [0.004] * 20:
budget.charge(step_cost)
except RuntimeError as stop:
print("stopped:", stop, "after", budget.steps, "steps")
Loop detection
Agents sometimes repeat themselves: calling the same tool with the same arguments, or alternating between two actions without progress. Detect it by tracking recent actions, and when the same call repeats two or three times, stop the loop, tell the model, or escalate to a person.
Route before you run
The LLM call is usually the most expensive part of a request, so decide early whether a request needs it, and which model.
- Answer from a cache when the same question has been answered.
- Use rules or a script for requests that follow known patterns.
- Send simple requests to a small, cheap model, or an open-source model you run yourself.
- Send only complex requests to a large model or an agent.
A small router model or simple rules in front of the agent can cut cost dramatically when most requests are simple.
Reduce tokens per step
- Trim tool results to what the agent needs.
- Summarise or clear old steps from the history.
- Give each agent only the tools it needs, with concise descriptions.
- Keep the system prompt and tool definitions stable and first, so prompt caching applies.
- Use a cheaper model for simple steps, like extracting a value from a tool result, and the strong model only for planning and hard decisions.
- Avoid reasoning models for steps that don't need reasoning.
Track cost per task
Log the tokens and cost of every model call with the task ID, user and agent, and look at:
- Average and worst-case cost per task.
- Cost per successful task, because failed tasks cost money too.
- Which tools and steps use the most tokens.
- Cost per user and per customer.
Set alerts on unusual spend, and a hard spending limit with your model provider as the last line of defence.
Is the agent worth it?
Compare the cost per successful task with the value of the task. If an agent costs ₹40 to resolve a support ticket that took a person 20 minutes, it may be a good deal. If it costs ₹40 to answer a question a ₹0.10 single call could answer, the design needs to change. And if a script can do it for nothing, use the script.
From the floor
In the customer support agent, I explained routing as a cost decision first: LLM inference is the most expensive step in the whole process, so the router decides what kind of query it is and sends it to the right place, the cache, retrieval, a small open-source model like Llama, or the large model, because I can't call OpenAI's API every time a user sends a query in a product.
On day 1 of Build30, we made the first LLM call and built a token tracker in the same session, because tokens have limits on free tiers and paid APIs charge per token, and once you track tokens from the first call, you design for cost from the start. For agents, the same tracker logs every step with the task it belongs to.