Most quota problems look like degradation: traffic grows, 429s appear at peak, you request an increase. Claude Fable 5 on Microsoft Foundry presents differently — as total failure from the first request. Microsoft's published rate-limit table gives claude-fable-5 a default of 0 requests per minute and 0 input tokens per minute on standard pay-as-you-go Azure subscriptions. A successful deployment with a zero quota is a car with no fuel: everything is assembled correctly, and nothing moves.
The quota table that explains everything
| Model class | Pay-as-you-go default | Enterprise / MCA-E |
|---|---|---|
| Opus family, Sonnet 5 | 40 RPM / 40,000 ITPM | 2,000 RPM / 2,000,000 ITPM |
| Sonnet 4.6/4.5, Haiku 4.5 | 80 RPM / 80,000 ITPM | 4,000 RPM / 4,000,000 ITPM |
| Claude Fable 5 | 0 RPM / 0 ITPM | 2,000 RPM / 2,000,000 ITPM |
| Any model, Free Trial | 0 across the board | |
ITPM here counts uncached input tokens plus 5-minute and 1-hour cache-write tokens; output tokens and cache reads don't count. The pattern in the table is the message: Microsoft gates its most capable Claude model behind enterprise agreements. To run Fable 5 on Foundry you effectively need two things — an Enterprise agreement or Microsoft Customer Agreement for enterprises (MCA-E) on the subscription, and in practice a quota path via Microsoft's quota increase request form (published at aka.ms/oai/stuquotarequest) for anything beyond defaults. A standard pay-as-you-go card-on-file subscription cannot send Fable 5 traffic no matter how it's configured.
Compounding factors worth knowing before you plan a rollout
First, hosting: on Foundry, Fable 5 is available on Hosted-on-Anthropic-infrastructure deployments (listed by Microsoft as Preview), while the Hosted-on-Azure GA lineup is Opus 4.8, Sonnet 5, and Haiku 4.5. Second, quota is managed at the subscription level and shared: all Global Standard deployments of the same model and version in a subscription draw from one pool across regions, so spinning up a second Fable 5 deployment doesn't create new capacity. Third, Fable 5 carries Anthropic-side constraints that follow it onto every platform — it requires at least 30 days of data retention (it is not eligible for Zero Data Retention), and it accepts only adaptive thinking. None of these block you the way a zero quota does, but they belong in the same planning conversation.
Diagnosing it in the wild
The symptom is every Fable 5 request being throttled — and on Foundry, diagnosis is harder than on the first-party API because Foundry does not return Anthropic's standard anthropic-ratelimit-* response headers. There is no "remaining: 0" header to read; Anthropic's guidance for Foundry is to manage rate limiting through Azure's monitoring tools and exponential backoff. So the confirmation path is administrative: check the subscription's quota allocation for the deployment in the Azure/Foundry portal rather than inferring from response headers. If Opus 4.8 works from the same deployment pipeline and Fable 5 returns nothing but throttles, the zero default is almost certainly what you're seeing.
Interim architectures
Teams that need Fable 5-class capability before the agreement lands typically do one of two things. Some run Opus 4.8 on Foundry now (40 RPM / 40,000 ITPM default is enough for pilots) and swap the model ID later — remembering that Fable 5 rejects explicit temperature settings and manual thinking budgets, so build against adaptive-thinking conventions from day one. Others source Fable 5 from a different platform where their commercial setup already qualifies, keeping Foundry for the rest of the portfolio. Both are reasonable; what isn't reasonable is assuming the quota will be nonzero on launch day without having checked.
Where to go next
See Foundry quota types for how RPM and ITPM are measured, requesting a Foundry quota increase for the process, and rate-limit handling on Foundry for building the backoff logic that replaces the missing headers.