Claude Sonnet 5 Limits: Context Window and Usage Caps

Claude Sonnet 5 has a 1 million-token context window in beta via the API, compared with 200,000 tokens on Claude's Free consumer plan. At Layer3Labs, we build agent workflows that regularly push those limits, and we've learned that the number on the spec sheet rarely reflects what matters in day-to-day use.

Anthropic released Sonnet 5 on June 30, 2026, positioning it as a mid-tier model built for high-volume use. In practice, its limits show up in three places: the context window, the usage cap for your plan, and a tokenizer change that quietly reduces how much space your own documents take up.

Claude Sonnet 5's Context Window

Sonnet 5 supports a 1-million-token context window in beta on the Anthropic API. That is enough to hold roughly 750,000 words, or a few hundred pages of contracts, transcripts, or code, in a single call.

Free users get less room. Claude's Free consumer plan caps Sonnet 5 at a 200,000-token context window instead of the full 1-million-token beta. Pro, Max, Team, and Enterprise plans use the API-tier window when you access Sonnet 5 through those surfaces.

Go past the ceiling and content gets cut. Once a request exceeds the active context window, Sonnet 5 drops or truncates earlier content rather than processing all of it, which shows up as missing detail or an outright error on a long document job.

• API (beta): 1,000,000-token context window
• Claude Free plan: 200,000-token context window
• Exceeding the window truncates earlier content or returns an error

The Tokenizer Change Shrinks Your Real Window

Sonnet 5's context window counts tokens, not words. Its tokenizer produces roughly 30 percent more tokens for the same text than the tokenizer on Sonnet 4.6 did, per Anthropic.

That eats into the ceiling. A 1-million-token limit that used to hold a document of a given length now holds less of that same document, because each page consumes more of the budget. A contract that used to fit comfortably inside 700,000 tokens can now push past 900,000.

Test your longest real documents against the live token count first. Do not reuse an estimate from the prior model, since a fixed page or word capacity assumption will be wrong.

• Sonnet 5's tokenizer uses about 30% more tokens per document than Sonnet 4.6
• The same 1M-token ceiling now fits less of a given document
• Re-test long documents rather than reusing an old token estimate

Usage Caps by Claude Plan

Claude's Free plan caps Sonnet 5 usage at roughly half of the Pro plan's weekly allowance, on top of the smaller 200,000-token context window.

Pro raises that cap. It adds access to the Opus tier and Claude Code. Max goes further still, starting at 5 times the Pro allowance for $100 a month, with a 20-times tier available at a higher price, and it also raises the output limit per response.

Team and Enterprise work differently. Both set usage by seat and contract rather than a single shared cap, with Enterprise usage billed at API rates on top of the per-seat fee.

• Free: ~50% of Pro's weekly usage allowance
• Pro: full weekly allowance, adds Opus and Claude Code
• Max 5x / 20x: 5 or 20 times the Pro allowance, higher per-response output limit
• Team / Enterprise: usage set by seat and contract, Enterprise billed at API rates

Rate Limits and What Anthropic Has Not Published

Anthropic has not published a fixed requests-per-minute or requests-per-day figure for Sonnet 5. Treat any specific rate-limit number you see elsewhere as unconfirmed until you check your own API console.

Limits are not fixed in practice. API rate limits scale with your usage tier and billing history rather than a single published ceiling, and they can be raised on request for a workload that needs it.

Parallel calls are the risk. Check your current limit in the API console before launch, because a burst of parallel jobs hitting an unannounced cap is a common way a demo passes testing and then throttles in production.

• No published fixed rate-limit number for Sonnet 5 as of this writing
• Limits scale with usage tier and billing history
• Check your live cap in the API console before a parallel-heavy launch

Workarounds When You Hit a Limit

Chunk long documents into sections that fit comfortably inside the active context window, and summarize earlier sections instead of resending them in full on every call.

Cache what repeats. Any content you reuse across requests, such as a system prompt or a reference document, should not be billed and capped twice on the same material.

Route overflow work to a smaller or cheaper model when a task does not need Sonnet 5's full capability, and queue bursty jobs instead of firing them all at once.

Chunking text to fit the token limit was not enough on its own for a document-heavy build we ran for a regulated client. An embedded table or scanned attachment could still trip a separate file-size cap later in the pipeline. We added a check after every step instead of only checking the final output.

• Chunk long documents; summarize earlier sections rather than resending them
• Cache reused content to avoid spending the same tokens twice
• Route overflow work to a cheaper model and queue bursty jobs
• Check every pipeline step's output, not only the final result

Custom Limits for Team and Enterprise Plans

Team and Enterprise customers can usually negotiate limits that the published consumer plans do not offer. A high-volume support desk or a document-processing pipeline running thousands of calls a day is a normal reason to ask.

Enterprise adds SCIM (System for Cross-domain Identity Management) provisioning and centralized billing on top of usage negotiated per contract, which matters once more than a handful of seats need consistent access controls.

Ask early. A limit increase negotiated before launch is a contract line item. The same request made after a production outage is an emergency call to support, and it rarely gets answered as fast.

• Team/Enterprise limits are negotiable, unlike the fixed Free/Pro/Max caps
• Enterprise adds SCIM provisioning and centralized billing
• Request a higher limit before launch, not after a production incident