TokenOps Metrics: 10 KPIs to Track for AI Coding Spend (2026)

TL;DR

TokenOps metrics are the numbers that turn one AI coding invoice into decisions. Ten worth tracking, in the order you can trust them:

1. Attributed share of spend — % of spend traced to a developer, repo, and workflow.
2. API-equivalent spend per engineer — tokens priced at API rates, per engineer-week.
3. Cost per merged PR — spend divided by pull requests merged.
4. Context-carry share — % of spend paying to re-send context rather than generate output.
5. Re-read rate — % of file reads that re-read unchanged content still in context.
6. Model mix — share of spend on frontier models, by task type.
7. Redundant-run rate — % of agent runs that repeat a run that already succeeded.
8. Recoverable waste share — % of spend in the four named waste shapes.
9. Spend by lane — interactive vs. background agent vs. CI and automation.
10. Week-over-week spend trend — and the spikes it flags.

Each maps to one stage of the TokenOps loop — attribute → surface waste → optimize → operate. New to the term? Start with What is TokenOps?.

Why TokenOps needs its own metrics

A provider billing dashboard reports one total, broken down by model and API key. That answers "what do we owe?" It does not answer "who spent it, on what, and how much was waste?" — the questions a team actually acts on.

FinOps already solved the parallel problem for cloud. The FinOps Foundation's Unit Economics capability is about developing metrics that show "how an organization's technology use and technology management practices impact the value of the organization's products, services, or activities." TokenOps metrics are the same idea one layer up: token spend tied to developers, workflows, and shipped work. The billing standard is catching up too — FOCUS 1.4 added token-economics columns (our breakdown) — but those columns still describe the invoice, not the session.

Stage 1 — Attribute

1. Attributed share of spend

• Definition: the percentage of AI coding spend you can trace to a specific developer, repo, and workflow.
• Formula: attributed API-equivalent spend ÷ all captured usage priced at the same API rates
• Why it matters: every metric below is computed over the attributed slice. If only 40% of captured usage is attributed, your "cost per PR" describes 40% of it. Keep both sides in API-equivalent dollars: dividing token value by a seat invoice mixes two units and can exceed 100%. Track capture coverage (which tools and logins you read at all) as a separate number.
• Trap: reading per-API-key spend as per-developer spend. A key is a credential, not a person — a shared key or gateway collapses a whole team into one row. See AI spend attribution.

2. API-equivalent spend per engineer

• Definition: each engineer's token usage priced at published API rates, per week.
• Formula: Σ(tokens × API rate per token type) ÷ engineer-weeks
• Why it matters: it puts Claude Code, Codex, and Cursor usage on one scale, whichever plan or provider paid for it.
• Trap: treating a flat-rate plan as "free past the seat price." The plan price is what you paid; API-equivalent spend is how much work the tokens were. Report both, and never let the plan price hide the trend.

3. Cost per merged PR

• Definition: AI coding spend per pull request merged — the unit-economics number.
• Formula: attributed spend ÷ merged PRs (per team or repo, per period)
• Why it matters: it is the closest thing to "cost per unit of shipped work" a team can compute today, and the number finance asks for.
• Trap: using it to rank individuals. PR size varies, and research or abandoned branches spend without merging. Read it as a team or repo trend.

Stage 2 — Surface waste

4. Context-carry share

• Definition: the share of spend that pays to re-send the conversation and files already in the context window, rather than to generate new output.
• Formula: cost of input + cache tokens re-sent each turn ÷ total cost
• Why it matters: an agent pays for every token in its window on every turn. The carried portion grows with every turn of a long agentic session, and it is the most compressible part of the bill. See context efficiency.
• Trap: counting cached and fresh input tokens as the same. On Anthropic models, cache reads cost 0.1× the base input price (less on some newer models), while 5-minute cache writes cost 1.25×. Token counts and dollar shares diverge sharply; compute the share in dollars.

5. Re-read rate

