AI Unit Economics

The per-request cost structure of AI inference and the gap between software-like revenue scaling and infrastructure-like costs — now the binding constraint on AI business models.

Also known as: unit economics (of AI inference), unit economics, token economics, cost per cognitive outcome, cost per inference, seats to tokens, subsidy era, demand crunch, life cycle (of a model), active parameters, single-token FLOPs, usage-based pricing

Context Tax (Retry-Driven Cost Accumulation)

How authors use it

Oldest first (extraction date when no publication date is known).

AuthorTheir termTheir meaning
AI's biggest critic has lost the plot
Kelsey Piper · 2026-04-01
life cycle (of a model)The full economic arc from training cost through revenue generation to retirement — used by Epoch AI to assess profitability
DeepSeek v4, and the end of the OpenAI/Microsoft AGI clause
Simon Willison · 2026-04-30
active parametersThe fraction of an MoE model's weights that are actually used to compute each token — directly governs inference cost. Willison emphasizes the active vs total split as the key economic lever.
DeepSeek v4, and the end of the OpenAI/Microsoft AGI clause
Simon Willison · 2026-04-30
single-token FLOPsDeepSeek's stated efficiency metric: V4-Pro uses 27% of the FLOPs and 10% of the KV cache of V3.2 at 1M context; V4-Flash uses 10% of FLOPs and 7% of KV cache
The Agentic P&L: Beyond the Empire of Headcount
Shreshta Shyamsundar and Anmol Jain · 2026-05
Cost per cognitive outcomeThe new operating-line ratio: total token + infrastructure + latency cost divided by economically valuable outcomes (risk-weighted handshakes); replaces 'cost per FTE' as the unit-economics primitive
The Week AI Grew Up
AI Daily Brief · 2026-05-01
subsidy eraThe period when AI companies offered flat-rate or below-cost pricing to acquire users, absorbing the true compute costs
The Week AI Grew Up
AI Daily Brief · 2026-05-01
demand crunchA situation where demand for AI compute tokens far exceeds supply, driving up prices and forcing rationing
Is AI Doom Going Out of Style?
AI Daily Brief · 2026-05-05
seats to tokensThe business model shift from per-user SaaS subscriptions to usage-based pricing where AI agents consume tokens, removing the ceiling on per-customer revenue
Who Cares About Consumer AI?
AI Daily Brief · 2026-05-06
token economicsThe per-unit cost structure of AI inference where the value extracted per token consumed varies enormously between enterprise and consumer users, making consumer users structurally unprofitable
Guest post: AI Inference Is Breaking Unit Economics
Turing Post · 2026-05-07
unit economics (of AI inference)The per-request cost structure that determines whether an AI product can scale profitably — specifically the gap between revenue per request and cost per inference
GLM-5.2 is the new leading open weights model on the Artificial Analysis Intelligence Index
Artificial Analysis · 2026-06-17
Active parametersThe subset of a mixture-of-experts model's total parameters (40B of 744B) actually used per token/forward pass — used here as the comparability anchor between GLM-5.1 and GLM-5.2 ('same size... but scores 11 points higher').
Travel Through the Lens of AI with Booking.com CEO Glenn Fogel
Glenn Fogel (guest); No Priors / Sarah Guo (host) · 2026-07-11
token economicsThe live cost-management discipline of deciding which model to use, for which purpose, and when, and of tracking how many tokens a task consumes—weighed against an as-yet-unknown ROI and customer lifetime value.

Documents (62)

Propositions touching this concept (11)

By publication month, oldest first (extraction month when no publication date is known).

2025-12

2026-05

2026-06

2026-07

Tensions

