the only metric that matters in tokenomics: research report

01 · abstract and method

This study set out to test whether inference capacity, not human attention, is the constraint an agent-native company hits next. It ends somewhere more useful: the constraint question only matters because almost nobody reports the number that would tell you whether hitting it is good news or bad. That number is value created per dollar of inference. The inference bottleneck is the field observation that led here, not the finding itself. A company that routes its humans' attention well enough stops being limited by attention; ours then hit a hard capacity ceiling, on the machine running its agent fleet, 24 to 29 times over 60 days depending on how the count is collapsed, twice during a week nobody was at a keyboard. That observation only says something if you can also say what the capacity bought. This report builds that second number from the same telemetry, states its assumptions in the open, and reads it against what the public record shows enterprises spending and getting back.

observer bias, stated plainly

The authors operate the company measured in §06 and hold the hypothesis under test. The control is artifacts over impressions: every internal figure is produced by a script reading a system of record over a stated window with a stated denominator, re-runnable by anyone with the same logs, and unflattering readings (the retention gap in m1 and m6, the honest non-finding in m3) publish beside the flattering ones. Anything not tied to an artifact is labeled estimate or opinion in the sentence that states it.

observation boundary

The self-test in §06 covers one company, approximately one operator, across two machines, one that directs work and one that runs the agent fleet, both re-indexed and read fresh at write time. No third machine exists in this company's roster. Every window is stated beside the number it produces, because a figure without its denominator is not a measurement, it is an assertion.

02 · definitions

An ai-native company puts ai inside work its people already own: employees hold each task, a model accelerates them, and inference is a productivity input bought per seat. An agent-native company organizes the work around agents doing it: humans direct, review and hold judgment, and agents research, build, test, ship and coordinate other agents, which turns inference from an input into the labor line itself.

Neither term was coined by this series; the closest institutional prior uses are Gartner's "agent-native I&O" framing (February 2025) and a16z's "agent-native architecture" writing (March 2025), both aimed at infrastructure design, not workforce substitution. No. 003 set out the four-rung ladder from legacy to agent-native organizations; no. 004 built the agent-native benchmark this company is scored against; no. 005 established the 47.6:1 attention multiplier this report re-measures below. All three are referenced, not re-argued.

03 · the metric: value created per dollar of inference

Everyone measuring tokenomics measures an input: price per token, tokens per seat, dollars per employee, capacity per data center. The question that decides whether any of that spend is good business is what the tokens produced, divided by what they cost. This section defines that ratio and states, as a floor, what it reads today.

the numerator, three ways

the denominator

Every token consumed, at list rate, on every machine in the company's roster, including subagent and sidechain calls, retries, and runs that failed and were thrown away. The subscription discount the company actually pays is real and is not used here; list rate is the cost of the labor if it had been bought unrationed, the honest comparator for a replacement-cost numerator.

today's reading, highly assumptive

Across the company's two shipped products, list-rate compute totals approximately $165,000 over 142 and 38 days respectively. At the floor replacement-cost basis, $120,000 per product, that is roughly $1.50 of replacement value per dollar of inference spent building both. This reading is highly assumptive: it prices software that has no revenue yet against a published agency-rate range, not against a market that has valued it. At the midpoint of the published agency range instead of the floor, the same arithmetic reads several dollars of value per dollar of inference. This report publishes the floor, because a floor is defensible and a midpoint is a choice. The floor says nothing about whether either product has market value at all, a different and larger question this study makes no claim about.

the slope, not just the level

Every input to this ratio is moving one direction for this company: the agent-actions-per-human-message multiplier rose from 44 to 63 over the trailing month and reaches roughly 200 to 1 inside one fully autonomous build program (§06, m1); the list price of a fixed capability is falling roughly tenfold a year across the market (§05); and cost per merged change held flat while daily output quadrupled between the two products (§06, m3), meaning the operating system is keeping more of each run's output rather than spending more to get the same amount. For a company whose downstream step is still a person, none of those three levers move the same way, which is the argument this report makes for why the metric is worth building an operating model around rather than reporting once.

04 · why nobody else reports it

Three public sources describe "enterprise ai spend" and none share a denominator.

None of these is "enterprise ai spend" as one clean number: Menlo's figure excludes hyperscaler infrastructure billed separately, Gartner's is worldwide and broader, Ramp's is per employee and the only one built from real payments rather than survey or analyst modeling.

