Theo and ThePrimeagen on AI Subscriptions, Compute and Model Economics

I use AI more and more in development, while my friend ThePrimeagen is more skeptical. In his video about the AI economy, he argues that the generosity of current subscriptions is changing. I agree with much of his central point, but I think the role of compute capacity and the economics of model training deserve more detail.

Prime starts with a reported pricing-page test involving Claude Code and the $20 plan. A painted-door test can expose proposed pricing to measure interest without necessarily implementing it. I interpret the possible change as an attempt to manage expensive demand and limited compute; the company’s full motives and the test’s results are not established here.

The issue predates that example. Cursor previously charged partly by message count, but requests can differ enormously in cost: one message may need a short answer while another launches a long agent run. Cursor pays model providers for inference, so a fixed number of messages can expose it to very uneven costs.

Anthropic experimented with higher off-peak usage, then introduced a peak-hour adjustment to five-hour limits while leaving weekly limits unchanged at that point. I see this as an effort to shift demand toward periods when hardware is less busy. That interpretation is plausible, but the experiment’s private results are not public evidence.

I have heard estimates that some heavy users receive thousands of dollars of inference at API list prices under a $200 subscription. That comparison is not the provider’s actual internal cost or proof that every subscriber is subsidized by that amount. Request mix, contracted prices and the provider’s own cost structure are unknown.

My hypothesis is that enterprise demand and scarce capacity influenced Anthropic’s decisions more than simply persuading individual subscribers to upgrade. Both revenue and capacity can matter, and the public evidence in this discussion does not establish the precise weight of each motive.

Prime argues that the apparent margin on a model request can be misleading if it ignores the cost of building the model. A request’s revenue may exceed its immediate serving costs while the business still has to cover hardware, training, staff, research and other expenses. Revenue alone is not profit.

I agree that heavy subscriptions complicate the picture, but my figures about electricity and inference costs are estimates, not audited provider accounts. Electricity prices vary by location, and total serving cost is not interchangeable with electricity alone. A meaningful profitability analysis needs actual usage, capacity costs and allocation of fixed costs.

Dario Amodei offers a deliberately simplified example: spend $100 million to train a model, later earn $200 million from it, and spend $1 billion on the next model. On a company-wide timeline the increasing investment can produce a loss, even if a particular model’s revenue exceeds its allocated training and serving costs.

The example helps separate unit economics from overall cash flow, but it does not establish actual profit for any named model. It also depends on assigning shared infrastructure, research and serving expenses appropriately. Rapidly growing investment can overwhelm current revenue even when a previous model was commercially useful.

Prime worries that a model replaced quickly may not earn back what it cost. I think it matters whether a release required a new pre-training run or was an iteration on an existing base. Later versions may reuse substantial work, although the exact training histories and costs of proprietary models are generally not public.

As a rough conceptual distinction, pre-training builds broad representations from data, while post-training shapes and improves behavior through additional methods. This is a simplification: both can affect capabilities, and their boundaries and costs depend on the particular training process.

Reinforcement learning and other post-training techniques can improve behavior on tasks such as coding and tool use. An open-weight base can be adapted by another organization, as in Cursor’s Composer 2 example discussed here. The presence of open weights does not make the work trivial or free.

I expect many iterations to cost less than a fresh pre-training run, but there are important exceptions: post-training can itself consume enormous compute. My guesses about which Opus releases reused a base and their dollar costs are not disclosures from Anthropic. Release cadence and perceived behavior are not enough to prove a training recipe.

Prime cites a large OpenAI investment and translates it into an estimated monthly burn rate. The underlying financing terms, spending period and cash flows would need separate verification before treating that calculation as a financial statement. His broader concern is that these services must eventually support their costs.

The discussion moves to GitHub Copilot’s move away from simple request-count pricing. Prime emphasizes that different models cost different amounts. I think there is another problem: even two requests to the same model can consume very different amounts of compute, especially when one runs tools for hours.

Charging by request count resembles charging for a shopping cart by the number of items without considering what the items are. Model multipliers partly distinguish models, but they do not necessarily account for a short reply versus an extended agent session. My own long-running example illustrates why those units can be awkward.

