Compute Capacity Belongs in Your AI Cost Model, Not Just Your News Feed

Key takeaways

• Anthropic signed an agreement for all of the compute capacity at SpaceX's Colossus 1 data center: more than 300 megawatts and over 220,000 NVIDIA GPUs, coming online within the month.
• On the same day, Claude Code's five-hour rate limits doubled for Pro, Max, Team and seat-based Enterprise plans, and the peak-hours limit reduction was removed for Pro and Max.
• API rate limits for Claude Opus models were raised considerably.
• None of that is a change to the published price per token, and yet it changes what a seat is worth.
• Capacity announcements are the closest thing this market has to a leading indicator for pricing pressure.

What actually changed

Anthropic published three changes, all effective the same day. Claude Code's five-hour rate limits doubled on Pro, Max, Team and seat-based Enterprise plans. The peak-hours limit reduction on Claude Code was removed for Pro and Max accounts. API rate limits for Opus models went up considerably.

Behind those three lines sits the reason: a partnership with SpaceX covering the entire capacity of the Colossus 1 data center, which Anthropic describes as more than 300 MW and over 220,000 NVIDIA GPUs arriving within the month. That sits alongside an agreement of up to 5 GW with Amazon, a 5 GW agreement with Google and Broadcom starting in 2027, a strategic partnership with Microsoft and NVIDIA including $30 billion of Azure capacity, and a $50 billion infrastructure investment with Fluidstack.

Why is a rate limit change a pricing event?

Because the price you actually pay is not the number on the pricing page. It is the number on the pricing page divided by the work you managed to get done.

If you are on a seat-based plan and your five-hour ceiling doubles, the seat costs the same and delivers more. Your cost per completed task falls. Nobody sent you a price-change email, but your unit economics moved.

The same logic runs in reverse on the API side. A raised rate limit does not lower your $ per million tokens, but it removes a constraint that was quietly forcing you to either queue work, over-provision fallback models, or route traffic to a second provider you did not really want to pay for. Those workarounds all had a cost. Some of it was in dollars, some of it was in engineering time, and most teams never attributed either back to the model line in their COGS.

How do you put capacity into a cost model?

Start by separating two numbers that founders routinely collapse into one.

The first is unit price: dollars per million input tokens, dollars per million output tokens. That is what the provider publishes and what changes when there is an actual price announcement.

The second is delivered cost per user: what one active user actually costs you in a month, given the model you route them to, the tokens they burn, the retries you eat, and the ceiling you hit. Rate limits, cache pricing and throughput all live here.

Most pricing mistakes happen because a team models the first number and bills against the second. When capacity moves, the second number moves and the first does not, so the model quietly drifts out of date.

What should you do this week?

Three things, in order of effort.

First, re-run your per-user cost with the new ceilings. If your heaviest cohort was throttled before, their real cost was higher than your spreadsheet said and your margin on them was worse than you thought. It may now be genuinely better.

Second, look at whatever you built to work around the old limits. Fallback routing, request queuing, a second provider held on standby. Some of that is now dead weight, and dead weight in an inference path is dead weight in your gross margin.

Third, decide whether any of the saving should reach the customer. It does not have to. But if you priced a tier defensively because throughput was uncertain, that defensiveness is now costing you conversions rather than protecting your margin.

Does more capacity mean cheaper tokens?

Not automatically, and it is worth being careful here. Capacity coming online reduces scarcity, and scarcity is one of the things holding prices up. But the same capacity is also being consumed by longer contexts, reasoning-heavy models and agent loops that make many more calls per user task than a chat interface ever did.

The honest read is that capacity announcements tell you the direction of pressure, not the size of the move. Treat them as a signal to re-check your assumptions, not as a promise of a discount.

The takeaway: your AI cost model has a capacity variable in it whether you wrote one down or not, so write one down.

If you want to see what the new ceilings do to your per-user numbers, you can model token cost per request, per user and per month in the Calcaas LLM cost calculator.