the governance wave

Uber capped ai coding-tool spend at $1,500 per engineer per month after its 2026 ai budget was consumed in four months [v]. Coinbase's ceo states the company holds ai cost roughly flat despite exponential usage growth by routing prompts to cheaper models [l]. The NBER working paper "Writing Code vs. Shipping Code" (Demirer, Musolff, Yang, May 2026, matched telemetry across a large sample of GitHub developers, 2022–2026) [v] found autonomous coding agents raised commits 240%, projects 80%, and shipped releases only 30%; the attenuation from 240% to 30% is the mechanism, most of the extra output an agent produces stalls before it reaches production, and inference spent on work that stalls is inference spent on a numerator of zero. An enterprise measuring a poor return per token is behaving rationally when it caps.

what the labs are capping, in real time

On September 10, 2026, Thibault Sottiaux, who leads Codex and ChatGPT at OpenAI, paused new $200/month Pro-plan subscriptions to the company's newest model because demand was "putting the most strain on our systems" [v, TechCrunch]. The reply thread underneath is the whole debate in six posts: the era of subsidized tokens is ending, prepare accordingly; no, tokens are getting cheaper and compute is scaling; you're missing the nuance; the price has kept going up for two years; and one reply that changed the subject: "the quality of what you can produce per $ is up by like a factor of 1000 though" [l, one recorded exchange between named individuals on X, not a survey of the industry's view]. Every voice in it, including the one that changed the subject, is measuring an input. None names what a dollar of it produced.

the market has started pricing the metric before anyone has published it

TechCrunch reported on September 8, 2026 that Cognition raised $2 billion at a $48 billion valuation, four months after a prior round at $26 billion, with its own reported annualized run-rate revenue rising from $492 million to $900 million over that stretch [v]. Two weeks earlier TechCrunch reported that Instinct, a personal-agent startup roughly a year old, raised $250 million of a $350 million round at a $2.5 billion valuation, on adoption rather than disclosed revenue, explicitly described as a personal-assistant product, not an ai coding company [v]. Neither round discloses a value-per-dollar-of-inference figure; what each prices is confidence that shipping speed per dollar of tokens will keep compounding. Nobody has put a number on that confidence. This report's claim is that the number exists and is measurable the same way any productivity ratio is: numerator over denominator, both stated.

05 · consumption: where one operator sits

No vendor publishes a percentile ladder for individual inference consumption. Published: enterprise developers average $150 to $250 of list-rate inference per month, 90th percentile below $30 a day; heavy individual power users run $500 to $2,000 a month; Ramp's top 1% of firms spend $7,400 per employee per month, a firm-level not individual figure [v/l per §04]. Above the power-user band the public record stops; the closest adjacent dataset, OpenRouter's app rankings, measures traffic through apps, not people, and cannot be converted to a per-operator comparison.

One operator in this company, measured over the trailing 30 days across both machines, consumed approximately $130,000 of list-rate-equivalent inference (§06, m4), several orders of magnitude above the highest publicly reported individual power-user figure, because no percentile table exists to place it more precisely. Against Ramp's top-1%-of-firms figure it is on the order of 17 times that; against a $150 to $250 typical developer month, several hundred times. Both are this report's own arithmetic, labeled as such, not a published ratio. The company buys this inference as several subscriptions with weekly ceilings, a rationed way to consume compute against unrationed api pricing, returned to in §08.

06 · self-test: method and results

Subject: the company measured throughout this report, both machines in its roster, session transcripts re-indexed at write time. Every figure below is self-administered; the method and script are named with each measure so any is re-runnable against the same logs.

m1, the touch ratio

The definition matches no. 005 exactly: a human message is a typed record with a human origin, excluding tool-result feedback and automated hook injections, confirmed by direct scan; agent actions are main-chain tool calls, with sidechain and subagent calls given separately as an upper bound. Re-run over the trailing 30 days, company-wide: 180,170 main-chain tool calls against 3,903 human messages, 46.2:1 (62.8:1 including sidechain calls), against no. 005's published 47.6:1 a month earlier. Re-running the same method over no. 005's original window on today's disk returns 35.1:1, not 47.6:1, because local retention has rotated some of that period's transcripts out since publication; 46.2:1 is a fresh, directly measured number, read as consistent with 47.6:1 in direction and magnitude, not a reproduction of it. A separate figure inside one fully autonomous build program, 3,191 agent actions against 16 human touches, roughly 199:1, illustrates a ceiling routing can reach under favorable conditions and is not averaged into the 46.2:1 figure.

m2, capacity stops

Detection method: a direct grep for the literal stop message the coding-agent client emits on hitting a usage limit, found before any regex was written against it. The raw match count over 60 days was 904 lines, inflated because every parallel agent running when a limit hits narrates the same wall-clock reset independently. Collapsing by machine and reset-clause gives 24 distinct stop events, all on the machine running the agent fleet, none on the machine that directs work; a stricter collapse keyed to (machine, clause, calendar day) instead of (machine, clause) gives 29 events, because a non-weekly reset clause repeats across different days with no date attached, while the weekly-ceiling resets do carry a date and collapse cleanly either way. That 24-to-29 figure is a floor by construction: an operator who is fully blocked opens no session and narrates nothing.

m3, per-product compute

The honest finding is not the one this study's plan assumed going in. Per merged change, cost was flat across the company's two shipped products: about $52 on the first (142 days, ~$76,000 list-rate compute, 1,458 merged changes) and about $51 on the second (38 days, ~$89,000, 1,722 merged changes), a 1.01x ratio; per commit, the second product cost more, not less. What changed is daily throughput: the second product ran roughly $2,333 of list-rate compute per calendar day against roughly $535 a day on the first, a 4.4x difference, while the operator's own message volume held constant across both windows. This is evidence for a company running hotter against its inference ceiling over time, not evidence the second product was cheaper per unit of output, and it is stated that way rather than as the efficiency-gain framing this study's plan originally expected.

m4, monthly consumption

Company-wide over the trailing 30 days, across both machines: 340,871 assistant turns, 2,133 sessions (425 on the machine that directs work, 1,708 on the machine that runs the agent fleet), an average of 476,081 tokens of context per turn, 98.75% of that context past the base context floor, for a list-price-equivalent total of $127,698. A narrower cross-check scoped to six working repositories over the same window gives $133,513, split roughly 76.5% top-tier model, 20.2% a mid-tier reasoning model, 3.1% a cheap tier, and a small remainder; the 4.5% gap between the two totals is scope and window definition, not disagreement.

replacement-cost estimate. Building two products at the low end of the published $120,000–$500,000 agency range implies roughly $240,000 of replacement value against roughly $165,000 of list-rate compute across both (the sum of the two m3 totals), the $1.50-per-dollar floor stated in §03. What this floor cannot tell you: whether either product has any market value at all.

m5, the throttle estimate

Over 2026-07-12 to 2026-09-10, excluding the vacation week 2026-08-30 to 2026-09-05 entirely (reported separately, not folded in): a floor of 34.3 hours lost (4.48% of ex-vacation tool calls, 6.0% of ex-vacation business hours) from 26 narrated stops outside the vacation week; a middle of 25.7 hours (3.36%, 4.5%) from gaps tied to a stop's own reset window; a ceiling of 335.6 hours (43.87%, 58.9%) from every company-wide gap over two hours during weekday business hours, narrated or not, which deliberately includes meetings, meals and sleep and is not a claim that 44 to 59 percent of throughput is inference-capped. The middle estimate, converted, is roughly 8,233 additional tool calls at the window's own $0.737-per-call list rate, about $6,070 of list-equivalent inference, or roughly 117 additional merged-change-equivalents against m3's $52.07-per-merged-change figure, an upper-middle estimate, not a claim those changes exist. The blind spot: a fully blocked operator opens no session and narrates nothing, so the floor and middle are floors by construction; the vacation week's 3 stop events (11.6 hours idle, autonomous programs running unattended, not counted as lost time since nobody was directing work to lose) show the wall binding with zero human in the building.

m6, the monthly series

Calendar months March through September 2026 (September partial, through the 10th), across the company's four active repositories and both machines: merged changes per day rose from roughly 8 in March to 10 in April, 13 in May, 16 in June, then to a 57-per-day rate in August, cost per merged change holding near $50 across the measured months. The retention caveat matters more than the trend line: March, April and May have zero surviving session transcripts on either machine, so dollar figures, tool-call counts and human-message counts for those months are unmeasurable, not zero, while merged-change and commit counts persist in git and GitHub regardless. June is the worst case: a persisted data file built 2026-09-07 shows $30,747 for June against $2,861 from a fresh rebuild three days later, meaning most of June's transcripts rotated out of retention inside that three-day gap alone. July and August match their persisted-file totals closely and are the most trustworthy rows. September is partial by construction (10 of 30 days at write time) and its per-day figures run high because the vacation week's autonomous-program activity landed inside a shortened month; it is reported as a partial month, not annualized. The monthly merged-changes counts above are not comparable product to product: merge practice (squash frequency, PR granularity) differed between the two repositories over this period, so a month-over-month rise in the series is a directional read of activity, not a like-for-like unit comparison. That is why the post itself does not publish this series and instead uses only the per-product-window figures in m3, roughly 4x daily compute and about $52 per merged change, which hold the unit fixed within each product's own window.

07 · the metric, modeled

Everyone's inference spend is public in outline; almost nobody's return is. This section carries the napkin behind §03's and §06's reading in full, alongside three other rows built from the same public figures used in §04 and §05, so every number here can be checked against the arithmetic that produced it, not taken on the strength of the claim.

the caveat every row but one needs. Only the third row is measured against this company's own records; every other row is [estimate], built from a public per-employee or per-developer spend figure and a published productivity range, not from a company's own reported numerator and denominator together. The frontier-lab and Cognition rows are stronger and weaker at once: stronger because they are the two entities plausibly closest to this company's own ratio, weaker because neither publishes an inference-spend figure at all, so both are labeled unpublished rather than assigned a number this report cannot support.

our numerator, three ways, highly assumptive throughout

Two shipped products, about $165,000 of list-rate inference across 142 and 38 days, every token on every machine including subagents, retries and failed runs (§03, §06 m3/m4). Replacement cost at the bottom of published agency ranges for a consumer app with a backend and ai features, $120,000 each, gives $1.50 per dollar, the floor this report uses everywhere else. At the midpoint of that range, $310,000 each, the same arithmetic gives $3.80 per dollar. A third basis, labor equivalence: 1,722 merged changes in 38 days is, at a working developer's two to three changes a day, roughly 15 to 20 developers, about $250,000 a month loaded, which gives $2.80 per dollar. None of the three prices market value, which the products do not yet have; revenue replaces this numerator the month it exists.

the enterprise napkin

Ramp's top-1% spend, $7,400 per employee per month, is about $89,000 a year. Value: a 20 to 30 percent productivity gain on a $150,000 loaded employee is $30,000 to $45,000, and the NBER conversion of activity into shipped releases, 30 of 240 (§04), cuts what actually ships to a fraction of that gain. Ratio: $0.05 to $0.50 per dollar of inference, the capped row in the table above.

the ai-native tech-company row

The same $30,000 to $45,000 productivity-gain estimate, against a lighter spend: $250 per developer per month, a vendor-published enterprise average (§05), about $3,000 a year, and a more generous 30 to 100 percent conversion, since a tech company's own releases ship at a higher rate than the NBER's cross-industry sample. That gives $4 to $13 per dollar, higher than the enterprise row because the spend is lighter, and it is the row this report expects to fall as spend rises: the return is capped by a person downstream who does not get faster as the company spends more on them, the same mechanism behind Uber's own spend cap (§04).

2029, three scenarios

Two levers move this company's ratio and nothing else does: the list price of a fixed capability, and how many agent actions run per human touch. Price: a16z measured roughly 10x a year at fixed quality; frontier-tier prices fall slower, so this report takes 3x a year as the conservative floor. Autonomy: this company's own multiplier rose from 44 to 63 over the trailing month and reaches roughly 200 inside one autonomous build program (§06, m1); 3x by 2029 is the assumption used here, not the ceiling the data already shows. Output retained per run is held flat, no assumed improvement there at all.

The ai-native line does not move in any scenario, because the person downstream of it does not get faster; it stays within the $0.05-to-$13 band measured today, likely nearer its own floor as spend rises. That asymmetry is the argument the rest of the report makes in prose: an agent-native company's ratio compounds because both of its levers move; an ai-native company's ratio is capped by one lever that never does.

08 · counter-evidence, each tested

(a) waste, not scarcity

The same 60-day window in which stops occurred also followed a period in which cost per unit of shipped work fell, by the company's own prior measurement. If the wall were a symptom of waste, falling unit cost should have relieved it; it did not, stop frequency held even as unit cost fell, the pattern a genuine capacity constraint would produce, though this study has only one company's data to test it against.

(b) rationing, not physics

A subscription is a fixed-price ration on a metered good; the same good is sold unrationed, at list price, through an api. One documented case makes the gap concrete: a developer measured 440 sessions and 18,000 turns in a month against a $200 subscription, calculating the same usage would have cost approximately $1,588 at published api rates, roughly 8x the subscription price that month [v]. A broader claim that subscriptions run 15 to 30x cheaper than metered pricing generally is the same source's own aggregate estimate, not independently re-derived. What the concrete case supports: the wall a subscriber feels is a price ceiling the vendor set below its own list rate, not evidence inference is physically scarce at that scale. Cash is denominated in tokens; enough of it removes the wall a subscription creates, though not necessarily the one capacity creates further up the supply chain, which is also why Cognition and Instinct's rounds in §04 read as bets against a wall that money can move.

(c) an attention wall in disguise

The flat touch ratio (46.2:1 against 47.6:1) is offered in §06 as evidence attention routing held steady while inference ran out; it cuts both ways, since a flat ratio is also consistent with attention itself being the limiting factor throughout, inference simply tracking whatever fixed attention could direct. The strongest evidence against that reading is m3: daily compute rose 4.4x on the second product while message volume held constant, more consistent with inference finding headroom under an unchanged attention budget than with attention expanding.

09 · confounds

This comparison cannot tell you several things it might look like it tells you. It is one company, self-administered, with instruments its own operators built to test a hypothesis they hold; the observer-bias control in §01 reduces the risk a number is computed wrong and does nothing about the risk the wrong numbers were chosen to compute. There is no control company, a conventional or ai-native twin measured over the same window, which is the experiment this study needs and does not have. The company has no revenue, so every replacement-cost figure in §03 and §06 describes cost, never validated market value, the specific gap the metric's second and third numerators are meant to close and have not yet. The machine-labor evidence in §04 describes populations of hundreds of thousands of developers or one large lab's own staff; nothing here establishes that one operator's numbers generalize to those populations, or the reverse. The stop-frequency measurement in m2 and m5 is a floor by construction: a company hitting a harder wall would produce fewer narrated stops, not more, since a fully blocked operator opens no session at all. And the Cognition and Instinct figures in §04 are two data points about investor confidence in shipping speed, not a measurement of either company's own value-per-dollar-of-inference; this report does not claim to know either company's numerator or denominator, only that the rounds price something adjacent to it.

10 · verdict, amendment, falsification, review date

the risk, not the pitch

This report is not a case for which companies are worth backing; the table in §07 is a warning as much as an opportunity. An enterprise that adopts ai as a productivity input inside software its people still operate locks in a ratio capped by that person, the same shape Uber's own spend cap made visible (§04), and token efficiency does not remove that cap. Token efficiency matters and comes first; value per dollar of inference is the number that drives profit and revenue once it does.

the amendment

The plan assumed routing improvements between the first and second product would show up as a cheaper unit cost, and that a cheaper second product would itself be evidence for the inference-bottleneck thesis. Neither held: unit cost was flat, not falling. The actual divergence, a 4.4x rise in daily compute at the same per-unit price, is a different finding, though it still supports the broader claim, since it shows a company running more inference per calendar day without running more per shipped unit or more messages per operator, which is what capacity expansion under a fixed attention budget should look like. What held instead of the hypothesized efficiency gain was throughput: the same operating system, run harder, at the same cost per unit.

falsification tests

A re-measurement of the touch ratio over the next 30 days showing a sustained rise, not flat, would weaken the claim that attention routing has plateaued. A materially lower stop frequency (m2/m5) coinciding with unchanged or rising per-product cost would suggest the wall was closer to rationing than to genuine scarcity. A third product built at a meaningfully lower cost per merged change than the first two would revive the efficiency-gain story the plan expected and did not find. A value-per-dollar-of-inference reading that falls as usage or revenue numerators become available, rather than rises, would weaken §03's central claim. Each requires a further 30 to 60 day observation window on the same company, using the same scripts, before being treated as a finding rather than noise.

Review date: 2026-12-10, or sooner if a stop-frequency reading materially diverges from the 24-to-29-events-per-60-days baseline, or if either numerator beyond replacement cost becomes reportable.

11 · sources

tier 1 — fetched and verified this study [v]

tier 2 — corroborated via secondary sources [l]