Measuring AI Coding Agent Token Cost: What One Task Really Costs (2026)

There are two well-worn conversations about AI coding spend in 2026. One is the policy conversation, caps, tiers, chargeback, covered in the cost-per-engineer FinOps playbook. The other is the news conversation, the Microsoft and Uber blowups, covered in the budget-bomb postmortem. This is neither. This is the question that comes before both of them and that almost nobody answers cleanly: how much does a single agentic task actually cost, and how do you measure it?

It's the question all over Hacker News ("The Costs of Claude Code: Token Usage, Limits, Optimization"; "Ask HN: Opus 4.7, is anyone measuring real token cost on agentic tasks?") and Reddit ("How much does Opus 4.7 actually cost per 1M tokens"; "a library that tracks LLM API costs and finds wasted spend"). The headline price card is published. The thing nobody can find is the bridge from $5/$25 per 1M tokens to what this PR cost me. That bridge is the whole point.

Why agents burn tokens super-linearly

Here is the mechanic that everyone underestimates. An LLM is stateless. The agent runtime, Claude Code, Cursor's agent mode, your homegrown loop, is what makes it feel like a conversation, and it does that by re-sending the entire context on every turn. Turn 1 sends the system prompt and your request. Turn 2 sends all of that again, plus the assistant's turn-1 reply, plus whatever the tool calls returned. Turn 8 sends everything from turns 1 through 7. The context isn't reused server-side for free; you pay input tokens for the whole transcript, every turn.

That means cost doesn't scale with the number of turns. It scales with the sum of the running context across turns, which, because context only grows, is roughly quadratic in task length. Worked example, using Claude Opus 4.7 at $5/1M input and $25/1M output:

