Reading the bill: the economics of one agent task

An agent task is a stack of small charges, not one number. Most of the cost sits in lines you never look at — repeated context, tool definitions, retries — and the one lever that reliably cuts the bill is caching what doesn't change, not asking for shorter answers.

What actually gets billed

Every call bills input tokens (your prompt, file contents, conversation history, tool schemas) and output tokens, at rates that differ by model tier. As of this writing, Claude Opus 5 is $5/$25 per million input/output tokens, Sonnet 5 is $2/$10, and Haiku 4.5 is $1/$5 (Anthropic pricing docs). Tool use adds a fixed tax you rarely see: declaring the bash tool adds roughly 244–325 input tokens per request depending on the model, and the text editor tool adds about 700 — before the tool does anything (same source). An agent that calls five tools a turn is paying that tax five times.

The worked example

Anthropic's own documentation walks through a one-hour Opus 5 session that reads 50,000 input tokens and writes 15,000 output tokens: $0.25 for input, $0.375 for output, $0.08 for session runtime, for $0.705 total. Turn on prompt caching and re-run the same session with 40,000 of those input tokens served from cache: $0.05 for the 10,000 uncached tokens, $0.02 for the 40,000 cache reads, the same $0.375 output and $0.08 runtime — $0.525 total (Anthropic pricing docs). That's the figure above: same output, same runtime, a smaller input line.

Why caching is the lever, not shorter output

Cache reads cost 0.1x the base input price — a 90% discount — while a 5-minute cache write costs 1.25x and a 1-hour write costs 2x (prompt caching docs). That means caching pays off the moment you read it back more than once inside the window: one hit already beats paying full price twice. For an agent that re-reads the same CLAUDE.md, the same repo tree, or the same long system prompt on every turn, that's the single biggest lever available, and it requires no change to what the agent actually does.

Where the money leaks

• Re-reading files every turn. If the agent re-opens files it already saw this session instead of relying on cached context, you're paying full input price repeatedly for the same bytes.
• Long-lived sessions that never reset. A five-minute cache window means a slow back-and-forth (waiting on a human, a long test run) can miss the window and start paying full price again.
• Retries. A failed tool call or a bad edit that triggers a redo multiplies the whole stack — input, output, and tool overhead — not just the output.
• Tool sprawl. Every tool definition you expose adds fixed input tokens to every single call, whether the agent uses that tool or not.

Try it today

1. Pull the usage object from your last few API calls and look at input_tokens, cache_read_input_tokens, and cache_creation_input_tokens separately.
2. Compute what you actually paid using the current per-model rate table, not a mental estimate.
3. If you call the API directly, add a cache_control breakpoint on the stable part of your prompt — system instructions, repo docs — and compare the next run's cache-read count.
4. Count how many tools your agent has registered and drop any it hasn't called in the last week.
5. Set a rough per-task dollar budget before you start a long agentic run, so a retry loop doesn't run unbounded.

Where this breaks

• A 5-minute cache window doesn't help a slow, human-in-the-loop workflow — you'll rewrite the cache more often than you read it.
• The Batch API's 50% discount only applies to asynchronous workloads; an interactive agent session can't use it.
• None of this counts wall-clock or managed-session runtime charges, which bill separately from tokens.

Next: what an agent should never be allowed to do.