Agent economics

How to estimate a monthly AI agent bill (with the formula)

A monthly agent bill has five inputs. Four are measurable; one is a guess. Here is the formula, an example for three agent shapes, and the sensitivity that decides whether you are off by 30% or 10x.

Published · 10 min read · by AgentBurn Editorial · dataset snapshot 2026-10-27

1. Five inputs, one bill

Every monthly agent bill can be written with five numbers. The vendor packaging — seats, credits, minimum commitments — sits on top of these, not instead of them:

  • Runs per day (R) — completed tasks per day.
  • Tokens per task (T) — the average for one completed task, including whatever the harness re-sends.
  • Blended price (P) — dollars per million tokens for your input, output and cache mix.
  • Retry overhead (ρ) — extra attempts as a share of the first attempt.
  • Success rate (s) — the share of attempts that end in a completed task.

The snapshot can supply T for three of its 30 projects: Claude Code at 24.1M tokens per task, Codex CLI at 3.9M and n8n at 137,000. It supplies P for 22 models from official list prices. It supplies R for none: every runs-per-day value in the dataset carries the basis "model", and the methodology says plainly that no public source exists for daily run volume. R, ρ and s are yours to measure.

2. The formula

The methodology page defines the derivation and the calculator implements it. The short version:

formula
blended $/1M = (input_share * input_price)
             + (output_share * output_price)
             - (cache_hit_share * input_share * (input_price - cached_price))

attempt cost   = (tokens_per_task / 1e6) * blended $/1M
monthly bill   = runs_per_day * 30 * attempt cost * (1 + retry_overhead) / success_rate
monthly tokens = runs_per_day * 30 * tokens_per_task * (1 + retry_overhead)

Run it once on a coding agent at the calculator's defaults: 75% input share, 25% output, no cache, and Sonnet 5.5 at $2 input and $10 output per million. The blend is $4.00 per million tokens, so a 3.9M-token task costs $15.60 per attempt. With 10% retry overhead and an 85% success rate, the cost per completed task is $20.19.

Compare that with the published Codex CLI row: $1.50 per task. Same product, same task set, 13x apart — and the whole difference is the cache assumption. The published row is only reproducible if most of the 3.9M tokens are served from the prompt cache, where GPT-6.1 Sol bills $0.10 per million rather than the $2 list input rate. A from-scratch estimate that ignores caching is not conservative; it is wrong by an order of magnitude.

One consistency check before using the last term. A published per-task cost is normally a cost per completed task, which means its own retries and failures are already inside it. The (1 + retry_overhead) / success_rate term is for estimates built from raw attempts — the token route. Apply it once, to one basis, never on top of a figure that already contains it.

3. Three profiles, three bill shapes

Here are three agent shapes priced from the snapshot's units. Each column is the published unit cost multiplied by volume — no retry or success term added, because the published costs are per completed task.

Agent shapeUnitPublished unit costTokens per task200/day2,000/day
Ops workflow (n8n)task$0.42137,000$2,520$25,200
Coding agent (Codex CLI)task$1.503,900,000$9,000$90,000
Coding agent (Claude Code)task$13.3024,100,000$79,800$798,000
Support agent (Agentforce)action$0.1010,000 threshold$600$6,000

At 200 tasks a day — the calculator's default volume — the shapes already differ by two orders of magnitude, and the 2,000/day column is ten times each of those figures. The support row is priced per credit, not per token: Agentforce charges 20 Flex Credits, about $0.10, for a standard action, with a 10,000-token threshold before extra credits apply. An action is not a resolution; a three-action resolution is about $0.30, so multiply the row before comparing it with the task rows. The n8n row is a single community-reported run — roughly 137k input tokens and $0.42 for a five-word question — so treat it as an anecdote with a date, not a fleet average.

The token column explains the shape. A 24.1M-token coding task is 176x the n8n run in token volume and 32x in dollars; the difference is the harness's context policy, not the model's price list. If your work looks like the coding row, the bill is decided by tokens per task. If it looks like the support row, it is decided by actions and volume.

4. Where retry and success enter

When you build cost from tokens, retry and success enter as one multiplier, (1 + ρ) / s. Applied to the token-built attempt from section 2, $15.60:

Retry overheadSuccess rateMultiplierCost per completed task
0%100%1.00$15.60
10%85%1.29$20.19
25%75%1.67$26.00
40%60%2.33$36.40

Even the worst case is a 2.3x swing — smaller than the 13x gap between the token-built cost and the published Codex row, which is the cache assumption. Put directly on the price side, the published coding rows imply $0.38 to $0.55 per million tokens, against $4.00 for a 75/25 list-price blend: a 7x to 10x range. But a cache hit rate is measurable from your provider's usage dashboard, so it is a calibration task rather than a guess.

Volume has no such ceiling. A 10x error in runs per day is a 10x error in the bill, which is why the next section treats that input on its own.

5. Runs per day is the guess

Our dataset labels every runs-per-day value with the basis "model". The methodology is direct about it: no public source exists for daily run volume, the figure is a model estimate from pricing tiers and community reports, and window totals are an order-of-magnitude index of relative activity rather than a market size. The largest modelled values in the snapshot — Sierra at 180,000, n8n at 150,000, Copilot Studio at 120,000 — describe fleets, not your deployment.

The volume term is linear: 24h tokens = runs per day × tokens per task. For the Claude Code unit, 200 tasks a day is 4.8 billion tokens a day and 144.6 billion a month; 2,000 tasks a day is 1.45 trillion tokens a month. Nothing else in the formula can move the number by that much, and nothing else is as easy to get wrong.

If you cannot measure volume, write the range down instead of a point. "Fifty to five hundred tasks a day" produces a 10x budget band, which is more useful than a single invented number and honest about which input is doing the damage.

6. Replace the guesses

Three of the five inputs come from your own logs: tokens per task, retry overhead and success rate. The telemetry SDK posts input, output and cached tokens, tool calls, retries, duration and a success flag per task; the aggregate yields T, ρ and s directly, and the cached-token column yields the cache hit rate that turns a list-price blend into P. Point the calculator at your own numbers and the forecast stops being a reconstruction of someone else's harness.

Two caveats survive measurement. Prices are list prices, with no negotiated discount and no batch rate. And if the agent routes across several models, blend by traffic and token share, not by model count. Both rules are documented on the methodology page.

Order of work: measure volume and tokens per task first — each carries a 10x. Then cache. Retry and success are the last 2x. A model built on a guessed volume with a measured cache rate is still a guess about the biggest input.

Sources

  • AgentBurn dataset snapshot 2026-10-27 — projects.json (Claude Code, Codex CLI, n8n and Agentforce cards), models.json (22 list prices), benchmarks.json (per-task token and cost rows).
  • AgentBurn methodology — the pricing formula, list-price caveats, and the note that runs per day is a model estimate.
  • n8n issue #38130 — community report of about 137k input tokens and $0.42 for one five-word question, github.com/n8n-io/n8n.
  • Agentforce Flex Credits cost model 2026 — 20 credits ≈ $0.10 per standard action, 10K-token action threshold, community write-up.
  • AgentBurn cost and ROI calculator — defaults used here: 200 tasks/day, 75% input share, 0% cache, 10% retry, 85% success.
  • Model list prices captured 2026-10-27 from the providers' official pricing pages.