Which of your AI agents spent the most last month? If the only answer is a single number on the invoice, that is where AI agent costs get out of hand. You cannot cap, tune or question what you cannot see.
The short answer: you control AI agent costs by putting a ceiling on each agent, matching each task to the smallest model that does it well, capping loops and tool calls and tagging every request with the team and agent behind it. Then you look at the numbers once a month. None of it depends on which platform runs your agents.
Why do AI agent costs run away?
AI agent costs run away because an agent is not one model call. It is a chain of calls with no natural stopping point unless someone builds one. A chatbot answers once. An agent plans, calls a tool, reads the result, decides what to do next and calls again. Each request carries a growing pile of everything that came before it.
Six causes are common.
Loops
An agent that cannot finish a task keeps trying. It calls a tool, gets an unhelpful result, rephrases and calls again. Nothing inside the model says "this has gone on too long." A runaway loop is the version people notice. The quiet version is an agent that loops a few extra times on every hard request and never gets flagged.
Retries
Network errors, rate limits and malformed outputs all trigger retries. A retry is a full new request, billed like one. If an integration fails often, a well-meant retry policy can multiply the cost of every task that touches it.
Long context
Context is the text a model reads on each request: the instructions, the conversation so far, any memory, tool results and any documents pulled in. Models are billed by tokens, the small units of text they count. A long context means more tokens on every step. A ten-step task does not read the conversation once. It reads a growing version of it ten times. Pasting whole documents in, retrieving far more passages than the question needs or carrying memory nobody uses makes this worse. Long replies add to it too, because the next step reads them. (Retrieval from your own knowledge bases is optional. When you use it, how much you retrieve affects cost as well as quality.)
The wrong model for the job
Larger models cost more per request and are slower. Many agent tasks do not need them: classifying a message, extracting a field, checking whether a reply follows a template. Running every step on the most capable model available is the easiest way to build an agent and the most expensive way to run one.
No attribution per agent
When all agents share one API key, the provider's invoice shows one number. You can see that spend rose but not which agent, team or workflow caused it, so you cannot fix anything specific.
Metered credit pricing
Some platforms sell usage as credits that different actions consume at different rates. The unit is hard to predict, so the bill is too. All six share one problem: a cost you cannot count in advance is a cost you cannot budget. It also hides the return side, since ROI cannot be judged against a cost you have not measured.
How do you control AI API costs?
To control AI API costs, work on the driver behind each surprise. The table maps each driver to a first control.
| Cost driver | First control |
|---|---|
| Loops | Cap steps per task and stop on repeated tool calls |
| Retries | Limit retry counts and add a delay between attempts |
| Long context | Trim prompts, history and memory and retrieve fewer, better passages |
| Wrong model | Route simple steps to a smaller model |
| No attribution | Tag every request with team and agent |
| Unpredictable pricing | Prefer a stated allowance you can count |
Cap loops and tool calls
Set a maximum number of steps for every task and of calls to any single tool. When an agent hits the cap, it should stop and hand the task to a person, with a short note on what it tried. A cap marks the point where continuing costs more than the task is worth.
Also stop on repetition. If an agent makes the same tool call with the same arguments twice in a row, a third attempt will not help. This catches loops far earlier than a step cap.
Restricting which tools an agent can call shrinks the space for loops. That boundary is covered in how to control what an AI agent can access.
Match the model to the task
Routing means sending each step to the model that suits it. It works best when you start with the cheapest model that passes your tests and move up only where quality drops.
A reasonable pattern is a small model for classification, extraction and formatting and a larger one for steps that need real reasoning or careful writing. Test on your own examples: only a run on your real tasks shows whether a smaller model is good enough.
Write prompts that cost less
Every request pays for its prompt again, so each extra line is billed on every step. Keep the system prompt short and stable: the role, the rules that matter and nothing the agent will not use.
Ask for a fixed, compact output format, such as a few named JSON fields or short bullets, instead of open prose. Cap the output length too. Replies are billed. The next step reads them as context.
Put the parts that never change at the start. Many providers can cache a repeated prompt prefix, so a stable opening can be cheaper to run. Check your provider's rules.
Keep context short
Summarise old conversation turns instead of replaying them in full. Pass tool results through a filter so the agent sees the three fields it needs instead of a whole response. If the agent answers from your documents, retrieve a handful of relevant passages and not whole files.
Decide what the agent remembers
Memory is context the agent carries forward, so it is billed whenever a step reads it. Conversation memory covers the current exchange. Long-term memory carries facts across conversations and grows unless you manage it.
Keep only what later steps need, such as a customer's stated preference and not the conversation that revealed it. For long-term memory, save a short note and not the full exchange. Expire entries that have gone stale. Enable long-term memory only where recall helps.
Limit retries
Use a small, fixed number of retries with a pause between attempts. Log every retry so it shows up in your numbers. If a connector fails often, fix the connector, because a retry policy that hides a broken integration pays for the same failure repeatedly.
How do AI agent budget limits work?
AI agent budget limits work by giving each agent its own ceiling, so one misbehaving agent is less likely to use up the allowance meant for all the others. The ceiling is set per agent and not only per account, because an account-wide limit tells you something went wrong only after the fact, not where.
Three decisions make a budget limit useful.
Pick a unit you can count. A limit in currency is hard to reason about when prices differ by model and change over time. A limit in requests, runs or tasks is something a team can estimate from real workload: roughly how many conversations does this agent handle in a month and how many requests does each take?
Set the number from the job. An agent that answers internal questions for a team of twenty has a very different ceiling from one on a public support channel. Start from the expected volume, add margin for the odd busy month and revisit after the first month of real data.
Decide in advance what happens at the limit. There are three options: the agent stops, it keeps going and alerts someone, or it falls back to a smaller model. A hard stop is the strongest protection, but on a customer-facing agent it means a customer meets a dead end. An alert-only policy keeps service running, but someone has to act on the alert. A fallback preserves service at lower quality. A sensible split is a hard stop for internal and experimental agents and an alert plus a human escalation path for anything customers touch.
Whatever you choose, write it down per agent. The worst outcome is finding out what your limit does by hitting it.
How do you track LLM spend per team?
You track LLM spend per team by tagging every request with who and what caused it, then reporting on those tags. Without that, you have only the provider's invoice, which answers "how much" and never "which."
Four practices get most of the value.
- One owner per agent. Every agent is assigned to a team or a named person. An agent with no owner is the first place to look when spend rises.
- Separate keys or projects. Where your provider allows it, use a different API key or project for each team. This is the cheapest form of attribution and needs no code.
- Request tags. Add the agent, the team and the workflow to the metadata of every call or log them at a gateway between your agents and the model provider. Spend can then be grouped any way you need.
- Cost per outcome, not only per call. Divide the spend by what the agent achieved: tickets resolved, leads qualified, questions answered. The total on its own cannot say whether the spend was worth it.
Cost per outcome also exposes a cheaper model that is not cheaper. If a smaller model needs three attempts where a larger one needs one, the per-call figure hides it.
How should you review AI agent costs each month?
Review AI agent costs once a month, as a short fixed agenda. It stays short if the data is already grouped by team and agent.
A monthly review should answer these questions:
- Which three agents cost the most? Is each one worth it?
- Did any agent reach its limit? Was that the right limit?
- Did any agent use far less than its limit, so the ceiling can come down?
- Were there loops, repeated retries or unusual spikes? What caused them?
- Is any step running on a larger model than it needs?
- Does every agent still have an owner?
Write down one change per agent and check it the following month. Costs drift because nobody looks.
How does Commt handle AI agent costs?
Commt is built around a stated allowance, not a metered bill. The plans, as they are set for launch, sell a monthly number of requests: 5,000 on Entry and 16,000 on Pro, with Enterprise set by contract. You can count a request yourself, so you can compare it with your own workload before you commit.
There are no credits and no metered bill. When a plan runs out, you upgrade. That is a deliberate tradeoff: the allowance is a fixed amount, not unlimited use, so a team with heavy usage needs a higher plan. In exchange, what you pay is known in advance. In our review of credit-metered agent platforms, cost unpredictability was the top complaint. This design is a response to it.
Three more parts of the launch product bear on the controls above:
- A request limit on each agent. The agent create screen ships at launch with a request limit for each agent. The slider starts at 2,000.
- Model access by plan tier. Which models an agent can reach depends on the plan tier. The routing logic for each step, such as a smaller model for simple work, is still yours to design.
- Memory settings on each agent. At launch, the agent create screen starts conversation memory on and long-term memory off. Long-term memory is available on Pro and above.
Commt does not replace these habits. You still need an owner for each agent, a cap on loops and a monthly review. The allowance gives you a stated number to plan them against. For more on how Commt thinks about agents that do only what you allow, see what a private AI agent is.
Start with one agent and one limit
You do not need a cost platform to start. Pick your most expensive agent this week. Give it an owner and a ceiling, cap its steps and tool calls, trim its prompt and memory, move its simplest step to a smaller model and tag its requests by team. Look at the result in a month, then repeat for the next agent.
If you would rather start with a plan whose cost you can count in advance, Commt's early access opens on Monday 9 November 2026. Join the early access list at commt.co and claim 30% off, locked for 12 months. The offer runs until 10 November 2026, 07:00 UTC.