What an AI Coding Agent Actually Costs You in Token Spend at Production Scale

Why the vendor pricing page doesn't answer this

Every LLM provider publishes a per-million-token price. That number tells you almost nothing about what an AI coding agent costs you in practice, because the actual spend is driven by variables the pricing page doesn't show: how much context the agent re-reads every turn, how many tool calls a task takes, whether prompt caching is actually landing, and what "effort" level you're running at. We measure this on our own work, so here's what the real numbers look like.

The building blocks of a coding-agent bill

A single agentic coding task is not one API call — it's a loop: read files, think, edit, run tests, read the output, think again, repeat. Every iteration resends the accumulated conversation history as input tokens, plus whatever new output the model generates. That compounding is where costs actually come from, not the sticker price per token.

• Input tokens — the full conversation so far, resent every turn. This dominates spend on any task longer than a couple of turns.
• Output tokens — what the model actually generates: reasoning (if thinking is on), code, and commentary. Priced at roughly 5x input on most current models.
• Cache reads vs. cache writes — a correctly cached prefix costs about a tenth of normal input pricing to re-read; an uncached prefix costs full price every single turn.

Measuring it properly — not with tiktoken

A common mistake we still see: teams estimate Claude token costs using OpenAI's tiktoken tokenizer. It undercounts Claude tokens by 15–20% on plain text and considerably more on code, because it's a different tokenizer entirely. If you want a real number, count tokens against the actual model:

resp = client.messages.count_tokens(
    model="claude-opus-4-8",
    messages=[{"role": "user", "content": open("large_file.py").read()}],
)
print(resp.input_tokens)

Run this against your own repo's real files before estimating anything — a generic "tokens per line of code" rule of thumb is wrong in both directions depending on language and file structure.

What actually moved our numbers

Across our own agentic coding work, three levers changed cost by far more than model choice did:

• Prompt caching, correctly placed. A cache hit costs roughly a tenth of an uncached read. On a long agentic session with a large repo context re-read every turn, the difference between "caching works" and "caching silently isn't landing" was the single largest cost swing we've measured — often 5–8x on multi-hour sessions. The most common silent killer: a timestamp, a UUID, or non-deterministic JSON key ordering anywhere in the system prompt or tool definitions, which invalidates the cached prefix on every request without ever throwing an error. If cache-read tokens are showing as zero across repeated requests with an identical prefix, that's the bug to find, not a pricing problem.
• Effort level, not model tier. Dropping from the highest effort setting to a middle setting on routine tasks cut token spend meaningfully with no measurable quality loss on anything short of genuinely hard, multi-step work. Reserve the highest settings for tasks that actually need deep reasoning — most day-to-day edits don't.
• Context editing / compaction on long sessions. Without it, a session that runs for hours re-sends its entire accumulated history every turn, and that history is mostly stale tool output the model doesn't need anymore. Clearing old tool results (rather than the whole conversation) kept sessions lean without losing task continuity.

A worked example

Take a moderately complex refactor: touch 15 files, run the test suite three times, fix two failures. In our measurements, that's roughly 30–50 agent-loop iterations. Without caching, each iteration resends the growing conversation at full input price — the total input-token bill for the task can be 10–15x the size of the final diff, purely from re-sending history. With caching landing correctly, the effective input cost drops to a small fraction of that, because only the newest turn is billed at full price each time; everything before the last cache breakpoint is billed at cache-read rates.

The lesson isn't a specific dollar figure — that depends on your repo size, model choice, and task shape — it's that caching health is a bigger cost lever than which model you pick. A well-cached session on a more expensive model can cost less than a poorly-cached session on a cheaper one.

What we'd tell you before you budget for this

1. Measure your own workload — don't extrapolate from someone else's blog post (including this one). Repo size, task shape, and how chatty your agent's tool loop is all change the number by an order of magnitude.
2. Check cache-read tokens before you optimize anything else. If they're near zero on repeated similar requests, fix that first — it's almost always a bug, not a pricing reality.
3. Budget in ranges, not point estimates, for agentic (not single-call) workloads. A single classification call is predictable. An open-ended agentic coding task is not — it can finish in five iterations or fifty depending on how well-specified the task was up front.
4. The best cost lever is a well-specified task, not a cheaper model. An ambiguous prompt that makes the agent re-explore context it already gathered costs more than a clear one on a pricier model.

Scoping an AI coding workflow and want real numbers first?

We benchmark against your actual codebase before recommending a model or architecture — not a generic pricing table. Tell us what you're building and we'll give you a measured estimate, not a guess.