Nobody told you the agent would cost that much

The demo cost a few cents to run, so you shipped it. Then the bill came, and it had more digits than you expected. Nothing was broken. The agent worked exactly as designed. That is the part worth understanding, because agent costs surprise almost everyone, and the reason is structural, not a mistake.

Why the intuition is wrong

You priced the agent by running it once. But an agent is not one API call. It is a loop, and the loop has a way of multiplying that a single call never shows you.

Three things drive the multiplication. First, context is re-sent on every turn: each step in a conversation usually resends the whole history, so a ten-step task can send the growing transcript ten times over. Second, retries: a failed tool call or a malformed response triggers another attempt, and another. Third, verbose tool output: a tool that returns a large blob of text feeds that entire blob back into the next model call, and the next.

Put those together and a task that looked like one cheap call becomes dozens of increasingly expensive ones. The worst case is a loop that does not terminate cleanly, quietly running up spend until something stops it.

Diagram of an agent loop where cost compounds with each iteration around the cycle

Where the money actually goes

Before you can control cost, you have to see it, and the headline number on the bill does not tell you which feature caused it. The spend hides in a few predictable places:

The re-sent context, which grows with every turn of a long task. The retry paths, which are invisible on the happy path and only fire when things go slightly wrong. The multi-agent conversations, where two or more agents talking to each other can generate far more calls than a human ever requested. And large tool results, which quietly inflate the size of every subsequent call in the chain.

The controls that work

Good news: each cause has a matching control, and none of them require a different model.

Cache the stable parts of the prompt. If a large system prompt or a fixed set of instructions is sent on every call, prompt caching lets the provider reuse it instead of reprocessing it each time. For workloads that resend the same preamble repeatedly, the major model providers document real cost reductions from caching. It is often the single highest-leverage change.

Route by difficulty. Not every step needs your most capable, most expensive model. Use a smaller, cheaper model for the easy steps, classification, extraction, simple formatting, and reserve the expensive one for the reasoning that actually needs it.

Set hard ceilings per session. Cap the number of steps and the total tokens a single task is allowed to consume. When it hits the ceiling, it stops and reports, rather than running into the night. This one control turns a runaway loop from an open-ended bill into a bounded one.

Detect loops. Watch for the agent repeating the same action or circling without progress, and break the cycle. A loop that cannot make progress should be ended, not funded.

Trim tool output. Do not feed an entire large result back into the model when a summary or the relevant slice would do. Smaller tool outputs mean smaller, cheaper subsequent calls.

LLM provider usage dashboard showing token consumption and spend over time

Cost control is reliability in disguise

Here is the reframe that makes this easy to prioritize. The runaway loop that burns your budget is the same runaway loop that hangs your user’s request. The uncapped retry that inflates the bill is the same retry that leaves someone staring at a spinner. Every control that bounds cost also bounds latency and failure.

So this is not penny-pinching. Token ceilings, loop detection, and difficulty routing make the agent both cheaper and more dependable at the same time. You are not trading quality for savings. You are removing the failure mode that produced both the bad experience and the big number.

Start with visibility

If you take one thing from this, make it observability. Attribute spend to features, so you know which part of the product is expensive and why. You cannot control a cost you cannot see, and most surprise bills are simply costs that were never measured until they arrived.

Building agents that are predictable in both spend and behavior is core to what NukyLabs does. If your agent’s bill is bigger than its value, the fix is usually a few of these controls applied in the right places, and that is a defined piece of work.

Facing this in your own build?

NukyLabs helps founders take AI-generated apps, agents, and automations from a working demo to something that survives real users. If any of the above hit close to home, we can scope it with you.

Get a free consultation →or message us to talk through your project.

References

  1. Anthropic: Prompt caching
  2. OpenAI: Prompt caching

Leave a Comment

Your email address will not be published. Required fields are marked *

WhatsApp Messenger
Scroll to Top