George Seabridge · about · cv · writing

Should I worry about my AI sub being heavily subsidised?

2026-07-20

“Enjoy the cheap tokens while you still can!”

A lot of people seem to be expecting a rug-pull moment where prices get aggressively hiked by the frontier labs after years of exuberant VC-fuelled subsidy. It’s common to hear statements like “your $200/month Claude subscription actually costs $5,000 in API usage”. On the face of it, this sounds ludicrously unsustainable. Anyone would be mad to allow their business to get hooked on this drug when the music so clearly has to stop playing one day soon, right?

The numbers certainly seem to stack up: SemiAnalysis tried to figure out the max possible API-equivalent spend on the various subscription plans available from OpenAI and Anthropic, and found that you can indeed consume as much as $14,000 on a $200/month plan.

SemiAnalysis estimate of maximum possible API-equivalent usage on subscription plans

The fear of a coming correction is exacerbated by a clear direction of travel in pricing models. Anthropic’s current Enterprise contracts use usage-based billing, with a per-seat platform fee that doesn’t cover any actual token burn - all tokens are charged at API prices. GitHub Copilot did the same in June 2026, explicitly citing how agentic usage made their previous buffet model unsustainable. And OpenAI has linked Codex credits directly to token consumption across personal and enterprise plans, although it continues to include some usage with subscriptions.

So should we - the token-hungry power users caning our Max 5x or 20x subscriptions for everything they’re worth - be worried? Surely OpenAI, Anthropic and their backers are going to tire of setting thousands (tens of thousands?) on fire every month per power user paying just $200. Are we going to wake up one morning and find the rug pulled out from underneath our autonomous swarm of coding agents, with the only option to shift to the API and 40x our spend?

I think these fears are somewhat off the mark. (Don’t pull the plug on that 24/7 coding setup just yet.) While you should expect to eventually pay more than $200/month for round-the-clock coding agents, it’s unlikely to be anywhere near API list prices. Although Anthropic might sell you the same tokens for $5,000 at API usage billing, this is clearly not the same as what it actually costs Anthropic to serve those tokens.11. It’s astonishing how many commentators make statements like “it costs Anthropic $5,000 to deliver your $200/month sub!” No, it does not. In fact, there are plenty of reasons to believe that direct inference is now a very high contribution-margin business (albeit not taking account of model training, research, product development and the rest of the cost base).

A compelling data point comes from DeepSeek, who published a day of production traffic and calculated a theoretical direct inference margin22. The calculation assumes every token was billed at R1 prices and compares that revenue with GPU leasing costs. Actual revenue was substantially lower because web and app access was free, V3 was cheaper and DeepSeek offered off-peak discounts. of

theoretical hardware margin=187,072562,027=84.5%.\text{theoretical hardware margin} = 1 - \frac{87,072}{562,027} = 84.5 \%.

And this is at DeepSeek’s low token prices.

I asked GPT-5.6 Sol to perform a detailed bottom-up analysis of token serving against API cost specifically for a long-horizon coding agent workload, then checked the arithmetic and load-bearing assumptions by hand. The detailed analysis is included in the appendix, but the bottom line is that a model with DeepSeek-like serving characteristics, sold at Sonnet 5 API prices, produces a direct inference margin of around 70-75%, with 60-80% as the defensible range - and a parametric extension to flagship Opus-class models suggests their margins are fatter still.

This fits with the chart below, derived from the same SemiAnalysis estimates, which assumes a 75% gross margin on API list prices and shows the implied subscription contribution margin from a user on each plan type, sensitised by what proportion of the theoretically available usage they actually consume. In other words, since SemiAnalysis derived that Claude Max 20x theoretically maxes out at $8,000/month of API-equivalent spend, the cost to serve is c. 25% of $8,000 = $2,000. If a user hits 10% of the maximum possible allowance, then Anthropic will break even on that user’s $200 sub.

SemiAnalysis derived subscription margin by utilization, assuming 75% API gross margin

The amount of red on that chart is what is worrying. The key point is that this business model works today because of gym economics33. The idea that subscription users pay a flat fee and some users consume dramatically more than they pay for, incurring a negative contribution margin, effectively being cross-subsidised by a much larger cohort of users with dramatically lower intensity usage. . Only a small portion of the user base is “tokenmaxxing” - trying to consume the absolute maximum amount of usage possible within the limits of their subscription. The user base breaks down into these broad categories:

