The "AI Is Subsidized And You're About To Get Way Less Use And Pay Way More" Argument Is Wrong

Because it misses the only thing a business actually cares about.

Everyone runs the same math: price your usage at published API rates, get a number five to twenty times your subscription, conclude you're being subsidised and the bill is coming. I ran that math myself, on this page, after watching a five-hour session vanish in five minutes. Then I went looking for the number that would confirm it — and found the opposite.

A crowd stares up at an enormous ornate brass pressure gauge with its needle buried in the red, while a small plain machine runs quietly and unnoticed on the floor behind them.
The needle everyone is watching is the published API price list. The thing that decides the outcome is the little machine nobody turned around to look at.

What's In This One

  1. The Rationing Habit — and What I Finally Did Instead
  2. Where It Broke
  3. The Real Lesson: Frontier Models Will Overthink and Over-Spawn If You Let Them
  4. The Fix: Triage Before You Delegate
  5. The Part I Actually Have to Learn, Same as Everyone Reading This
  6. The Argument Everyone Is Making — And The Number It Skips
  7. What I Think Happens Next
  8. The Bottom Line

For weeks before any of this, I'd fallen into a habit I didn't clock as a problem until I was writing it up: quietly rationing my Claude Code usage. Holding off on ambitious asks because I wasn't sure they were worth "spending" a session on. Breaking tasks into smaller pieces than they needed to be. Watching the meter more than I was watching the actual goal. That's a sunk-cost trap wearing a budgeting costume — I was spending real attention managing a number instead of just doing the work the number was supposed to enable.

Then Anthropic shipped Fable, its priciest, most capable model, and I decided to stop rationing and actually use what I was paying for. I pointed it at something I'd been meaning to do for weeks: build out a real research library — drug and supplement timing, interactions, raw-vs-cooked nutrient science, all citation-verified against primary sources — to feed a health project I'm building. Legitimate, useful, exactly the kind of deep-but-tedious work AI is supposed to be good at absorbing.

One entire 5-hour session was gone in about five minutes of real work. Not because I wasted it — because Fable did exactly what I asked, at frontier prices, faster than I had any intuition for. Weeks of careful rationing, undone by five minutes of actually using the thing.

Part I

The Rationing Habit — and What I Finally Did Instead

I asked Claude to research 60 topics and fact-check every claim against a real, independently verifiable source before any of it went near a page I'd publish:

That's not a small ask, and I said yes to doing it the expensive-but-correct way: no fabricated citations, ever — I've been burned by that before.

That wasn't even the whole list. In the same window I was also chasing a genuinely ambitious, arguably ridiculous side-goal: trying to model how AI itself is going to transform the stock market — which sectors get hollowed out, which get supercharged, on what timeline — for a separate research project. Two different kinds of hard problems, both legitimate uses of frontier reasoning, both happy to eat as much compute as I'd hand them.

Claude Code has a tool for exactly this. You describe the shape of the job and it spins up a swarm of sub-agents — one per research topic, then a second wave to adversarially verify each one, then a synthesis pass to pull it all together into something usable. On paper, this is the dream: instead of me grinding through 60 topics one at a time, dozens of instances work in parallel and hand me a finished library.

It worked. The research is genuinely good — every one of those 60 entries independently source-checked, several twice. But getting there cost a lot more than I expected, and it cost it fast.

Part II

Where It Broke

Two separate times, mid-run, I hit a wall. The tool itself reported it as "You've hit your monthly spend limit" — which turned out to be wrong. What I'd actually hit, both times, was the ordinary session limit: Claude Code runs in rolling 5-hour blocks, and a heavy enough burst of work can exhaust an entire block in minutes, not hours. The error message named the wrong ceiling, but the ceiling was real either way.

That's the mechanic worth sitting with. It's not that I ran out of runway for the week — I had days of it left. It's that a single 5-hour session can vanish in minutes if you point enough parallel work at it. And once it's gone, it's gone until that session's own clock runs out.

