Why Your Agent Loop Costs More Than the Model’s Listed Price

Meta description: See why Anthropic agent loop costs, not just Opus or Haiku token prices, drive tool-heavy Claude bills and how to measure savings before swapping models.

Tags: Anthropic, Claude, agent costs, prompt caching, token usage

Featured image: abstract, friendly illustration of a looping agent pipeline with small token nodes, tool icons, and retry arrows; no real people, no logos, no text.

Anthropic agent loop costs are the real budget question for teams building tool-heavy Claude agents. Anthropic's published rate card lists Opus 5.5 input tokens at $4 per million and Haiku 4.5 input tokens at $1 per million, so a simple downgrade looks like a 75% cut. Opus output also costs 4x what Haiku output costs. Yet in many agent runs the bill falls by only a fraction of that because the Messages API loop, repeated tool-result re-injection, and retries dominate spend. The practical takeaways are where tokens go, which levers matter, and what to log before changing the model picker.

Why model swaps miss the bill

Anthropic frames agents as a loop: the model plans, acts through a tool, reads the result, and decides whether to continue. Every step after the first user message either consumes new output tokens or re-sends existing context as input tokens. A planning call charges the full system prompt and tool schemas as input tokens on every turn unless cached. A tool call is cheap to emit, but its result must be read on the next call and goes back in full as input tokens. If a task needs six tool calls, one result is re-read and re-billed on each of the five later calls because the Messages API resends the full conversation history. Retries compound this: if a tool call is malformed or a step is redone, the agent resends the prompt, schemas, and prior results still in context, so one retry can cost more than the original planning call.

Where thinking and tool results raise the bill

Extended thinking adds another cost curve. Thinking tokens are billed as output tokens and tracked separately in usage.output_tokens_details.thinking_tokens. On Opus 5.5 and newer, prior turns' thinking blocks stay in context and are billed again as input tokens on the next call. On Sonnet and Haiku, they are stripped between turns and do not carry forward. Two agents doing the same multi-step task on different model tiers can therefore have meaningfully different totals even before considering base prices.

A worked pattern on Sonnet 5.5

A representative single tool-using agent turn on Sonnet 5.5, built from Anthropic's published rates rather than a specific logged bill, shows the concentration: planning and final synthesis are a small minority, while tool-result re-injection and one retry dominate. Cost scales with turns and carried context, not model smartness or per-token price alone. Anthropic's context-editing example makes this concrete: clearing stale tool results before the next call reduced one turn from 70,000 input tokens to 25,000, a 64% input-token cut without changing model tier, prompt, or task.

Levers that move the bill

Batch processing is the first discount to check: asynchronous, non-interactive requests get a flat 50% discount on input and output tokens across Opus 5.5, Sonnet 5.5, and Haiku 4.5. For background summarization or overnight re-indexing, that discount applies before architecture changes matter.

Model tier still matters: if a task does not need Opus-level reasoning, Sonnet or Haiku can cut input cost by half to a quarter. Prompt caching is often higher leverage for stable system prompts or tool schemas reused across dozens of turns. A cache write costs 1.25x the base input rate for a 5-minute TTL or 2x for a 1-hour TTL; a cache hit costs 10% of the base input rate on most models and as little as 5% on Opus.

Context editing is underused: the clear_tool_uses_20250919 edit type automatically clears oldest tool results after a configured input-token threshold, replacing them with placeholders server-side, so the client does not maintain a separate trimmed conversation copy. The free token-counting endpoint can estimate a prompt, system message, and tool set before sending. That is cheaper than running the architecture and checking the invoice afterward.

Related guidance: Choosing Between Opus, Sonnet, and Haiku: A Cost Framework, Prompt caching and token budgeting: what’s documented vs. exam-tested, The Three Layers of Memory in the Claude Agent SDK, and What to Log Before Your Agent Fails in Production.

What to measure and who should act

The Messages API usage object reports input_tokens, output_tokens, cache_creation_input_tokens, and cache_read_input_tokens separately on every response, plus output_tokens_details.thinking_tokens when extended thinking is active. Logging those four or five numbers per call, broken out by loop step, turns a vague complaint such as our Anthropic bill is higher than expected into a fixable finding, for example that one retry path causes most of a task's token count. If teams already log tool calls and outcomes, adding token counts to the same log line costs almost nothing and shows where the money went.

Agent FinOps looks less like pricing negotiation and more like profiling: the model picker is visible, but the loop is where spend happens. Use this when multi-step Claude agents with tools, retries, or long context dominate spend; skip heavier cache and context-editing work if the workload is mostly one-shot calls or already near the published token floor.

Source note: the underlying analysis, Why Your Agent Loop Costs More Than Its Model Price Tag, was published in Towards AI on Medium.