I don’t know what the mix is between these use cases today, but I suspect it is highly skewed as we ascend the tokenmaxxing scale. There are a handful of early adopters with early-stage startups or personal projects who are willing to throw agents at building software around the clock with minimal oversight, driving their agents deep into red territory on that chart. Most engineering teams have not got there yet and sit in the middle bucket - much lower per-sub utilisation, comfortably in the green regions of the chart. For now, there are enough of them to keep the buffet open.

The question becomes: what happens if this autonomous coding thing actually catches on and works? Gym economics aren’t going to keep working if the mix starts shifting heavily towards that style of usage. In the limit, we need to consider the economics if autonomous fleets of coding agents become the predominant mode of running software projects.

The future economics of autonomous software development

Let’s assume that engineering converges on a style of development that involves humans planning and guiding, while ensuring they bottleneck the coding agents as little as possible. Picture a kanban board where AI automatically picks up tickets that are ready to go, then review agents automatically review the output and drive to completion via an automated merge queue with automated deployment. Humans exist to research and understand what users want, guide the direction of the project, create and manage tickets, oversee major architectural decisions and unblock critical decision points. Everything else is done autonomously.44. I don’t know if this is really going to happen but it seems at least fairly plausible looking forward from July 2026.

The important quantity to know is the per-agent monthly inference cost of running around the clock. Per the appendix analysis, each step costs roughly 1.3-2.3¢ to serve a DeepSeek-like model with Sonnet 5 strength, and a serial agent operating at full duty cycle can get through about 90k steps per month. That implies a direct inference cost of roughly $1,200-2,100 per month. That figure is for a Sonnet-class model; the appendix’s flagship sensitivity suggests an Opus-class agent runs at a low single-digit multiple of it - still far below API list prices. Next, try to guess what margin the providers will manage to squeeze out of you, and finally you can predict your future cost for access to this round-the-clock intelligence.

In any case, it’s going to be a lot next to a $200 subscription, but much less remarkable next to the fully-loaded cost of an engineer. The demand-side question is whether the agent produces more valuable work than it costs. If it does, a four-figure monthly bill can be perfectly sustainable even after the buffet closes. But beware: if you’re currently tokenmaxxing on a $200 sub, expect the screws to tighten over the next few years as everyone else works out how to run their agents round the clock too. The more normal your usage becomes, the less able the labs will be to cross-subsidise you against lower-utilisation subs.

Margin pressure

Everything so far has assumed that providers keep charging something like today’s API list prices, pocketing a c. 75% margin on direct serving cost. Can they actually do this?

Last week, Moonshot announced Kimi K3, a 2.8T-parameter model whose full weights are promised for 27 July. It came within weeks of the frontier lab launches of Claude Fable 5 and GPT-5.6. Moonshot says K3 demonstrates frontier-level performance across its evaluation suite, while acknowledging that it still trails the strongest proprietary models overall.

It’s hard not to conclude that margins are going to come under considerable pressure in the face of this level of competition. Even a couple of months ago, the typical refrain was that open models were 6-12 months (at least) behind the frontier. K3 is another indication that the gap is compressing dramatically. And although it remains to be seen how sustainable a practice it is for Chinese and other open-weight labs to keep doing huge training runs, employing armies of top-tier ML talent and then giving away their primary output artifact for free, releasing the weights weakens the link between what it cost to train a model and what inference providers can charge to serve it. Any number of them can compete to deliver the resulting intelligence as if it’s a utility like electricity or gas.

This is also the answer to the most natural objection to everything above: “fine, direct serving margins are fat, but the labs still have to recoup their gargantuan training runs and research payrolls somehow, so prices must stay far above serving cost”. They do have to recoup them - but that’s their problem, not a floor under your price. The floor under your price is set by competition, and an inference provider serving an open-weight model never has to fund a training run at all.

This also addresses one very common objection. Sure, direct serving margins are fat, but don’t the labs still have to recoup the absolutely behemoth investments they’ve made in data centres, training runs, ML research payrolls, and so on? Well, yes, they do, but that’s their problem. Those costs are well and truly sunk, and if competition forces them to serve below the price they’d prefer, they’ll have to do it to stay alive.

It’s likely that frontier labs will stay at the frontier, and probably compound a variety of advantages like data curation, highly-specialised RL pipelines and know-how for long-horizon tasks, and pure customer inertia and lock-in. But as those capabilities diffuse into open models, it seems inevitable that 75% direct inference margins on API list prices will get squeezed by inference providers selling increasingly interchangeable intelligence. (And yes, that means the enormous capex at your favourite soon-to-be-public frontier AI lab may never pay off, and their share prices could tank55. Not financial advice, I have no idea what’s going to happen; probably they take over the world and hit market cap $400tn. even though they did indeed change the world and usher in an industrial-revolution-scale economic event.)