• Definition: the share of file reads that re-read a file whose unchanged content is still in the agent's context.
• Formula: repeat reads of the same path ÷ total file reads
• Why it matters: re-read loops are the most common shape of recoverable token waste — paying again to re-learn what the agent already knew.
• Trap: flagging every repeat. A re-read after the file changed is correct behavior, and so is a re-read after context compaction dropped the file. Count only reads of unchanged content the agent still had in context.

6. Model mix

• Definition: spend split by model tier, ideally by task type.
• Formula: frontier-model spend ÷ total spend, segmented by task (rename, test fix, refactor, design)
• Why it matters: frontier models on commodity tasks are the "oversized model" waste shape.
• Trap: pushing frontier share down for its own sake. A frontier model on a hard refactor is leverage. The signal is the frontier share on trivial tasks, not overall.

7. Redundant-run rate

• Definition: the share of agent or workflow runs that repeat a run that already succeeded.
• Formula: duplicate successful runs ÷ total runs
• Why it matters: pure repeat spend with no new result — common in scheduled agents and in CI loops that re-trigger on every push.
• Trap: counting retries after real failures. A rerun after a red build is work, and so is a run on new code. Only a repeat with the same inputs that already passed is waste.

Stage 3 — Optimize

8. Recoverable waste share

• Definition: the share of spend that falls into the four named waste shapes — re-read loops, bloated context, redundant runs, oversized models.
• Formula: spend classified as recoverable waste ÷ attributed spend
• Why it matters: this is the headline optimization number: what you can cut without cutting what ships. It is also how you prove an intervention worked — the share should fall on the next comparable work.
• Trap: false precision. Classifying waste means reading the workflow, and some of it is judgment. Report the shapes and their dollar ranges; don't publish a two-decimal "efficiency score" the telemetry can't support.

9. Spend by lane

• Definition: spend split between interactive sessions, background agents a developer launched, and fully automated work (scheduled agents, CI review bots).
• Formula: lane spend ÷ total spend, per lane
• Why it matters: each lane has a different owner and a different fix. Interactive waste is coached; automated waste is fixed in config, once.
• Trap: booking agents launched from an interactive session as human work. An agent-heavy team can look like a small interactive bill with a large invisible one behind it.

Stage 4 — Operate

10. Week-over-week spend trend

• Definition: the change in attributed spend per team and repo, week over week, with spikes flagged.
• Formula: (this week − last week) ÷ last week, alerting past a threshold the team sets
• Why it matters: a 20x spike from a looping agent should be visible the day it starts, not at month-end close.
• Trap: comparing a partial week to a full one, or reading a new tool rollout as a spike. Annotate known changes — a new model, a new agent, a new hire — on the trend line so the next spike is legible.

Summary table

Where to start

You don't need all ten on day one. Get attributed share above 90% first — nothing else is trustworthy until it is. Then add cost per merged PR for finance and context-carry share plus re-read rate for engineering, since those two usually point at the biggest recoverable line. Add the trend and alerts once you've proven one optimization moved the number.

None of these come from the invoice alone. Attribution, re-reads, model-by-task, and redundant runs only exist in the session — which is why a billing tool can flag a spike but not its cause. For how session-level tools differ from billing and gateway tools, see 6 AI spend management tools and TokenOps vs FinOps.

Promptster Teams tracks these from the session

Promptster Teams reads Claude Code, Codex, and Cursor sessions across the repos you choose, attributes spend by repo and workflow (each engineer sees their own figures; managers see team and squad totals), and reports context carry, re-reads, model mix, lanes, and cost per PR — from prompts plus workflow, with code and diffs redacted locally before upload, and never developer monitoring.

See how Promptster Teams runs TokenOps →

Related: What is TokenOps? · TokenOps — definition · Recoverable token waste · AI spend attribution · TokenOps vs FinOps · How much does Claude Code cost a team? · Attributing AI coding spend per developer