An AI agent in production is a program that calls a paid API in a loop. That is the whole risk in one sentence. Every reasoning step costs money. Every retry costs money. A bad prompt or a stuck loop costs money until something stops it.
Most agent demos skip this part. The demo runs once, on one input, and the bill is rounding error. Production is different. You run it thousands of times a day, on inputs you did not write. That is where token spend goes sideways.
We have built 10 production products in 7 months. The agents that survive contact with real traffic all share the same boring property. They have hard limits wired in from the first commit. Here is what those limits look like.
Cap the loop, not just the call
The first failure mode is the runaway loop. An agent decides it needs one more tool call, then one more, forever. Each step looks reasonable. The total does not.
Set a max-step count per task. Five steps, ten, whatever fits the job. When the agent hits the ceiling, it stops and returns what it has. It does not get to keep spending because it feels unfinished.
Set a max-token budget per task too. The step count protects you from loops. The token budget protects you from one step that pulls a huge document into context. You want both. They fail in different ways.
Pick the cheap model by default
Not every step needs the expensive model. Routing is a cost lever most teams ignore.
Classify the work first. Simple extraction, formatting, and routing go to a small model. The hard reasoning goes to the large one. A support agent we built answers in 12 minutes, down from 4 hours, and most of its steps run on the cheap model. The expensive model only shows up when the question is genuinely hard.
This is plain engineering. You profile where the cost lands, then you move the easy work somewhere cheaper. Same as any other system.
Cache the parts that repeat
Agents re-send the same context constantly. The system prompt, the tool definitions, the retrieved documents. You pay for those tokens on every call unless you cache them.
Prompt caching cuts the cost of repeated context hard. Put the stable parts at the front. Put the variable parts at the end. The provider charges you full price once and a fraction after that. For a high-traffic agent this is real money, not a footnote.
Meter it like infrastructure, because it is
You cannot guard a number you do not see. Most teams find out about a bad week from the monthly bill. That is too late.
Log token count and cost per task. Tag every call with the agent name and the task type. Then you can answer the question that matters. Which agent, on which input, spent the most this week. Without that, "the AI bill went up" is the entire diagnosis.
Set a daily spend alarm per agent. When spend crosses the line, you get paged, not surprised. This is the same discipline as a CloudWatch alarm on a runaway Lambda. An agent is just another service that can misbehave at 3am.
The bill underneath the agent
The agent's token spend sits on top of your cloud bill. The two compound. We have audited a lot of AWS accounts, and most hide 30 to 60 percent in savings that nobody is watching.
If you have not looked under the hood, start there. Our Cloud Bill Audit is a flat fee and it pays for itself fast. The Well-Architected Review goes deeper on the architecture around the agent. Both are fixed price. You own the findings and we exit.
Build it with the guardrails in
These limits are cheap to add on day one and painful to retrofit. Wiring step caps, token budgets, model routing, caching, and metering into an agent that already serves traffic means touching every hot path. Doing it up front is a few hours.
When we build an agent, the guardrails ship with it. OpenClaw Installation and our RAG Chatbot build come with the spend controls already in place, fixed price, and you own the code.
If you are running an agent in production and the bill makes you nervous, that nervousness is correct. Let's look at it together. Book a free 30-minute call and we'll find where the money is going.