It makes less on tokens every year, on purpose.
In most usage-metered software, gross margin is roughly flat because cost of revenue scales with usage. In Quinn it climbs, because a rising share of served work is a cache hit and a cache hit costs a fraction of a fresh recompute. The model is built to turn the deflation of compute into the engine, not the threat.
One layer deflates on purpose. The other grows with the network.
The layer that deflates, on purpose
Metered compute margin and the per-run spread. A reused result is priced as a fixed fraction of what a fresh recompute would cost, so per-run price falls as compute cheapens and as the cache warms. The model makes less on tokens every year, deliberately.
The layer that grows with the network
Subscriptions, certainty (proven-correct, gate-verified results), the registry take-rate on the marketplace, and enterprise licensing. None of it deflates with the token; it grows with the network. This is where the durable revenue lives.
Metered compute margin
Deflates on purposeThe spread on fresh runs, which shrinks as compute cheapens. Led away from over time.
Subscriptions
Flat fee, deflation-neutralUsage bundles a payer buys and draws down for whoever they cover.
Marketplace take
Scales with the networkThe registry cut on published actions. Grows with the builder economy.
Enterprise licensing
Grows with adoptionThe standard and its runtime, licensed where an enterprise runs it internally.
Bottoms-up from paying accounts and usage, not top-down from market share.
The mix shifts from access and compute spread toward certainty and registry take-rate as the network matures. That shift is the shift from application revenue to standard-layer revenue. Source: live model, tab 5. Refresh-required.
The parties who create value share in it, funded from margin.
The model is built so that adding earners never reduces what an existing earner receives. New earners are funded from the company's own margin. Two mechanisms are live; one is on the roadmap.
Builder royalty
Live at launchA builder authors an action and earns roughly 20% of the outcome price on every run of it. Pass-through, scales with built-action volume.
Referral payout
Live at launchA referrer earns a declining share of a referred user's payments, single-level, funded from company margin. Self-liquidating CAC, paid only on realized revenue.
Seeder dividend
On the roadmapA first-computer earns as others inherit a verified result. Turns on with reuse density, funded from margin. No line until live.
Acquisition is self-liquidating, paid only on realized revenue, so payback shortens and LTV to CAC widens as the cache warms. Flip the scenario and watch it move.
Metered per person, always. Payment decoupled from metering.
An operator or team admin can absorb the meter for many people, which removes the every-person-needs-a-card friction. The more an operator absorbs, the more the shared cache saves across their people, so the operator motion and the cache flywheel are the same motion.
Community
Cache-primed entry: cheap models, free shared-cache hits, use-but-not-build
Pro
Base usage allotment
Team
5x the Pro pool
Scale
20x the Pro pool
Source: Economic Policy v1.1, §2. Community carries no revenue by design; it is the cache-priming flywheel.
The compute line falls from 40% of revenue to 4%. That fall is the whole margin story.
As the cross-tenant cache-hit rate rises, blended cost of revenue falls, and gross margin climbs from 45% to 86% without a price change. The builder royalty holds at roughly six points because it is priced on value, a fraction of recompute, not on tokens, which is what lets the royalty survive as compute trends toward free.
| Driver, base case | Y1 | Y2 | Y3 | Y4 | Y5 |
|---|---|---|---|---|---|
| Cross-tenant cache-hit rate | 4% | 12% | 22% | 32% | 40% |
| Blended cost of revenue (% of rev) | 55% | 42% | 30% | 20% | 14% |
| of which compute (after cache) | 40% | 27% | 16% | 8% | 4% |
| of which builder royalty | 5% | 6% | 6% | 6% | 6% |
| of which payment and infra | 10% | 9% | 8% | 6% | 4% |
| Gross margin | 45% | 58% | 70% | 80% | 86% |
Source: live model, tabs 6 and 7, base scenario. In the conservative case the hit rate stalls at 24% and gross margin tops out at 76%, still a strong software margin. Refresh-required.
EBITDA-positive in Year 4, on modest cumulative early losses.
The base case turns EBITDA-positive in Year 4 on cumulative early losses of roughly $5.0M through Year 3. The company is not asking to be funded through a long march to profitability; it is asking to be funded to prove a measurable network effect.
| Line | Y1 | Y2 | Y3 | Y4 | Y5 |
|---|---|---|---|---|---|
| Revenue | $280K | $1.9M | $7.9M | $24.5M | $59.4M |
| Gross profit | $126K | $1.1M | $5.5M | $19.6M | $51.1M |
| Gross margin | 45% | 58.0% | 70% | 80% | 86% |
| EBITDA | ($1.2M) | ($1.7M) | ($600K) | $6.9M | $27.9M |
| EBITDA margin | -428.6% | -89.5% | -7.6% | 28% | 47% |
| Net income | ($1.5M) | ($2.2M) | ($1.3M) | $5.0M | $21.1M |
Every derived line recomputes off the stored primitives, so the three scenarios can never drift out of reconciliation. Source: live 12-tab model. Indicative and refresh-required.
Per-run price falls as compute cheapens, but total revenue rises, because the durable layer (certainty, the standard, registry take-rate, access) grows with the network rather than with the token price.