What a coding agent really burns: 1.6B tokens of receipts
A dated receipt for one real coding-agent workload: 1.6B prompt tokens all-time, a 224M-token peak day, 93% of prompt volume served from cache — and the arithmetic that turns that into dollars per task, per day and per month.
tl;dr
TL;DR — This is the receipt the other posts cite: 1.6B prompt tokens all-time, a 224M-token peak day, 93% of prompt volume served from cache, measured on our own gateway and published at llms.txt.
The shape matters more than the total. At 93% cache reads, that peak day is 208.32M cached and 15.68M fresh prompt tokens, plus 8M output on the model below — and the cached share, not the headline input price, is what decides the bill.
What it costs. Priced at our own catalog rates on 2026-10-24, that day is $13.31 on our cheapest lane, $27.40 on the mid lane and $111.32 on the flagship lane. Thirty such days is $399 / $822 / $3,339.
What is not in this receipt. The per-day series, the per-model split and per-customer usage are not published, and no throughput or latency claim is made here. The data file lists exactly what is and is not in it.
Token-Max coding plans
A billion tokens a day for your coding agents
Flat monthly plans sized for real agent burn — glm-5.3 + qwen3.8 lanes on GPU cells we own and tune. Daily reset, live token meter, OpenAI-compatible. Capacity is limited: apply and see your queue position.
Table of contents
- What was measured, and what was not
- The shape of an agent day
- The peak day, priced
- Why the cached column decides everything
- What 1.6B all-time actually says
- What this means if you are buying
- Where runaii.cloud loses
- FAQ · Glossary · Sources and freshness · Changelog
What was measured, and what was not
Disclosure. I'm the founder of runaii.cloud, and this is our own workload. The three headline figures are aggregates from our gateway: 1.6B prompt tokens all-time, a 224M-token peak day, and 93% of prompt volume served from cache. The same three numbers are published in llms.txt, and they are the receipt the coding-plans comparison and the coding-agent API comparison both model.
What that is: a token count from our own billing path, aggregated, and a cache-read share computed as cached prompt tokens ÷ total prompt tokens over the same window.
What that is not: a benchmark, a latency measurement, a throughput claim, or a per-customer report. We do not publish the daily series, the per-model split, per-key usage, or the distribution behind the 93% — a share is not a median, and a peak day is not a typical day. The data file states the same limits in machine-readable form, so nobody has to infer them from prose.
The reason to publish the shape at all is that almost every "cost of an AI coding agent" number circulating in 2026 is either a vendor list price with no workload attached, or a screenshot of somebody's personal usage with no method attached. A shape with a stated method is more useful than either, and it is re-priceable: substitute your own logs and the arithmetic below still works.
The shape of an agent day
An agent is not a chat window. Every turn re-sends the system prompt, the tool definitions, the file tree and the open files; only the newest tool result and the newest instruction are actually new. That is why an agent's prompt volume is dominated by prefix re-reads, and why a cache-read price is the only number that decides the bill.
At our published 93% cache share, a 224M-token prompt day splits into:
cached prompt 224M x 0.93 = 208.32M tokens
fresh prompt 224M x 0.07 = 15.68M tokens
output 8M (modelling assumption, see below)
total 232M tokens in the day
The 8M output figure is the one number here that is not measured: it is the output assumption carried over from the coding-agent cost comparison, kept identical so the two posts can be read against each other. If your agents write more output than that, substitute it — the output rate is the most expensive rate on every card below, so it is the assumption most worth replacing with your own logs.
One more useful conversion: the modelled task shape is 50,000 fresh input tokens, 200,000 cached prompt tokens and 8,000 output tokens — 258,000 tokens. At that shape, the 224M-token peak day is roughly 868 tasks (224M ÷ 258K). That is the bridge between a day and a task, and it is arithmetic on two stated assumptions, not a measurement of either.
The peak day, priced
At our catalog rates on 2026-10-24, per 1M tokens:
| Lane (catalog rates) | Cached 208.32M | Fresh 15.68M | Output 8M | Peak day | 30 such days |
|---|---|---|---|---|---|
| deepseek-v4-flash ($0.22 / $0.022 / $0.66) | $4.58 | $3.45 | $5.28 | $13.31 | $399 |
| qwen3.8-flash ($0.40 / $0.04 / $1.60) | $8.33 | $6.27 | $12.80 | $27.40 | $822 |
| glm-5.3 ($1.40 / $0.26 / $4.40) | $54.16 | $21.95 | $35.20 | $111.32 | $3,339 |
Each row is cached tokens × cached rate + fresh tokens × fresh rate + output tokens × output rate. Component cells are rounded to the cent; the totals are computed from the unrounded products, which is why a column can add to a cent more or less than the total. The spread between the cheapest and most expensive lane on an identical workload is 8.4x — driven by the cached rate and the output rate, not by the headline input price.
Our catalog's GLM-5.3-Flash row ($0.15 / $0.03 / $0.50) is deliberately absent: the same catalog file flags that id as retired from serving, so it is not a lane we will sell you. Check the live catalog rather than any table, including this one.
Why the cached column decides everything
Run the sensitivity, because it is the one thing a reader can check without trusting us. Hold the day fixed at 224M prompt tokens and 8M output, and move only the cache share:
| Cache share | Cached tokens | Fresh tokens | Peak day on deepseek-v4-flash |
|---|---|---|---|
| 0% (no cache) | 0M | 224M | $54.56 |
| 50% | 112M | 112M | $32.38 |
| 80% | 179.2M | 44.8M | $19.08 |
| 93% (our published share) | 208.32M | 15.68M | $13.31 |
| 98% | 219.52M | 4.48M | $11.10 |
The arithmetic for the 0% row is 224M × $0.22 + 8M × $0.66 = $49.28 + $5.28 = $54.56; for 50% it is 112M × $0.022 + 112M × $0.22 + 8M × $0.66 = $2.46 + $24.64 + $5.28 = $32.38; for 80% it is $3.94 + $9.86 + $5.28 = $19.08; for 98% it is $4.83 + $0.99 + $5.28 = $11.10. The point is a shape, not a promise to the cent: the same workload costs 4.1x more at 0% cache than at 93%, and no provider's headline input price tells you which row you are on. Our own row at 93% is the reason the published share is part of the receipt rather than an afterthought.
What 1.6B all-time actually says
1.6B all-time against a 224M peak day is 7.1 peak days (1.6B ÷ 224M). That is the most useful honest statement in the receipt: the peak day is not a typical day, it is a burst. A workload whose all-time total is about a week of its own peak day is a workload with a long tail and a few very heavy days, and any pricing decision made from the peak day alone will over-provision for the rest of the month.
We publish the total and the peak, not the curve, because the curve is the part that would identify a customer's work pattern. That is a real limit of this receipt, not a rounding choice.
What this means if you are buying
Three decisions, in order of how much they move the bill:
- Get your cache share first. If your harness re-sends a stable prefix and your provider bills cached reads at a fraction of input, you are on the 93% row. If your provider does not expose a cached-read price at all, you are on the 0% row whether or not caching happens underneath — you cannot see it, so you cannot be billed for it correctly.
- Price a task, not a token. 258K tokens per task at our modelled shape is $0.0207 on our cheapest lane. Tasks per day is the unit your own logs can produce, and it is the only unit comparable across a metered API and a flat plan.
- Then decide metered or flat. At our published peak-day shape, Token-Max Team's $199 breaks even at 15.0 heavy days a month against our cheapest metered lane, 7.3 against the mid lane and 1.8 against the flagship lane. Below those counts the meter is cheaper; above them the plan is. The full break-even table is in the coding-plans comparison, and the plans themselves are on Token-Max.
Where runaii.cloud loses
- The receipt is ours, so it describes our workload. It is a real workload shape on a young platform, not a survey of the industry, and a different workload (longer contexts, more output, heavier tool use) prices differently.
- We withhold the series. Anyone who wants the daily curve, the per-model split or per-customer numbers will not get them from this page, and that limits how far the receipt can be audited.
- Our cheapest lane is a small model. The $13.31 day is a Flash lane; the flagship lane is 8.4x more, so "an agent day costs $13" is true only for that lane.
- Token-Max is application-gated. The flat lane's capacity is physical, so the plan is not self-serve checkout.
Sources and freshness
- Published workload receipt: runaii.cloud/llms.txt — 1.6B prompt tokens all-time, 224M peak day, 93% of prompt volume served from cache (read 2026-10-24).
- Machine-readable form of this receipt: /blog/what-a-coding-agent-really-burns/data.json — the same figures plus the derived arithmetic and the list of what is not published.
- runaii.cloud rates: runaii.cloud/pricing — deepseek-v4-flash $0.22/$0.022/$0.66, qwen3.8-flash $0.40/$0.04/$1.60, glm-5.3 $1.40/$0.26/$4.40 per 1M tokens (read 2026-10-24 from
src/lib/catalog.ts). - Token-Max plan card: runaii.cloud/token-max — Solo $49 / 100M tokens a day, Team $199 / 300M, Max $499 / 1B, application-gated (read 2026-10-24).
- Output-token assumption (8M per peak day): carried over from the coding-agent API comparison, where the same day shape is modelled.
Prices move monthly in this market. The changelog records edits; the data file is the receipt.
Related
- AI coding plans compared (2026) — the same heavy day priced against eight flat plans.
- Best LLM API for coding agents (2026) — the cached-read column across providers.
- Claude Code alternatives, priced — the harness and billing lanes this workload shape decides.
- Cache economics, measured — the method behind the cache figures.
Changelog
- 2026-10-24: initial publication. Workload figures are the aggregates published at llms.txt on the same date; rates are from
src/lib/catalog.tsand the Token-Max card is fromsrc/app/token-max/page.tsxon the same date. Output tokens per peak day (8M) is labelled as a modelling assumption, not a measurement. Next scheduled re-verification: 2026-11-24.
FAQ
▸How many tokens does a coding agent use per day?
There is no single number, and any post that gives one without a workload shape is guessing. Our own published peak day is 224M prompt tokens with 93% of prompt volume served from cache; our modelled task is 258K tokens, which puts that peak day at roughly 868 tasks. A typical day is lower than the peak — we do not publish the curve, so treat 224M as a ceiling, not an average.
▸What does a heavy coding-agent day cost?
At our catalog rates on 2026-10-24, 224M prompt tokens at a 93% cache share plus 8M output costs $13.31 on deepseek-v4-flash, $27.40 on qwen3.8-flash and $111.32 on glm-5.3. Thirty such days costs $399, $822 and $3,339 respectively. Those are arithmetic on published rates, not invoices.
▸Why is the cache-read share the most important number?
Because most of an agent's prompt tokens are re-reads. At our published 93% share, 208.32M of the 224M-token day is billed at the cached rate. Move the share to 0% and the same day costs 4.1x more on the same lane. A provider that hides the cached price can look cheap per token and cost multiples more per task.
▸Is 1.6B tokens a lot?
For a single platform's all-time prompt volume on a young service, it is small — about 7.1 of its own peak days. That is the honest reading: a burst-shaped workload with a long tail, which is why a peak-day receipt should never be multiplied by 30 without saying so.
▸Can I reproduce this with my own logs?
Yes, and you should. Take cached tokens ÷ total prompt tokens over your window for the cache share, price 50K fresh / 200K cached / 8K output at your provider's card for a task, then scale by your own task count. Every formula used here is printed above; nothing depends on our data except the three headline figures, which are labelled as ours.
Glossary
- Prompt tokens
- the input an agent sends: system prompt, tool definitions, repository context and the newest instruction. The dominant part of an agent's bill.
- Cached read
- a prompt token whose prefix the provider has already processed and stored; billed at a fraction of fresh input by providers that expose it, and reported per response in `usage.prompt_tokens_details.cached_tokens`.
- Cache-hit share
- cached prompt tokens ÷ total prompt tokens over a window. Our published workload reads 93%; the share moves the bill more than the headline price does.
- Heavy day
- in this post, a 224M-token prompt day with 8M output tokens, modelled on our published peak-day measurement.
- Task
- in this post, one agent session at 50K fresh input, 200K cached prompt and 8K output tokens — 258K tokens.
- Peak day
- the highest single day in the measured window. A ceiling, not an average, and never a monthly multiplier.
Token-Max coding plans
A billion tokens a day for your coding agents
Flat monthly plans sized for real agent burn — glm-5.3 + qwen3.8 lanes on GPU cells we own and tune. Daily reset, live token meter, OpenAI-compatible. Capacity is limited: apply and see your queue position.