How the SpaceX Deal Lets Anthropic Double Claude Code Limits

The workflow that died at message forty-seven

I had been using Claude Code for about four months when I decided to build a document intake pipeline for a batch processing project. The idea was simple: an agent that could read a stack of contracts, extract the key terms into a structured format, flag anything that deviated from a standard template, and produce a clean summary for each document. Nothing exotic. The kind of work that previously required either a paralegal or a full afternoon of careful reading.

I am Madhuranjan Kumar, and I remember message forty-seven of that session because it was where the agent stopped. Not with an error I could troubleshoot. It stopped mid-extraction with a rate limit response that ended the session completely. The documents were not even particularly long. The agent had been producing good output, reading carefully and flagging the right clauses, and then the session ran out of runway while roughly a third of the work was still in the queue. I stitched together what had finished, completed the remaining third manually, and noted in my working file that this class of workflow was not ready for production. Not because the capability was absent. Because the infrastructure could not support an extended, serious job without hitting a wall.

That experience was not unusual at the time. It was the standard experience for anyone trying to use Claude for real document work rather than short conversational tasks. The rate limits were not a bug or an oversight. They were a symptom of a genuine resource constraint: more people wanted to run serious workloads through Claude than the available compute could support at peak times. Understanding that backstory is important for understanding why the changes that recently arrived matter more than a headline about doubled session limits suggests.

What compute actually means for an AI company

When people hear that an AI company has a compute constraint, the image that often comes to mind is servers running out of memory or bandwidth getting congested. The actual bottleneck is more specific and more fundamental. Running a large language model at scale requires dedicated hardware, primarily high-end graphics processing units, and the number of user requests that can be served simultaneously is directly proportional to the number of those units available and how efficiently they are allocated. When demand exceeds the available supply, the company faces a choice: let the system slow down for everyone, or implement rate limits that ration access so that at least some users get a reliable experience.

Anthropic had been managing this constraint through the mechanisms that frustrated builders for months: session time limits, peak-hours throttling that reduced effective session length during the busiest parts of the workday, and restrictions on Claude Code access for some plan tiers. These were not ideal solutions. They were the best available given the infrastructure at the time. Building out additional compute capacity takes time, capital, and physical hardware that cannot be sourced overnight regardless of how much money is available.

The situation changed when Anthropic secured a compute partnership with SpaceX. This partnership delivered a significant jump in available capacity, including a substantial number of high-end NVIDIA GPUs, acquired quickly rather than through the multi-year procurement timelines that enterprise hardware typically requires. The effect on the rate limits was immediate and concrete: Claude Code's five-hour session limits doubled for Pro, Max, and Team subscribers. The peak-hours throttling that had been eating into weekday morning sessions was removed entirely for Pro and Max accounts. And the Claude Opus API output limits on tier one rose from 8,000 tokens per minute to 80,000, a tenfold increase for the most capable model in the lineup. Lower tiers saw even larger multipliers.

Anthropic has also been securing compute through a range of other channels. Agreements with Amazon, Google, Broadcom, Microsoft, NVIDIA, and FluidStack are part of a broad effort to build the infrastructure foundation a serious AI company at this scale requires. The SpaceX deal added a particularly large block of capacity quickly, which is why the rate limit changes arrived together rather than in a gradual rollout. The long-term roadmap extends further still: both companies have expressed interest in orbital AI compute, multiple gigawatts of processing capacity running on hardware above the atmosphere. The reasoning is practical: terrestrial data centers face real physical limits on available power and cooling capacity in most regions, constraints that orbital infrastructure avoids entirely.

The infrastructure backstory behind months of throttling

Understanding why the limits existed is useful context for understanding why the changes are significant rather than cosmetic.

The periods of Claude outages and throttling that frustrated builders over the past year were not software problems. They were demand management during a period when the user base was growing faster than the infrastructure could scale to meet it. Every time the team loosened a restriction, usage climbed and pressure built again. The restrictions were the team's way of keeping the service reliable for users who could stay within bounds while they worked to build more headroom. The sessions that stalled at message forty-seven were not failing because of bad software. They were failing because the compute needed to finish the job was serving someone else's session at the same time.

This dynamic is worth understanding because it changes the right interpretation of the new limits. These are not marketing promises about what the system is theoretically capable of. They are operational commitments backed by capacity that already exists and has already been provisioned. The infrastructure that allowed the session limits to double is online. The peak-hours throttling was removed because the capacity to handle peak-hours demand without throttling has been secured. The Opus API ceiling rose tenfold because the GPU capacity to serve that throughput is there now rather than pending.