Conclusion

So should you worry? Well, yes, a bit. A $200 all-you-can-eat subscription is unlikely to remain a durable way of supplying a truly round-the-clock frontier coding agent. Expect more credits, metering, model routing and usage limits as autonomous workloads become more typical.

The good news is that the $5,000-6,000 API price tag people talk about is not the hidden cost waiting to spring out of the box. Under the assumptions in this post - chiefly, that frontier models can be served with something like the efficiency of the best open-weight proxies - the direct cost of serving that workload today is more like $1,200-2,100 for a Sonnet-class model (and a low multiple of that for a flagship), and both improving inference efficiency and open-model competition should keep pushing down the price of any given level of intelligence.

You’re likely to be able to do things in the future like deploy frontier-level intelligence against core planning and architecture work, while setting off much cheaper, less capable open models to implement tightly scoped tickets. There will be many tricks to keep costs under control, and probably many unicorn-scale ecosystem businesses devoted to helping you orchestrate the raw “utility-like” intelligence to get your domain tasks done at the lowest possible cost.

So, if you’re early on the journey of building a software business on top of these models, don’t treat a Max subscription as your steady-state COGS. Test whether the unit economics work at a metered cost per useful completed task. You’ll need to make a judgement call about where lab contribution margins eventually settle.

And enjoy your cheap tokens while you can!


Appendix: Inference economics

We analyse66. Underlying research performed by GPT-5.6 Sol. a steady-state, long-context autonomous coding workload. The best public workload data is TraceLab’s analysis of 140,338 Claude Code inference steps. Across the observed Claude steps:

API price of a coding agent

Until 31 August 2026, Claude Sonnet 5 API pricing is:

For a cache-hot long-context step, we assume 194,000 cached-prefix tokens, 1,700 appended tokens and 690 output tokens. The 1,700-token append approximates roughly 1,000 genuinely new tokens plus the previous output reintroduced into the next prefill.

194,000×$0.20/M=3.88¢194{,}000 \times \$0.20/\text{M} = 3.88\text{¢} 1,700×$2.50/M=0.43¢1{,}700 \times \$2.50/\text{M} = 0.43\text{¢} 690×$10/M=0.69¢690 \times \$10/\text{M} = 0.69\text{¢}

This gives:

5.0¢ per ideal cache-hot step\boxed{5.0\text{¢ per ideal cache-hot step}}

This is a lower bound. TraceLab estimates that retaining caches across human pauses would reduce mean Claude append volume from 8,479 to 3,862 tokens per step. That produces:

3.89¢+0.97¢+0.69¢=5.54¢ per step.3.89\text{¢} + 0.97\text{¢} + 0.69\text{¢} = \boxed{5.54\text{¢ per step}}.

Using the complete observed append distribution instead gives:

3.89¢+2.12¢+0.69¢=6.70¢ per step.3.89\text{¢} + 2.12\text{¢} + 0.69\text{¢} = \boxed{6.70\text{¢ per step}}.

A reasonable range for a long-running autonomous Sonnet loop is therefore 5.5–6.7¢ per step, with 5.0¢ representing a nearly ideal cache-hot floor.

As an independent cross-check, TraceLab estimates $22,654 of API-priced usage across 140,338 Claude steps:

$22,654/140,338=16.1¢ per step.\$22{,}654/140{,}338 = 16.1\text{¢ per step}.

The sample was 82.8% Opus, 7.9% Haiku, 7.8% Sonnet 4.6 and 1.5% other models. Applying current Sonnet 5 prices to the observed token volumes gives approximately 6.7¢ per step, close to the bottom-up estimate.

TraceLab also observes average per-step times of:

A continuously operating serial agent therefore completes approximately:

3,60011.5+16.8127 steps/hour.\frac{3{,}600}{11.5+16.8} \approx127 \text{ steps/hour}.

Over a 30-day month:

127×24×3091,600 steps/month.127 \times 24 \times 30 \approx91{,}600 \text{ steps/month}.

Holding this cadence fixed, monthly API spend is approximately:

Step priceMonthly spend
5.00¢$4,575
5.54¢$5,076
6.70¢$6,134

Thus a single Sonnet agent operating at a true 100% duty cycle consumes roughly $5,000–$6,000 per month at current API prices. Real deployments will be lower to the extent that they wait for CI, external systems, approvals or an empty ticket queue.

Cost to serve

Anthropic does not disclose Sonnet’s architecture, so the physical serving calculation necessarily uses a proxy. A credible transparent proxy is DeepSeek-V3/R1:

