Measurements · 2026-09-05 · 1,315 words · 6 min read

What one coding task costs: tokens, dollars, minutes, three ways

A method for costing an agent task across an interactive session, a headless run, and a cheaper model, with a price calculator and a dataset of published numbers.

cost tokens pricing prompt caching method

You get a method for putting a dollar figure on one coding task done three ways, a calculator that reproduces the vendors' own worked examples to the cent, and a dataset whose rows are published numbers with their sources. What you do not get is a measurement I did not make. The rows for your own runs are the ones the method tells you how to collect, and the dataset leaves them out rather than invent them.

The three approaches

A task is the same task whichever way it is done: a paragraph-sized change with a test. The three approaches are the three ways people actually run agents.

1. Interactive session. You open the harness, describe the task, watch, and correct. Context accumulates across turns, and prompt caching does most of the work of making that affordable.
2. Headless single shot. One non-interactive call with a permission mode and a turn or dollar cap. No corrections; the run either lands or it does not.
3. Headless with a cheaper model. The same call routed to a smaller model, or with the expensive model reserved for planning and a cheaper one for edits.

The columns that make the three comparable are the ones every vendor reports: input tokens, cache-write tokens, cache-read tokens, output tokens, and the wall time the API was busy. Dollars are derived from those five and a price table, and minutes come from the harness's own duration fields.

The price table, dated

The Claude pricing page on 2026-09-05 lists, per million tokens: Claude Opus 5 at $5 input and $25 output, Claude Sonnet 5 at $2 and $10, and Claude Haiku 4.5 at $1 and $5. Prompt caching multiplies the base input price: a 5-minute cache write costs 1.25x, a 1-hour write 2x, and a cache read 0.1x. The page states that a cache hit "costs 10% of the standard input price, which means caching pays off after one cache read for the 5-minute duration." The Batch API halves both input and output prices. The FAQ on the same page gives the rule of thumb the calculator uses for estimates: "1 token is approximately 4 characters or 0.75 words in English."

The OpenAI pricing page on the same day lists gpt-5.5 at $5.00 input, $0.50 cached input, and $30.00 output; gpt-5.4 at $2.50, $0.25, and $15.00; gpt-5.3-codex at $1.75, $0.175, and $14.00; and gpt-5-mini at $0.25, $0.025, and $2.00. Those cached-input prices are also one tenth of base input, so the same arithmetic applies.

Prices move. The calculator carries the read date as a constant and prints it with every result, so a stale table announces itself.

Two published worked examples, reproduced

The pricing page contains a worked example: "A one-hour coding session using Claude Opus 5 that consumes 50,000 input tokens and 15,000 output tokens" costs $0.25 for input and $0.375 for output, plus a session-runtime line item that applies only to the managed-agent product and that I exclude. The page then reruns it with caching: "If prompt caching is active and 40,000 of the input tokens are cache reads," the input splits into $0.05 for the 10,000 uncached tokens and $0.02 for the 40,000 cache-read tokens, with output unchanged at $0.375.

The Claude Code costs page shows a /usage block from a real session:

Total cost:            $0.55
Total duration (API):  6m 20s
Total duration (wall): 6h 33m 10s
Total code changes:    0 lines added, 0 lines removed
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

That block is the most instructive published number I know of. Almost all of the input, 940,000 tokens, was served from cache; the fresh input was 1,200 tokens. At Sonnet 4.6 list prices from the same pricing page ($3 input, $0.30 cache read, $3.75 cache write, $15 output), the calculator gives $0.5526, which rounds to the displayed $0.55. The API was busy for 6 minutes 20 seconds inside a session that stayed open for six and a half hours.

What ran here: on 2026-09-05, Python 3.13.12 on Windows, the shipped calculator's self-test:

ok   pricing page: 50k in + 15k out on Opus 5 = $0.25 + $0.375: computed $0.6250 expected $0.625
ok   pricing page: 10k in + 40k cache read + 15k out = $0.05 + $0.02 + $0.375: computed $0.4450 expected $0.445
ok   costs page /usage block (rounded display values): computed $0.5526 expected $0.550

