AgentBurn getagentburn.com
Submit Agent
Home/Blog/Seats, credits, tokens
Agent economics

Seats, credits, tokens: comparing AI agent pricing units

Agent pricing arrives in at least four units, and none of them convert to another without an assumption. A normalization checklist, plus the dataset rows that make the trap visible.

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

1. Four units, four different questions

Ask two AI agent vendors for a price and you get two different nouns. A legal agent is quoted per seat. A CRM agent is quoted in Flex Credits per action. A coding agent is quoted per task or per million tokens. A support agent is quoted per resolved conversation. None of the units is wrong — they answer different questions. The one you need, what one completed piece of work costs, is usually not on the price list.

The numbers here come from the AgentBurn dataset (snapshot 2026-10-27): 30 production projects, 22 priced models at list prices. Only three of the 30 publish a token count per task and ten a cost per task, so this is a normalization guide built on a thin, traceable set of rows. The per-field provenance in projects.json says which is which.

2. Why the units do not convert on their own

Each unit meters something real and hides what makes it comparable:

UnitWhat it metersWhat it hidesExample in the dataset
SeatAccess per person per periodConsumption — two seats can differ by orders of magnitudeHarvey: per seat with usage limits, no per-task figure
CreditVendor-defined metered eventsThe credit-to-token rate, and what triggers a chargeAgentforce: 20 credits ≈ $0.10 per action; Copilot Studio: 2/5/10 credits
Task / actionOne completed unit of workWhat “completed” means, and whether retries are inside itClaude Code: 24.1M tokens and $13.30 per task
Token (list price)Model input and outputHow many tokens a finished task needs22 models, $0.10 to $10 per 1M input tokens (models.json)

The gaps are structural. A seat price has no usage term to divide by. A credit has a usage term whose rate is set by the vendor's rate card. A per-task price has a usage term, but the task definition is a contract term. Only the token layer compares across providers, and it is the smallest part of what you buy.

3. Credits, worked: Agentforce and Copilot Studio

Salesforce Agentforce meters a standard action at 20 Flex Credits, which the cost-model source in our dataset puts at roughly $0.10, with a 10,000-token threshold per action before extra credits apply. Two numbers fall out, and both need an assumption.

formula
credit price      = $0.10 / 20 credits        = $0.005 per credit
cost per action   = 20 credits × $0.005       = $0.10
implied $/1M tok  = $0.10 / (10,000 / 1,000,000) = $10.00 per 1M tokens

The $10 per million is the number to argue with: about five times the $2 input list price of Claude Sonnet 5.5 and roughly eighteen times the blended rate implied by the Claude Code row in section 4. That gap is not pure markup — an action includes CRM grounding, orchestration and an audit trail — but “20 credits per action” tells you nothing until you know how many tokens one of your actions consumes, and whether it stays under 10K.

Copilot Studio publishes a ratio rather than a price: 2 Copilot Credits for a generative answer, 5 for an agent action, 10 for tenant-graph grounding. Our dataset records those counts and the Microsoft Learn source; it does not record a dollar rate per credit, because that rate comes from a contract or credit pack, not a public page. The missing multiplier is exactly where the comparison stops.

VendorPublished unitPublished rateImplied $ per 1M tokensAssumptions required
AgentforceFlex Credit per standard action20 credits ≈ $0.10; 10K-token action threshold$10.00Action fills the 10K band; nothing above threshold; credit price holds at volume
Copilot StudioCopilot Credits per answer / action / grounding2 / 5 / 10 creditsNot computable from the datasetContract credit price plus your answer-to-action-to-grounding mix

A credit is not a unit of work. It is a unit of billing shaped by a rate card: two agents that each “do one action” can consume 2 credits or 25.

4. What a per-task figure actually contains

Per-task pricing is the closest unit to the truth, but the task still varies. Three projects publish both a token count and a cost:

ProjectTokens per taskCost per taskImplied blended $ per 1M tokens
Claude Code24,100,000$13.30$0.55
Codex CLI3,900,000$1.50$0.38
n8n AI agents137,000$0.42$3.07

Read the wrong way, that table suggests n8n is the expensive option. It is 32x cheaper per task and 5.6x more expensive per token. The reason is amortization: a 24.1M-token session re-reads the same cached prefix, so its blended rate lands below Claude Sonnet 5.5's $2 input list price — impossible without prompt caching at $0.20 per million. A single 137k-token workflow run has nothing to amortize. Same list prices, different harness, opposite conclusion.

That is why the leaderboards keep cost per task and cost per solved task separate instead of blending them into one score.

5. A checklist before you compare two vendors

Six questions, in the order that eliminates the most uncertainty fastest.

  1. Define one unit of work. A merged PR, a resolved ticket, a delivered report. Write it down before you ask; if the vendor's definition differs, the comparison is undefined.
  2. Ask for tokens per task, split input / output / cached. The only figure that transfers across vendors, and missing for 27 of the 30 projects in our dataset.
  3. Ask for cost per task at list price, including retries. Ten of 30 publish it; check whether it is list price or an effective contract price.
  4. Ask what “solved” means, and for the success rate over a stated sample. Also missing for 27 of 30. Without it you cannot leave the per-attempt world.
  5. Substitute your own run volume. Run volume is a model estimate on all 30 rows — six carry no estimate at all — so every monthly figure multiplies a stated cost by a modelled volume.
  6. Recompute on cost per solved task. One formula, two lines:
formula
cost_per_solved_task = cost_per_task ÷ success_rate
monthly_spend        = runs_per_day × 30 × cost_per_task
monthly_cost_per_solved = runs_per_day × 30 × cost_per_task ÷ (runs_per_day × 30 × success_rate)
                        = cost_per_task ÷ success_rate

Three rows carry both a cost per task and a stated success rate, so they are the only ones where the division uses published figures:

ProjectCost per taskSuccess rateCost per solved task
Aider$0.4867.5%$0.71
Cline$0.4266.8%$0.63
GitHub Copilot coding agent$0.7565.0%$1.15

Cost per solved task is AgentBurn arithmetic on two stated values, not a vendor-published metric. In this small set the ordering survives the division; nothing guarantees it will, and the point of the metric is the case where it does not. The methodology documents the formula and the label each field carries.

The trap in one sentence: a vendor can publish a real cost per task, a real success rate and a real credit rate and still leave you unable to compute cost per solved task — the three numbers rarely share a document, a unit and a date.

6. Outcome pricing is a different category

Sierra charges per resolved conversation and Decagon charges per resolution. These are not a fifth unit to convert into tokens; they are a price for an outcome, with model spend and human escalation folded into the vendor's margin. Neither publishes tokens per task or cost per task in our dataset, which fits: the vendor is not selling tokens.

Outcome pricing is comparable only against your own cost per solved task, and only if “resolved” means the same thing on both sides — a vendor counting a closed ticket and a finance team counting a ticket that stayed closed for 30 days measure different populations. When the definitions line up, the outcome unit is the most honest of the five; when they do not, it is the least auditable. To price a specific workload, the calculator takes a task, a model, a retry rate and a success rate and returns all five units side by side — a list-price scenario, with the same caveat as every figure above.

Sources