For hardware, assume an eight-GPU NVIDIA B200 node. NVIDIA specifies:

CoreWeave currently lists eight-GPU B200 nodes at roughly $34–35/hour spot and $68.80/hour on demand. We use $45 per node-hour as an illustrative saturated-fleet economic cost. Anthropic may obtain better economics through long-term commitments, custom silicon or strategic cloud agreements.

Incremental prefill and cache writes

For one agent step, define:

A cache hit avoids recomputing the existing prefix, but each appended token must still attend over that prefix. Approximate attention work is therefore:

PA+A22.PA+\frac{A^2}{2}.

Using P=194,361P = 194,361 and A=1,700A = 1,700:

PA+A220.332 billion attention token-pairs.PA+\frac{A^2}{2} \approx0.332 \text{ billion attention token-pairs}.

For calibration, an optimised DeepSeek-R1 deployment achieved an 8.6-second time-to-first-token for a full 128k-token prefill on GB300; the comparable GB200 results were approximately 1.07–1.23 times slower.

A full causal 128k prefill contains:

128,00022=8.19 billion attention token-pairs.\frac{128{,}000^2}{2} = 8.19 \text{ billion attention token-pairs}.

The incremental step therefore contains approximately:

0.3328.19=4.05%\frac{0.332}{8.19} = 4.05\%

of the benchmark’s attention work. Its token-local model-body work is approximately:

1,700128,000=1.33%.\frac{1{,}700}{128{,}000} = 1.33\%.

Interpolating between these two limits gives roughly 0.11–0.43 node-seconds per incremental prefill. At $45 per node-hour:

$45×0.110.433,600=$0.0014$0.0054.\$45 \times \frac{0.11\text{–}0.43}{3{,}600} = \$0.0014\text{–}\$0.0054.

We therefore estimate:

Incremental prefill cost0.150.55¢ per step.\boxed{\text{Incremental prefill cost}\approx0.15\text{–}0.55\text{¢ per step}.}

This is deliberately approximate: short-query kernel efficiency need not scale linearly from a full 128k prefill, and the benchmark uses a different but closely related Blackwell configuration.

Decode cost

The active context during generation is approximately:

194,361+1,700+6902196,000 tokens.194{,}361+1{,}700+\frac{690}{2} \approx196{,}000 \text{ tokens}.

The long-context SGLang benchmark uses an FP8 KV cache of 35,136 bytes per token. A 196k-token sequence therefore carries approximately:

196,000×35,1366.9 GB196{,}000 \times 35{,}136 \approx6.9\text{ GB}

of KV state.

On GB200, the benchmark achieves:

for a 128k-input, 8k-output workload, whose average decode context is approximately 132k tokens.

First-order inverse-context scaling to 196k gives:

147.9169.1×132196100114 tokens/s/GPU.147.9\text{–}169.1 \times\frac{132}{196} \approx100\text{–}114 \text{ tokens/s/GPU}.

Across eight GPU-equivalents, this is approximately 795–910 tokens/s. Because the published benchmark uses rack-scale expert parallelism that an isolated eight-GPU node may not fully reproduce, we use a prudent range of:

600900 output tokens/s per eight-GPU equivalent.600\text{–}900 \text{ output tokens/s per eight-GPU equivalent}.

At $45 per node-hour:

decode cost/M output tokens=$45T×3,600/106=$13.89$20.83.\text{decode cost/M output tokens} = \frac{\$45} {T\times3{,}600/10^6} = \$13.89\text{–}\$20.83.

For a 690-token output:

Decode cost0.961.44¢ per step.\boxed{\text{Decode cost}\approx0.96\text{–}1.44\text{¢ per step}.}

KV transfer and storage

HBM residency during decode is already reflected in the measured long-context decode throughput and should not be charged twice. The additional cost is retaining and moving the roughly 6.9GB cache between steps and, in a disaggregated system, between prefill and decode workers.

A full 6.9GB movement at an assumed effective transfer rate of 100–300GB/s takes:

6.9 GB100300 GB/s=2369 ms.\frac{6.9\text{ GB}}{100\text{–}300\text{ GB/s}} = 23\text{–}69\text{ ms}.

As a deliberately conservative upper bound, charging the full economic cost of both endpoint nodes during the transfer gives:

2×$45×0.0230.0693,600=$0.00058$0.00173,2\times \$45 \times\frac{0.023\text{–}0.069}{3{,}600} = \$0.00058\text{–}\$0.00173,

or 0.06–0.17¢ per complete cache movement.