The math that actually matters

  • 5 hours — the size of one Claude Code session block
  • Minutes — how fast a heavy parallel workflow can exhaust it
  • 4.5+ hours — how long you can end up waiting before you're allowed back in, even with a mountain of weekly runway still sitting unused on the other side of the wall

Both times the fix was the same: resume the job from where it cached off once the session reset, and it picked up cleanly. But the pattern was obvious by the second hit. A single research task — genuinely useful, not wasteful — had, on its own, chewed through roughly 9 million tokens across two sessions, worth something in the neighborhood of a normal month's subscription cost, inside a matter of minutes each time.

That's when I stopped and asked the model itself to explain what was actually happening to the spend. It told me straight: the workflow had fanned out into dozens of parallel sub-agents, each one a full Fable call — Anthropic's most expensive model, at Anthropic's most expensive per-token rate — each one thinking through its slice of the problem independently before the results got merged back together. Powerful. Also, apparently, expensive enough to flatten a 5-hour session in the time it takes to make coffee, if you don't watch it.

Nobody lied to me, exactly, but the tool's own error message did. I could see the usage panel the whole time, and it never once said "monthly" was the real limit — that framing came from the workflow tool itself, and it was simply mistaken. The gap that actually got me: "I can see the number going up" is not the same as "I have an intuitive feel for how fast an entire session can go up," and that's exactly where I fell.

Part III

The Real Lesson: Frontier Models Will Overthink and Over-Spawn If You Let Them

Here's the part that actually changed how I work, not just what I noticed. Partway through, I realized one piece of the job — "for every drug and supplement, tell me: with food or empty stomach, needs fat or not, how much water, what to space it away from" — wasn't a research project at all. It was almost a single prompt. A plain-language question a frontier model could answer directly, in one pass, as a table, using knowledge it already had.

Even GPT‑4 or Sonnet 3.5 could have handled this just fine in a single prompt in 2024. But the 2026 model spun up a crazy amount of excess work and overthinking.

That's the part that stopped me. This wasn't a case of new capability requiring new overhead — it was more capability finding more ways to spend itself on a question that hadn't gotten any harder in two years.

I'd been about to let the same 60-agent-swarm machinery handle it anyway, because that machinery was already running and it felt like the path of least resistance. It would have worked. It also would have been absurd — dozens of expensive parallel agents individually re-deriving something one plain conversational turn could produce for a fraction of the cost.

That's the actual lesson, and it generalizes past this one afternoon: a frontier model, left to its own judgment about how to tackle a task, will reach for its most powerful tools by default — more agents, more reasoning depth, more verification passes — because more capability is genuinely available and genuinely improves the odds of a good answer. Nothing in the model is incentivized to ask "could I do this the old-fashioned simple way instead?" That instinct has to come from the human giving the instruction.

The fix isn't "use AI less." It's "tell AI how much AI to use." Caution a frontier model, explicitly, to do the simple version of a task the plain old-fashioned way unless the complexity genuinely earns a swarm of agents. Left unsupervised, it will happily spin up 100 agents to answer a question that fit in one paragraph — not out of malice or incompetence, but because you never told it not to.

Part IV

The Fix: Triage Before You Delegate

Once I switched to a cheaper, faster model and finished the last stretch of the job by hand — reading files directly and writing the synthesis myself instead of spawning another agent wave — the whole afternoon reorganized itself into a system I've now written down and will reuse every time this comes up again.

The idea is simple: before you let a frontier model loose on a big multi-part task, have a frontier model — the smartest one you've got — look at the whole task first and sort it into tiers by how much horsepower each piece actually needs. Then route each tier to the cheapest model that can actually do it.

Tier What lives here Model to use
Judgment / architecture The plan itself: what's the actual shape of this job, what can run in parallel, what's a trap that looks bigger than it is Top-tier frontier model, used once, briefly
Deep execution Genuinely hard reasoning steps that need real capability, one at a time Strong mid-tier model
Bulk mechanical work Formatting, straightforward lookups, drafting from a clear template, verification passes Fast/cheap model
"Almost a single prompt" Anything that turns out, on inspection, to just be a question with a knowable answer One plain conversational turn — no agents, no swarm, no tools

