How to control LLM costs in AI agent workflows

A single LLM call is cheap and easy to reason about. An agent workflow is neither. The moment you chain calls, add a retry policy and let a model decide how many times to loop, the cost stops being a number you can read off a pricing page and becomes a distribution you have to estimate.

That gap is where fixed-price AI projects lose their margin. This guide covers how to put a number on a workflow before it executes, and which controls actually prevent overspend rather than merely reporting it.

Why agent costs are unpredictable

Traditional software has a cost per request that is essentially flat. Agent workflows do not, for three structural reasons:

• Token volume depends on content, not on requests. Two users running the identical workflow can differ 20× in cost because one pasted a 40-page contract and the other pasted a paragraph.
• Control flow is decided at runtime. A ReAct-style loop runs until the model says it is done. Nothing in the code caps that at three iterations unless you wrote the cap yourself.
• Context accumulates. In a naive loop, every iteration re-sends the entire conversation. Ten iterations of a growing context is not 10× the first call — it is closer to quadratic.

The four cost multipliers

When a workflow costs 30× what was quoted, it is almost always one of four things. In rough order of how often they cause damage:

1. Unbounded loops

An agent that re-plans until it is satisfied has no natural stopping point. A maximum iteration count is not a nice-to-have; it is the single most important number in the workflow. Set it explicitly, and decide what happens when it is hit — fail loudly, or degrade to a cheaper deterministic path.

2. Retries on the wrong errors

Retrying a rate-limit error is correct. Retrying a malformed-output error with the identical prompt usually just pays twice for the same failure. Separate transport retries from semantic retries, and cap the second kind at one or two attempts with a modified prompt.

3. Context re-sending

If each step passes the full history forward, you pay for the same tokens repeatedly. Summarise between phases, pass structured state instead of raw transcripts, and only re-send documents to the step that actually needs them.

4. Oversized models on trivial steps

Classification, routing, extraction and formatting rarely need your most expensive model. A workflow with one heavy reasoning step and six light steps should not use the same model for all seven.

Pricing a workflow before you run it

You can estimate a workflow statically, without executing it, if you have three things per step: the model, an expected input-token count and an expected output-token count. The arithmetic is unremarkable — the discipline of doing it before the project is quoted is what pays.

step_cost = (in_tokens  / 1M × price_in)
          + (out_tokens / 1M × price_out)

run_cost  = Σ (step_cost × expected_iterations)
p95_cost  = Σ (step_cost × max_iterations)

Then compare p95_cost against the price you are charging. If a single run at p95 consumes more than a few percent of the project fee, the workflow needs restructuring, not a bigger budget.

Guardrails that actually hold

There is a meaningful difference between a dashboard that reports overspend and a control that prevents it. Reporting is a lagging indicator; by the time it turns red, the money is gone. The controls worth building are the ones enforced in code:

• Per-run ceiling. A hard token or dollar budget for a single execution. When it is exhausted, the run stops rather than continues.
• Per-tenant daily cap. A rolling 24-hour limit per customer or workspace, so one pathological input cannot drain the month.
• Iteration caps at every loop. Not one global cap — one per loop, because loops nest.
• Model allow-lists per step. Prevents a config change from silently promoting a cheap step to an expensive model.
• Fail closed. If the cost meter itself is unavailable, the workflow should refuse to run, not proceed unmetered.

What to watch after launch

Three numbers are enough for most teams, and all three are distributions rather than averages:

• Cost per completed outcome — not per API call. A workflow that halves its call count but doubles its failure rate got worse.
• Iteration count distribution. A rising tail is the earliest warning that inputs have drifted from what you designed for.
• Share of spend by step. If one step is 80% of the bill, that is the only step worth optimising.

Cost control on agent workflows is not primarily an optimisation problem. It is a design problem: decide the ceiling first, then build the workflow that fits under it.