The third check passes within a cent because the displayed token counts are rounded to one decimal of a thousand. Then the same 50,000-in, 15,000-out shape priced on other models, which is approach three in one line each:

claude-sonnet-5: 50000 in, 0 cache write, 0 cache read, 15000 out -> $0.2500
claude-haiku-4-5: 50000 in, 0 cache write, 0 cache read, 15000 out -> $0.1250
gpt-5.3-codex:   50000 in, 0 cache write, 0 cache read, 15000 out -> $0.2975

So for that token shape, the Opus-to-Sonnet step is 2.5x and the Opus-to-Haiku step is 5x, straight from the list prices. Whether the cheaper model lands the task is the question the price table cannot answer, which is why the method records an outcome column.

Estimating before you run

The calculator can also estimate a prompt's input tokens with the chars/4 heuristic. I ran it on a 230-character task description of the kind used in the CLI tutorial:

sample_prompt.txt: 230 chars -> ~58 tokens (chars/4 heuristic)
claude-sonnet-5: 58 in, 0 cache write, 0 cache read, 800 out -> $0.0081

Less than a cent, and also nearly meaningless, because the prompt is never the cost. The pricing page's tool-use table shows why: declaring tools adds a system prompt of 354 tokens on Claude Sonnet 5 before a single file is read, and every file the agent opens, every command's output, and every prior turn is input again on the next call. The costs page states this directly: "Claude Code sends your full conversation with every request, and each time Claude uses tools it sends another request carrying that batch of tool results." The 940,000 cache-read tokens in the /usage block are that mechanism over an afternoon. The heuristic is for sanity-checking a spec's size, not for predicting a session.

Reading the harness's numbers

The three approaches produce their numbers in different places. An interactive Claude Code session shows them in /usage; the costs page says the dollar figure "is an estimate, so for authoritative billing see the Usage page" in the console. A headless run with --output-format json returns a payload that, per the headless docs, "includes total_cost_usd and a per-model cost breakdown," and "Both figures are client-side estimates and can differ from your actual bill."

The Agent SDK cost-tracking page adds two caveats that change what you record. First, "total_cost_usd and costUSD fields are client-side estimates, not authoritative billing data," computed "from a price table bundled at build time." Second, the fields disagree about subagents: usage "Counts only the top-level agent loop, so tokens consumed inside subagents are not added," while total_cost_usd and modelUsage include them. If approach three delegates edits to a cheaper subagent, the usage field will undercount, and the method has to take its tokens from the per-model breakdown instead.

For the per-developer scale, the costs page gives the only published aggregates I have: "the average cost is around $13 per developer per active day and $150-250 per developer per month, with costs remaining below $30 per active day for 90% of users." Those are averages across enterprise deployments, not task costs, and they are in the dataset labelled as such.

The dataset

_README for what-one-coding-task-costs-tokens-dollars-minutes.csv
row_id              short id; ex1..ex3 are published worked examples, avg1..avg2 are published aggregates
source              URL of the page the row was copied from
model               model id as the source names it, or "unspecified" for aggregates
input_tokens        uncached input tokens
cache_write_tokens  tokens written to the prompt cache (5-minute rate assumed)
cache_read_tokens   tokens read from the prompt cache
output_tokens       output tokens
price_in_per_mtok   base input price used, USD per million tokens
price_out_per_mtok  output price used, USD per million tokens
cost_usd            dollars as published (or as computed by the calculator from the published tokens)
api_minutes         API-busy minutes when the source gives them (6m 20s -> 6.33)
approach            which of the three approaches, or the kind of aggregate
note                what the source says, in its words where possible

Five rows, all published. When you run the method yourself, add rows with the same columns from your harness's JSON result, keep the source column pointing at the transcript or result file, and never round the token counts. The calculator's --csv flag prints a row in the right column order from the numbers you pass it.

Limitations

Every dollar figure here is list price; contracted rates, Batch API discounts, and regional multipliers change them. The /usage example is one session on one model that is no longer the newest, and it is included because it is published, not because it is typical. The chars/4 heuristic is wrong for code by a wide margin and says so on every line it prints. And the method costs the run, not the outcome: a cheaper approach that fails and needs a second attempt costs both attempts, which is why time to green records attempts and outcomes alongside dollars.