The single most valuable move in that whole system is the last row: catching the tasks that only look like they need machinery. That's exactly what the "how should I take each supplement" question turned out to be, and it's probably the single most common way solo operators like me overspend on AI — not through recklessness, but through defaulting to the biggest hammer because it's already in hand.

I've saved this as a reusable skill — a written methodology I can invoke by name in future sessions, so the discipline doesn't depend on me remembering it mid-crisis next time the meter's spinning. The short version: plan with the smartest model, execute with the cheapest one that can actually do the job, and always ask "is this secretly just a question?" before reaching for a swarm.

You don't need to re-paste a big prompt every time, either. Do it once: hand your AI tool the rule set below and ask it to fold the rules into its persistent project instructions (Claude Code calls that file CLAUDE.md; other tools have their own equivalent memory or system-prompt file). After that one-time setup, a short trigger phrase is all you need before any big task:

Prioritize this all and tell me what parts of this task
require which model and effort level, before proceeding.

That's genuinely all it took, once the rules were saved. Here's what it looked like in practice, in a separate project:

  • Me: "Proceed with tier A tasks."
  • It: worked through the whole list, then said on its own — "Okay, switch to Opus, then run list B."
  • Me: switched models, said go.
  • It: picked up exactly where the plan left off.

Everything cohered. Progress was cached the whole way through in case anything got interrupted. I never once had to re-explain the system mid-task.

Here's the one-time setup prompt — paste it once, ask your AI to absorb it into its permanent instructions, and you're done:

ROUTING RULES — save these to your permanent project
instructions / memory file (don't just answer in chat —
write them to disk so they persist across sessions).

You are the PLANNER, not the executor, of this task.

1. Read the whole task before doing any of it.
2. Break it into a numbered list of subtasks.
3. For EACH subtask, assign the LOWEST-tier model/effort
   level that can plausibly produce an EXCELLENT result —
   not "good enough," excellent. Never round up "just
   in case."
4. Any subtask that's really just a knowable question gets
   tagged ZERO-TIER: answer it directly, right now, in this
   reply. No agents, no tools, no swarm.
5. My available tiers, cheapest to most expensive:
   - [tier 1 — your cheapest/fastest model]
   - [tier 2 — your mid-tier model]
   - [tier 3 — your most expensive/frontier model]
6. Show me the routed list before executing anything.
7. As each subtask finishes: if a downshifted result came
   out shallow, wrong, or clearly straining above its tier,
   don't silently redo it higher. Flag it "[!] needs a
   higher tier" with a one-line reason, and keep moving.
8. At the end, show me every "[!]" item together so I can
   decide what's worth re-running.
9. From now on, whenever I say "prioritize this all and
   tell me what parts require which model and effort
   level, before proceeding" — run this exact process
   without me re-pasting these rules.
Part V

The Part I Actually Have to Learn, Same as Everyone Reading This

Here's the honest complication in writing an article about AI usage limits: I've probably been overusing AI anyway, limits or no limits. Not just on this one research library — on basically everything else I touch.

None of that is really an AI problem. It's an old problem — the "a million ideas, no way to execute" pattern that anyone with ADHD, or honestly anyone with a restless enough brain, recognizes instantly. AI didn't create that pattern. It just removed every piece of friction that used to slow it down. Building used to be the bottleneck that forced you to finish one thing before starting the next. Now building takes minutes, so the bottleneck moved — it's not "can I build this" anymore, it's "can I stop myself from building the next seven things instead of finishing this one." I haven't solved that. I'm writing about usage limits from outside a subscription plan while still very much inside that trap.

