What an AI agent actually costs to run

Agents cost several times what a single request suggests, and the gap is almost entirely made of things no framework puts in front of you. This is where it goes, itemised.

The fixed overhead per request

Before your user types anything, every request an agent makes already carries:

• The system prompt.
• Every tool's name, description and full parameter schema.
• The provider's own tool-use preamble, injected whenever any tool is present.

On an agent with a dozen tools this routinely exceeds a thousand tokens. It is paid on every iteration of every loop, whether or not a tool is actually called. Build your configuration in the agent builder and the number is shown directly — for most people it is larger than they expected by a factor of two or three.

What tool definitions cost

Each tool contributes three things to every request. The name is cheap. The description and the JSON schema are not.

A description written as documentation — explaining what the function does internally, listing caveats, giving usage examples — can run 100 tokens. Twelve of those is 1,200 tokens per request before any schema. Three habits fix most of it:

• One precise sentence per description. The model needs to know when to call the tool, not how it was implemented. Caveats belong in the tool's response, not its definition.
• Flatten optional parameters. Nested objects with defaults and descriptions serialise into a surprising amount of schema. Flat parameter lists cost a fraction.
• Remove tools the agent never calls. Check your logs. Unused tools are a permanent tax, and there are almost always two or three.

The provider preamble is the part you cannot remove. Anthropic publishes the figure — several hundred tokens depending on model and tool-choice setting — and it applies whenever any tool is defined at all. It is worth knowing simply so it stops being a mystery in your accounting.

Iterations multiply everything

This is where agent budgets go wrong by an order of magnitude rather than a percentage. An agent permitted ten iterations can make ten billed requests for one user action. Each iteration carries the full fixed overhead plus the accumulated history of the loop so far — which grows the same quadratic way a conversation does, for exactly the same reason: the API is stateless and the history is resent.

So the worst case is not ten times a single request. It is ten times the overhead plus a quadratic term on top. Plan against that number, not the average, because the ceiling is what you authorised. The chat cost estimator models the compounding side; the agent builder multiplies the fixed side by your iteration limit.

A practical note: agents that cannot finish in four passes usually cannot finish in ten either. They just cost more to fail. Lowering a limit from ten to five rarely costs completions and reliably halves the worst case.

Skills as a cost structure

The instinct when an agent handles an edge case badly is to add instructions to the system prompt. That works, and it is the most expensive place to put them, because the system prompt is paid for on every request forever — including the vast majority where the edge case does not arise.

A skill inverts this. Its description stays in context permanently (cheap, a few dozen tokens) while its body loads only when triggered. So the rule is straightforward:

• Needed on most requests → system prompt.
• Needed occasionally → skill.

Teams get this backwards constantly. The skill builder shows the split explicitly: tokens always in context versus tokens loaded on trigger. Seeing the two numbers separately makes the decision obvious in a way that reasoning about it does not.

Cutting it down

1. Measure the fixed overhead first. It is usually the largest single item and the easiest to reduce. Nothing else is worth attempting until you know the number.
2. Cache the prefix. System prompt and tool definitions are identical on every request by construction — a perfect cache prefix, typically at a tenth the rate. See prompt caching explained.
3. Route by difficulty. Most iterations in a loop are mechanical. Run those on a cheap model and reserve the expensive one for the step needing judgement — compare rates in the model price table.
4. Lower the iteration ceiling. Then look at why anything was hitting it.
5. Trim tool descriptions. Tedious, mechanical, and frequently worth several hundred tokens per request.

The general principle underneath all five: in an agent, everything fixed is multiplied by everything variable. Fixed costs that would be trivial in a one-shot product become the dominant line item once they are paid on every iteration of every loop. Start from how to reduce LLM API costs for the levers that apply outside agents too.