For builders who spent months working around Claude's constraints, designing prompts to minimize token usage, downshifting to smaller models to stretch sessions, timing serious workloads for off-peak hours, this is a meaningful shift. The architectural workarounds that became habits during the capacity-constrained period can now be relaxed in favor of workflows designed around what the system can actually support.

What doubled limits look like on a real document job

Let me return to the document pipeline that stalled at message forty-seven and describe what running the same job looks like now.

A law firm receives a bundle of 600 pages of contracts and wants a first-pass review against its standard playbook of preferred clauses and past negotiated positions. Previously, an Opus agent reading this material would routinely hit session limits partway through, leaving a partial review that nobody trusted for live matters. Completing the job required either restarting the session and picking up from where it stopped, with the attendant risk of inconsistency, or finishing the remainder manually. Neither option made the tool feel production-worthy.

With the higher Opus API limits and a usable million-token context window, the architecture changes. The firm's clause library, its redline history from the past two years, the full 600-page bundle, and its current standard template can all enter context in a single session. A set of parallel sub-agents divides the review work: one flags risky indemnification language and produces a structured list with page references and a plain-English description of each risk, a second checks termination clauses against the firm's standard positions and notes every deviation with the specific language the counterparty used, a third drafts a client-facing summary of the key commercial terms and identifies the three issues that need partner-level attention before the deal moves forward.

The attorneys review and sign off because judgment and accountability stay with the humans on any matter that reaches a client. But the first-pass review that used to take a full associate day now completes in minutes and finishes reliably, because the rate limit that killed it halfway through is no longer the binding constraint. The job moves from a demonstration of what is possible to a tool that gets used on real deadlines with real consequences.

For builders with multi-agent workflows, the doubled limits change the economics of parallelism in a concrete way. Previously, running several sub-agents simultaneously on a large task meant each agent was consuming space within a shared rate limit, and coordinating them required careful throttling that added both complexity and fragility. The failure mode was an agent that appeared to be running but was actually stalled waiting for the rate limit to reset. With the higher ceilings, you can design the parallelism first and manage the limit second, which is the right order of operations for building something that behaves predictably under load.

What to retest now that the ceiling moved

The most immediate opportunity is not to design a new workflow from scratch but to retest the workflows that broke during the capacity-constrained period.

Any Opus agent that failed on rate limits in the past several months is worth running again before you redesign it. The failure may have been entirely a capacity problem rather than a structural issue with the prompt or the workflow design, and running the same job under the new limits will tell you quickly whether that is the case. If it runs to completion without changes, you have recovered something valuable at no additional cost. If it still fails, you now know the remaining issue is in the design rather than the infrastructure, and you can fix the right thing.

After retesting existing work, the practical priorities are clear. Move routine automations onto Claude Code so they run in the background without competing with focused build time. Use Opus more freely for tasks where the quality difference over smaller models is meaningful and where you were previously downshifting to protect session length. Start treating the million-token context window as production-ready for jobs that benefit from holding large amounts of material in memory simultaneously.

One thing worth measuring as you scale: actual token consumption per job. Higher limits can mask inefficiencies in prompt design. A job that now finishes but burns far more tokens than it should is still costing money and will cause problems if you try to run multiple jobs in parallel. The breathing room from the increased limits is best used to build workflows properly rather than to paper over prompt design issues with the larger headroom.

The session that stalled at message forty-seven would complete today without modification. More importantly, the architecture that job deserved, parallel sub-agents reading large context reliably, is now viable in practice rather than just in theory. That shift from theoretical capability to practical reliability is where real business value enters, and the time to build toward it is now rather than after the next announcement.

One practical sequencing note for anyone starting fresh with these new limits: do not begin by designing the most ambitious workflow you can imagine. Begin by identifying the highest-value job that already failed on the old limits, the one where you know the capability is there because it was producing good output right up until the session cut out. Run it again unchanged. Measure whether it completes. If it does, you now have a reliable baseline to extend from rather than a theoretical spec to build toward. If it still fails, the failure mode is now design rather than infrastructure, and fixing a design problem is a different task than waiting for more compute.

For the law firm case specifically, the value of reliable completion extends beyond the direct time savings. A review process that sometimes finishes and sometimes needs manual intervention cannot be built into a firm's standard workflow for live matters. The uncertainty alone keeps it in the category of "interesting tool for low-stakes situations." A process that completes reliably can be built into the intake process, assigned a timeline, and handed to clients as part of the engagement. The doubled limits are the difference between a curiosity and an operational capability, and that difference is what determines whether the investment in building the workflow returns its cost.