There's real research behind why this isn't just an ADHD thing. Psychologists Sheena Iyengar and Mark Lepper's well-known 2000 study on choice overload — the famous grocery-store jam-tasting experiment, published in the Journal of Personality and Social Psychology — found that a bigger display of options drew more browsers but converted far fewer of them into actual buyers than a smaller display did. Too many good options doesn't just feel harder to choose from; it measurably lowers the odds anyone finishes the choice at all. (Later replications found the effect is real but smaller and more conditional than the original headline suggested — it shows up most reliably when the options are similar and the stakes feel high, which describes an awful lot of AI-assisted "what should I build next" moments.)

Source: Iyengar, S. S., & Lepper, M. R. (2000). "When Choice Is Demotivating: Can One Desire Too Much of a Good Thing?" Journal of Personality and Social Psychology, 79, 995–1006.

If that's roughly right, a hard usage ceiling isn't only an inconvenience. It might be the first honest constraint a lot of us have had on this tool since it arrived. Scarcity forces sequencing. You can't spin up a sixth marketing plan for the same offer if finishing before the meter runs out matters more than generating the next idea. A limit that makes you choose is a limit that makes you ship.

That's the quieter, more optimistic version of everything else in this piece. The current era — nearly-free frontier intelligence, no real cost to trying six directions at once — is, in its own way, the Angelfire-and-GeoCities phase of AI: everyone throwing up whatever they can build the moment they can build it, because building suddenly got free and nobody's learned restraint yet. Real limits, even annoying ones, are usually what pushes a technology out of that phase. The web didn't mature by staying free-for-all forever; it matured once the cost of building things badly started to matter again, and the people who wanted actual results learned to build fewer things, better. I'd bet AI use goes through the same evolution — and honestly, I could use the push.

Part VI

The Argument Everyone Is Making — And The Number It Skips

Here is where I was heading, and where very nearly every piece written about this lands. You have read it a hundred times by now — on Substack, in YouTube titles, in the replies under any post about AI pricing:

Work out what your monthly usage would cost at the published API rate. It comes to five, ten, twenty times your subscription. Therefore you are being subsidised by the difference. Therefore, when the land-grab ends, your bill rises by that multiple or your usage gets cut to match.

I believed it. I wrote a version of it on this page. Having just watched the overage cliff swallow a session in five minutes, it felt obviously true, because I thought I had seen the "real" price arrive all at once.

Then I went looking for the number that would confirm it, and found something else.

API list price is not a cost. It is a price.

This is the entire error and it is almost embarrassingly simple. The published API rate is a retail price with margin already inside it. Using it to estimate what your usage costs the provider is like working out a hotel's operating costs from the rack rate on the back of the door.

The gap between your $100 subscription and its $2,000 API-equivalent is not a measure of subsidy. Most of it is margin, and the rest is that you are comparing two genuinely different products. API access is metered, guaranteed, free of rate limits, and resellable. A subscription is pooled, throttleable, and can be quietly routed to a cheaper model when the servers are busy. Those things should not cost the same, and the distance between them tells you nothing whatsoever about anyone's cost of delivery.

And the token count is inflated too

There is a second error stacked on top of the first, and it is the one I only noticed from my own habits.

I compact my Claude sessions maybe five times a day across several running chats. Every time, it tells me roughly how much it just cleared — frequently something in the region of half a million tokens. So I have a fairly vivid sense of the sheer volume moving through a working day. That volume is real, and it is exactly where the commentators are getting their raw material: genuine token counts, pulled from genuine usage-tracking tools, and then multiplied by the published API rate.

The problem is what those tokens actually are.

In a long session, the entire conversation gets re-sent with every single turn. That is how these models work — they are stateless, so the context comes back around each time. Count naively and the same half-million tokens get tallied again, and again, and again, once per exchange. Your usage meter is measuring throughput, not fresh work.

Repeated context is cached, and cached tokens are a different economic object entirely. Anthropic bills cache reads at roughly 10% of the normal input rate. The underlying cost is lower still, because the expensive part — the forward pass across that prefix — has already been done and the result is sitting in memory. Re-reading it is nothing like computing it.