• Base context (system prompt + repo map + request): 5K tokens.
• Each turn appends ~3K tokens of new content (the assistant's plan/edit plus a tool output, a file read, a test run, a grep result).
• Each turn produces ~800 output tokens.
• The task runs 15 turns before it lands.

Add up the input charged across all 15 turns and you get 390,000 input tokens for a task whose final context is only 47K. You paid for the prefix fifteen times over. Total: ~$2.25 for one task. If you'd naively estimated "15 turns × 5K context = flat" you'd have guessed $0.68, you'd be off by 3.3x. This is the single biggest reason internal cost models are wrong: they linearize a super-linear curve.

Table 1: where the $2.25 goes (15-turn Opus 4.7 task)

Turn	Running context (input tokens)	Input charged this turn	Cumulative input
1	5,000	5,000	5,000
5	17,000	17,000	50,000
10	32,000	32,000	162,500
15	47,000	47,000	390,000

The lesson in one line: a task that takes twice as long doesn't cost twice as much, it costs closer to four times as much. Any measurement system that reports cost per request, per call, or per seat will hide this. You have to measure cost per task to see it.

What a single agentic task actually costs

Take that $2.25/task number and scale it to a working engineer. A backend engineer leaning on agent mode realistically kicks off 15-25 agentic tasks a day, generate the endpoint, write the migration, fix the failing test, refactor the helper, chase the flaky CI. Call it 20 tasks/day over 22 working days:

Usage profile	Tasks/day	Monthly cost (Opus 4.7, uncached)	Monthly cost (with prompt caching)
Light (Chat + occasional agent)	10	$495	$161
Standard (agent-mode daily driver)	20	$990	$321
Heavy (refactors, platform work)	40	$1,980	$642

These aren't theoretical numbers. They are the arithmetic explanation for the empirical $500-$2,000/engineer/month band Uber observed across a ~4,000-engineer rollout, and for why Microsoft cancelled its internal Claude Code program after a six-month overrun. The standard profile lands at $990, squarely in the middle of the observed range. The headline price card was never wrong; the consumption shape was just bigger than anyone modeled.

Why per-seat pricing hides all of this

Cursor Business is $40/seat/month. Copilot Enterprise is $39/seat. Those numbers were set on the assumption that the median engineer would never approach the marginal model cost bundled into the seat. At $2.25/task, a $40 seat's worth of model cost is consumed after ~18 agentic tasks, less than a single day for an agent-mode daily driver. Everything after task 18 is either eaten by the vendor (until they re-price, which they all did) or billed to you as overage. The seat price is a floor, not a cap, and it tells you nothing about which engineer, which repo, or which task is driving the bill. The per-seat invoice is the least useful artifact in the entire stack, it's a flat number that obscures a distribution spanning two orders of magnitude.

Where the tokens leak

Once you can see cost per task, the same five leaks show up in almost every team. Ranked by how much money they waste:

• Runaway loops. The agent gets stuck, can't make a test pass, keeps re-reading the same files, keeps re-trying the same edit. Each iteration re-sends the now-bloated context. A loop that should have ended at turn 8 and instead grinds to turn 30 doesn't cost 4x more, it costs ~14x more because of the quadratic. This is the single most expensive failure mode and it's invisible without per-task turn counts.
• Re-reading large files. An agent that dumps a 2,000-line file into context, then re-reads it three turns later because it lost track, pays for those 25K tokens every subsequent turn. Multiply across a session and a single fat file can dominate a task's bill.
• No prompt caching. The system prompt, repo map, and stable file contents are identical turn-to-turn. Without caching you pay full input rate ($5/1M) for them on every turn; with caching the cached read is $0.50/1M, a 90% discount on the repeated prefix. In our 15-turn example, caching the prefix drops the task from $2.25 to $0.73, a 68% cut, with zero behavior change. See the prompt-caching cost-optimization playbook for the breakpoint mechanics.
• Verbose tool outputs. A tool that returns an entire 500-line log when the agent needed three error lines injects garbage into context that you then pay to re-send every remaining turn. Tool output size is an input-cost multiplier, not a one-time cost.
• Silent retries. Network blips, rate-limit backoffs, and partial-response retries can re-send a full-context request that already succeeded once. These never show up in turn counts the engineer sees, but they hit the token meter.

Every one of these is measurable, and none of them is visible in a seat count or even in a monthly token total. You only catch them with per-task attribution, which is the whole reason to instrument in the first place.

Two of the most expensive leaks above, re-reading files and re-sending context after the agent loses track, share a root cause: the agent has no durable memory, so every turn it re-establishes what it should already know. A persistent memory layer like memnode lets the agent record decisions and conventions once and recall them by key in later turns and sessions, instead of paying to re-read and re-send the same context. It's the structural complement to per-task metering: metering shows you the leak, memory closes it.

How to instrument agentic token spend

The goal is a base ledger where every model call is one row, and a task ID ties the rows of one agentic task together. Everything downstream, cost per task, per engineer, per repo, leak detection, is an aggregation over that ledger.

What to log on every call

Six fields, non-negotiable:

• model, rates vary 10x between tiers (Opus 4.7 at $5/$25 vs a mid-tier model); a token count without a model name is uncosteable.
• input tokens / output tokens / cached tokens, three separate counters. Cached reads bill at ~10% of input; collapsing them into one "tokens" number makes the caching leak invisible and overstates cost by up to 3x on cache-heavy loops.
• task_id, the join key. Without it you have calls; with it you have tasks. This is the field that turns a $5/$25 price card into "this PR cost $2.25."
• engineer / repo, the attribution dimensions. Engineer maps to the cost-per-engineer view that finance wants; repo maps to "which part of the codebase is expensive to work on," which is the more actionable signal.
• turn index, within a task. This is what surfaces runaway loops: a task with 30 turns is a red flag regardless of total cost.
• timestamp, for burn-rate projection and near-real-time alerting.

A row looks like this:

{
  "task_id":     "agent-7f3a9c",          // joins all calls in one task
  "engineer":    "eng_412",
  "repo":        "payments-service",
  "turn":        9,
  "model":       "claude-opus-4-7",
  "input_tokens":       32000,            // full-price input this turn
  "cached_tokens":      29000,            // prefix read from cache (~10% rate)
  "output_tokens":      820,
  "cost_usd":           0.1086,
  "timestamp":   "2026-05-28T14:22:11Z"
}

Three places to capture it

You can write that row from one of three layers, same as any LLM metering problem:

• SDK / wrapper (for in-house agents): wrap the Anthropic/OpenAI/Google SDK call; the usage object on every response already returns input_tokens, output_tokens, and cache_read_input_tokens. Stamp the task ID from your loop's context and write the row. Zero added latency, but only works for code you control.
• Proxy (for vendor tools like Claude Code or Cursor): route the tool's traffic through an internal LLM proxy (LiteLLM, Helicone, Portkey, or a small FastAPI relay). The proxy reads usage off the response and writes the ledger. This is how you meter tools whose source you don't own. The task ID is the hard part, derive it from the session/conversation ID the agent runtime sends.
• Vendor export (coarse fallback): Anthropic Workspaces usage CSV, OpenAI usage API, Cursor admin API. These give you per-day, per-key totals, enough for a monthly per-engineer number, but they lack the task ID, so they can't see super-linear loops or per-task cost. Use them to reconcile, not to optimize.

From ledger to cost-per-task dashboard

With the ledger populated, the views that actually change behavior are: cost per task (so an engineer sees "that refactor cost $11, the loop ran 34 turns" and learns to scope tighter), cost per repo (so you find the module that's expensive to work in, usually one with no tests and huge files), cost per engineer over time (the finance view, but driven by real tasks instead of a flat seat count), and a runaway-loop alert (fire when a single task crosses N turns or $X, so a stuck agent gets killed at turn 12 instead of turn 40).

The schema above is richer than UsageBox's billing-meter event on purpose. Keep task IDs, repo names, cache breakdowns and runaway-loop diagnostics in the tracing/analytics system that can query those dimensions. If you also need an independent billing-grade quantity, UsageBox can receive the numeric token or computed-cost value for the customer and explicit usage stream, dedupe retries, retain the raw accepted event, and roll that quantity up monthly. The two layers complement each other; UsageBox does not replace the dimensional agent telemetry described above.

The number to leave with

One realistic agentic task on Opus 4.7 costs about $2.25 uncached and $0.73 cached. The gap between those two numbers is 68% and requires no change to what the agent does, only that you measure it and turn caching on. The gap between $2.25 and the $0.68 you'd have naively budgeted is the super-linear surprise that turned into Microsoft's cancellation and Uber's blown 2026 budget. You cannot manage either gap from a per-seat invoice. You manage them by logging six fields on every call, joining on a task ID, and watching cost per task. Measure first; cap second.

Related reading

• Capping AI Coding Cost Per Engineer: the FinOps Playbook, the policy layer that sits on top of this measurement layer (tiers, auto-throttle, chargeback).
• The Microsoft & Uber Claude Code Budget Bomb, the postmortem on what happens when you don't measure agentic spend until the invoice arrives.
• Prompt Caching Cost Optimization (Claude / GPT / Gemini), the single biggest lever on agent-loop cost after measuring it.
• GPT-5.5 vs Gemini 3.1 vs Claude Opus 4.7: Pricing (May 2026), the per-1M price card behind every cost number in this article.