The true incremental cost should be lower. NVIDIA Dynamo transfers KV state directly between GPU memories using non-blocking RDMA, allowing the GPUs to continue servicing other requests during the transfer. KV-aware routing can also send a continuation to a worker already holding the relevant prefix. During longer tool waits, caches can be offloaded to CPU RAM or disk; the direct storage-media cost of retaining 6.9GB for seconds or minutes is negligible relative to GPU cost.

The material economic costs are therefore transfer contention, imperfect overlap and lost cache locality—not the storage bytes themselves. We use:

KV transfer and storage0.050.10¢ per step\boxed{\text{KV transfer and storage}\approx0.05\text{–}0.10\text{¢ per step}}

as a central allowance, with 0–0.2¢ as a wider sensitivity range.

Complete step economics

For a saturated autonomous coding workload:

ComponentDirect cost per step
Long-context decode0.96–1.44¢
Incremental prefill/cache writes0.15–0.55¢
KV transfer and storage0.05–0.10¢
Scheduling, failures and infrastructure overhead0.10–0.20¢
Total1.3–2.3¢

Against API revenue of:

the implied direct serving contribution margins are:

RevenueCOGSDirect serving margin
5.54¢1.3¢77%
5.54¢2.3¢58%
6.70¢1.3¢81%
6.70¢2.3¢66%

A reasonable central estimate is therefore:

70%75% saturated direct serving contribution margin\boxed{70\%\text{–}75\%\text{ saturated direct serving contribution margin}}

with approximately 60–80% as the defensible range. This is a direct inference contribution margin before model training, research, product development, sales and central overhead.

What about Opus-class models?

The analysis above prices a Sonnet-class workload against a DeepSeek-class serving proxy. But the anecdotes powering the rug-pull fear are mostly about flagship usage - 82.8% of the TraceLab sample was Opus. No flagship model has a disclosed architecture or independent third-party serving benchmarks (Kimi K3 is too new, but watch this space), so rebuilding the bottom-up calculation for a flagship model isn’t really viable. Instead, we treat the flagship case parametrically for rough numbers.

The revenue side needs no model at all: TraceLab’s $22,654 across 140,338 steps is an observed 16.1¢ per step at the sample’s Opus-heavy model mix.

On the cost side, long-context serving cost is, to first order, proportional to the bytes moved per token - active parameters plus KV cache. Let kk be the ratio of a flagship model’s per-token serving footprint to the DeepSeek-class proxy, so that:

flagship cost per stepk×(1.32.3¢).\text{flagship cost per step} \approx k\times(1.3\text{–}2.3\text{¢}).

Against the observed 16.1¢ of revenue per step:

kk (relative serving footprint)Cost per stepDirect serving margin
11.3–2.3¢86–92%
22.6–4.6¢71–84%
33.9–6.9¢57–76%
56.5–11.5¢29–60%

Break-even requires k712k\approx7\text{–}12: a flagship would need to move seven to twelve times more bytes per token than the DeepSeek-class proxy, at observed prices, before the direct serving margin hit zero.

That seems unlikely. Flagship-tier list prices have historically run at roughly 5x the mid-tier, while MoE active-parameter counts do not scale with headline capability anything like as fast as prices do. If the cost ratio sits below the price ratio - which is how a lab would rationally price its tiers - then flagship models carry fatter direct serving margins than the mid-tier, not thinner.

At the cadence derived above (~91,600 steps/month), a saturated flagship agent bills roughly $14,700/month at API list prices - consistent with the top end of the SemiAnalysis estimates - while costing perhaps $3,600–6,300/month to serve even at k=3k=3.

Footnotes

  1. It’s astonishing how many commentators make statements like “it costs Anthropic $5,000 to deliver your $200/month sub!” No, it does not.

  2. The calculation assumes every token was billed at R1 prices and compares that revenue with GPU leasing costs. Actual revenue was substantially lower because web and app access was free, V3 was cheaper and DeepSeek offered off-peak discounts.

  3. The idea that subscription users pay a flat fee and some users consume dramatically more than they pay for, incurring a negative contribution margin, effectively being cross-subsidised by a much larger cohort of users with dramatically lower intensity usage.

  4. I don’t know if this is really going to happen but it seems at least fairly plausible looking forward from July 2026.

  5. Not financial advice, I have no idea what’s going to happen; probably they take over the world and hit market cap $400tn.

  6. Underlying research performed by GPT-5.6 Sol.

  7. Append length is extremely skewed: the p90 is 5,342 tokens but the p99 is 232,206. The mean is raised by initial prefills and occasional cache misses, which generally occur when the cached prefix is short.