So the popular calculation manages to get both halves wrong at once. It takes a token count inflated by re-transmitted context, and prices it at the un-cached retail rate, which is itself a price rather than a cost. The two errors multiply. An honest version of that sum lands somewhere far below the terrifying number, and the terrifying number is the one that gets the thumbnail.

The only question a business actually cares about

Forget what your usage would cost at list price. The question that decides everything is narrower:

Is the company selling inference for more than it costs them to deliver it?

That is gross margin, and it is the number that determines whether a price can hold. Everything else — training bills, data centres, investor patience — is a financing question. Financing questions have completely different consequences, and we will get to them.

That number is not secret, and it is not what the subsidy argument assumes.

What's measuredThenNow
OpenAI compute margin (revenue left after paying to serve)~35% (early 2024)~70% (late 2025)
Anthropic inference margin38%70%+
Anthropic compute cost per $1 of revenue$0.71 (Q1 2026)$0.56 (Q2 2026)
Anthropic internal gross-margin guidance50–63% (2026)75–77% (2028 target)

Both frontier labs roughly doubled their serving efficiency in about eighteen months. Inference is not the loss leader. It is the profitable part, and it is getting more profitable.

The most-quoted piece of evidence is eighteen months stale

The single most cited proof of the subsidy thesis is Sam Altman saying OpenAI was losing money on its $200-a-month ChatGPT Pro plan because "people use it much more than we expected."

He said that in January 2025, when OpenAI's compute margin sat somewhere around 35%. It has roughly doubled since. The quote still gets recycled in 2026 as if it described current economics, when what it actually describes is a cost regime that no longer exists. It was true when he said it. It has been quoted well past its expiry date.

So where is the money actually going?

It is going, and the hole is enormous. It is simply not the hole your subscription is filling.

OpenAI has been reported to be burning in the region of $8 billion a year while carrying that 70% compute margin. Those two facts are not in tension. The burn sits in training runs, research salaries, and data-centre commitments, against industry capital expenditure running into the hundreds of billions for 2026 alone.

This distinction matters more than anything else on this page, because the two situations break in completely different ways. If serving lost money on every call, prices would have to rise hard and soon or the service would have to stop, which is the collapse everyone is forecasting. If serving makes money and the losses sit in research, the pressure valve is not your bill at all. It is the R&D budget. What gets cut is the next model, not the one you are already using.

What I think actually happens

Not a price rise. Something quieter, and much harder to complain about:

The squeeze arrives as degradation, not as an invoice. Your bill stays $100. What $100 buys gets smaller: tighter rate limits, a cheaper model quietly serving the same conversation, hard caps where the limits used to be soft. "Unlimited" becomes "generous," which becomes "sufficient."

For a company with healthy serving margins that is a far easier lever to pull than a price rise, and a far harder one for a customer to notice, measure, or protest.

Where the subsidy crowd is right

I would rather steelman this properly than win it cheaply. Everything below cuts against what I just argued:

Why the loud version is the one you keep hearing

Two selection effects, and they compound. The person calculating their $2,000-a-month API equivalent is, by definition, among the heaviest users on the platform. Subscriptions run on gym-membership economics: a pool dominated by light users, quietly paying for the few who turn up every day. The person writing the post is the guy at the gym six mornings a week, generalising from his own quads to the entire membership.

And "you are being subsidised, the bill is coming" is simply a better headline than "serving margins appear healthy and improving." One of those gets watched. The other one is this article.

Sources for this section: 80,000 Hours analysis of AI lab economics (Aug 2026); reporting on OpenAI and Anthropic compute margins via SaaStr and Yahoo Finance; Ed Zitron, "Anthropic's Profitability Swindle"; Anthropic's published prompt-caching rates (cache reads at ~10% of base input); Altman's January 2025 remarks on ChatGPT Pro; Bloomberg, CNBC and Fortune on the Kimi K3 release. Margin figures are reported rather than audited — no lab publishes inference cost of goods sold, and I have flagged the disagreements above rather than quietly picking the most convenient number.

This Isn't Just a Western Story

One thing the pricing outside the US clarifies: a promotion ending is a real event, and it is a different event from costs catching up. Watch which is which below.