Does low-level code quality matter intrinsically, or only instrumentally (via token economics)?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: The disagreement is about the grounds of the fundamentals-revival, not just its truth. If quality matters only via token cost (Verraes, and Fowler's proxy), the case for it is contingent on token economics and evaporates if tokens get cheap; if it is intrinsic (Ördög), it survives cheaper tokens. This makes the popular slogan 'quality still matters' quietly unstable — the same conclusion rests on incompatible foundations.
Is the model a swappable, commoditized component (so selection is a cost decision), or is model choice load-bearing (so selection is a capability decision)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: Both camps are right about different task strata, and the tie is broken by the routing camp's own artifact. Commoditization holds on the bulk/background tier (musistudio and the Pragmatic Engineer are correct that a cheap or open model suffices for a large share of tokens), but model choice is load-bearing exactly on the hard tier — the 'hardest 40%' the routing camp routes AWAY (the Pragmatic Engineer's own gap notes 60%-of-token-spend is not 60%-of-value). nrehiew's 6.5x over-editing spread and stellaraccident's collapse are measured on precisely that hard tier. The clincher the swap camp does not concede: musistudio's OWN per-model transformers (tooluse, enhancetool, reasoning, deepseek, gemini) prove the harness is NOT model-agnostic — every model needs bespoke request/response rewriting just to work behind Claude Code, so the 'any model' artifact self-refutes. Delangue even concedes the frontier gap himself. Verdict: select cheap-and-swappable for bulk, and treat the model as a load-bearing capability decision for the hardest slice — the two positions are not competitors but a partition of the task distribution.
Context size: should you shrink the problem to fit a small usable window (decompose / reset), or grow and trust a large window?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The apparent 'grow / trust the big window' position for CODING largely dissolves once retrieval is separated from coding — which is exactly Pocock's move ('good for retrieval, less good for coding') and musistudio's (longContext is a routed escalation, not the coding default). No text argues you should code inside a full 1M window. The only genuine pressure toward trusting a bigger window is the vendor-forward Fable 5 / Opus 4.6 claim that coherence loss is being engineered away — but that is a moving target (convergence 5), not a stable dial, and even the harness paper only relaxed context resets AFTER measuring that the new model no longer needed them. A secondary, live sub-dispute survives: reset vs compact. Pocock, the harness paper and best-practices favor clearing/resetting to a fresh agent; Hills and Osmani lean on compaction. The reset camp has the better argument on today's models — compaction preserves the same anxious agent — but the disagreement is real and unresolved. Verdict: shrink-and-decompose is the default for coding; grow only as an explicit retrieval escalation; prefer reset over compact unless the model version has demonstrably killed context anxiety.
Who selects the model/effort/context — a human deciding per task, or an automatic router — and who is trusted to hold the dial?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The human-vs-auto axis is less about capability than about (a) whether task difficulty can be detected a priori and (b) who bears the principal-agent risk. No router in the corpus actually measures difficulty — musistudio routes by token-count and static scenario, and the Pragmatic Engineer's routers infer 'good enough' without a demonstrated oracle — so 'auto' today means 'static-heuristic', not 'optimal'. Automation is safe when the user owns the policy (musistudio) and dangerous when the router profits from the choice (Cursor Auto) or when the provider adjusts the dial invisibly (stellaraccident). Verdict: keep the human holding the difficulty judgment and the effort dial until routers can both measure adequacy and prove neutral incentives; automate only the mechanical dispatch, over rules you own and can audit.
Should the harness/platform and its safety be centralized or left distributed across teams?
from: What is the future of software development in the agentic/AI age?
Assessment: A real operating-model split. Edwards-Alexander's distributed stance rests almost entirely on the DevOps-team analogy (his own extraction flags it as asserted-on-intuition, not argued), whereas the platform camp has the stronger concrete case for the citizen-developer safety problem — you cannot distribute production-data guardrails to non-engineers. The tension is partly reconcilable: Ocytko himself concedes a platform tight enough for non-engineers may be too constraining for expert engineers' identity and innovation, which is exactly the freedom Edwards-Alexander is protecting. The unresolved question is whether one platform can be both.
Strategically, is the right move to accelerate adoption to build a permanent lead, or to decelerate and hedge against AI's risks?
from: What is the future of software development in the agentic/AI age?
Assessment: Nearly opposite bets: Herlein optimizes for a world where AI keeps getting cheaper and better and first-movers win permanently; Verraes and Fowler optimize for a world where AI gets costlier, curtailed, or unreliable. Herlein's 'permanent moat' rests on flywheel logic plus a single secondhand anecdote and ignores technology-diffusion catch-up dynamics; Verraes and Fowler's hedge is cheap insurance but under-examines whether reversion is actually achievable once specs, agents, and toolchains are deeply embedded and human familiarity has eroded. The disagreement is ultimately a bet on the trajectory of token economics, which nobody in the corpus can price.

Open gaps (145)