In the interface I showed, GPT-5.4 had a 1× request multiplier, GPT-5.5 had 7.5×, and Claude Opus 4.7 had 15×. These were the displayed settings at the time, not current pricing. I estimated that one of my lengthy runs could be expensive at API rates; that was not a measured internal cost to Microsoft.

I argue that provider capacity and opportunity cost can influence pricing and access: a GPU serving one workload cannot simultaneously serve another in the same way. Financial margins can also matter. The public multiplier alone cannot tell us exactly how Microsoft weighted capacity, API cost, product strategy or revenue.

I point to a reported pause in signups as a sign that capacity may be limiting growth. A pause can have multiple operational and commercial causes, so it should not be treated by itself as proof of one exclusive motive. Prime and I agree that the subscription economy is changing; we disagree about the relative importance of the drivers.

Prime contrasts Microsoft, which has other profitable businesses, with a model lab raising money for research. I think having cash does not immediately create more chips or data-center capacity. Hardware availability and lead times can constrain even a wealthy company, although that does not remove the need to manage costs.

There is precedent for services limiting new subscriptions when demand exceeds capacity. I cite an earlier ChatGPT Plus signup pause. It shows that operational limits can affect access; it does not prove that all later subscription changes at other companies had the same cause.

Prime sees Google’s financial strength as an advantage. I agree that Google has substantial resources but point out that it also offers AI-powered features to users without a separate charge, including search experiences. A free user-facing feature still consumes resources somewhere, although its exact incremental cost is not visible from a search result.

I also discuss reports of restrictions around Google’s developer tools and subsidies for access to models. My assessment of those products is subjective, and the examples I cite do not establish that Google spent more than every competitor or reveal its internal capacity allocation.

Rising demand can also affect businesses buying inference directly. Prime mentions a report about Uber’s AI budget; I argue that enterprise API spending and individual subscription prices are different economic arrangements. A claim about a particular company’s spending or contract requires its own evidence and should not be generalized to every enterprise.

I compare consumer subscriptions with commercial services on terms, privacy and retention. Anthropic distinguishes individual Free, Pro and Max terms from its commercial API and team offerings; whether a particular work use is permitted depends on the applicable terms and circumstances. The AI-generated legal interpretation shown in the video is not an authoritative legal determination.

Data-use preferences and exceptions matter too. Anthropic describes a choice for consumer data used to improve models, while commercial data handling follows different terms. Organizations should examine current policies, contracts and their own security requirements rather than assume that all personal plans train on all data or that a single setting settles every issue.

Prime does not predict that the world will abandon AI; he expects companies to find a viable model while users see restrictions and changing economics. I agree that the offerings are changing, but I question whether the effective cost of useful work necessarily rises as fast as subscription limits tighten.

A model can cost more per token yet complete a task with fewer tokens. In the Artificial Analysis chart shown at the time, GPT-5.5 medium and GPT-5.4 xhigh had similar aggregate scores, while the displayed benchmark-suite costs were about $1,199 and $2,851 respectively. This is a historical benchmark comparison, not a guarantee of equal quality or lower cost on every task.

The displayed GPT-5.5 xhigh benchmark cost was around $3,357 versus $2,851 for GPT-5.4 xhigh, despite a larger per-token price difference. The total depends on the benchmark, model configuration, token counts and prices used. The point is to compare cost for an outcome, not only the price of a token.

The low setting in the chart cost about $500 to run and scored below the higher settings. That may be a useful tradeoff for some work, but a single aggregate score cannot capture every task, reliability requirement or preference. Teams should benchmark their own workloads.

The chart also showed large differences in token counts between model settings. Efficiency gains can make useful work cheaper even when the most capable setting remains expensive. That does not mean costs fall for every provider, and total bills can rise if a team uses more AI or runs longer agents.

I return to Copilot’s model multipliers and suggest that scarce capacity and enterprise demand might explain the gap. That remains my hypothesis: benchmark-suite cost and a provider’s request multiplier measure different things, and neither reveals the provider’s private economics on its own.

Prime and I agree on the important point: the economics are shifting and users should not assume today’s generous terms will remain unchanged. I am more optimistic about the improvements in model efficiency and more inclined to emphasize compute constraints. I have revised my own forecasts before, and expect to keep learning as the evidence changes.