The release pace is the other half of it. Moonshot shipped Kimi K3 in July 2026 — 2.8 trillion parameters, a million-token context window, open weights, benchmarked against the frontier rather than politely beneath it. Chinese labs are now landing frontier-class models faster than the subsidy argument's timeline assumes, with different cost structures and different reasons to price the way they do. That matters, because the whole thesis quietly depends on pricing power arriving once the land-grab finishes. Pricing power requires somewhere for customers not to go.

The same week I was writing this, Moonshot AI in China released Kimi K3 — a new 2.8-trillion-parameter model with a 1-million-token context window. My first assumption was "cheap Chinese alternative, undercutting Western frontier pricing." That assumption turned out to be wrong, and the way it's wrong is the actual point.

Model Price per 1M tokens (in / out) What that tells you
Kimi K3 (Jul 2026) $3 / $15 Priced at direct parity with Claude Sonnet — not a discount play, a capability-parity claim
Kimi K2.6 / K2.7 $0.95 / $4.00 The actual "cheap Chinese model" tier — this is what genuinely undercuts Western pricing
DeepSeek V4 Pro $0.435 / $0.87 Had a 75% introductory discount that expired May 31, 2026 — the rate then jumped straight to roughly 4x
DeepSeek V4 Flash $0.14 / $0.28 The genuine bargain-bin tier, small-model-scale pricing

Two things jump out:

There's also a practical wrinkle in treating "open-weight" as an escape hatch from any of this: Kimi K3's 2.8 trillion parameters make it a non-starter for genuinely local, on-your-own-hardware use — nobody is running this on a home rig. "Open weight" mostly benefits well-capitalized resellers who can rent the GPUs and undercut on hosting, not individuals looking to sidestep the subsidy cycle entirely.

The wall doesn't move. It just relocates — to a different company's balance sheet, on a different continent.

Sources: MarkTechPost on Kimi K3's specs and pricing; VentureBeat on the K3 launch; Kimi API pricing (K2.6/K2.5); DeepSeek/Kimi/Qwen/GLM pricing comparison.

Part VII

What I Think Happens Next

Worth noting before the list: these were written under the old framing, and they hold up better under the new one. Auto-routing to cheaper models and flat plans quietly getting less generous are precisely what you would expect from labs optimising a margin that is already positive — not from a company desperately trying to stop the bleeding.

None of this is inside information — it's a solopreneur's honest read after living through it once. Here's what I'd bet on, roughly in order of how confident I am, for you to poke holes in:

I don't think any of these are exotic. They're mostly just "what happened in every other compute-intensive tech category, applied here." The interesting question isn't whether they happen — it's which order, and how fast.

The Verdict

The Bottom Line

The runway wasn't wasted — the research library that came out of that week is genuinely good, and I'll be using it for months. But the way I got there was inefficient in a way I didn't have to accept, and wouldn't have accepted if I'd built the triage habit before the meter started running instead of during.

Growing pains, not a warning sign. This is what it looks like to actually run into the limits of a still-subsidized technology for the first time, instead of just hearing about it secondhand. It's not a reason to pull back from using AI hard — it's a reason to get deliberate about which model does which piece of the work, before you hit the wall instead of after.

My honest advice to anyone building the way I do — fast, with AI doing real load-bearing work rather than autocomplete — has survived the correction, even though my reasoning for it did not. Build the model-tiering habit now. Not because your bill is about to multiply, which I no longer think is the likely failure mode, but because the limits around that bill will keep tightening while the number on it stays comfortingly the same. The people who feel that least are the ones who already knew which model each piece of the work deserved.

Watching the AI Economics So You Don't Have To

Real experiments, real costs, real lessons — from someone actually running a business on this stuff, not selling a course about it. No spam.

Unsubscribe anytime. Your email stays private.

Related on scovert.com

— Scott Covert. If you've hit your own version of this wall — or you think I'm wrong about where this goes — I want to hear it. Reach me here.

Follow Scott · Substack · Medium