Microsoft Foundry rate-limits Claude deployments on two dimensions: requests per minute (RPM) and uncached input tokens per minute (ITPM). The word "uncached" is doing precise work. Per Microsoft's documentation, the ITPM counter includes uncached input tokens plus 5-minute and 1-hour cache-write tokens, while output tokens and cache-read tokens do not count toward it at all.
Mapping that onto the usage object every Claude response returns (Anthropic documents the object as consistent across all platforms, Foundry included):
| usage field | Counts toward Foundry ITPM? |
|---|---|
input_tokens (uncached input) | Yes |
cache_creation_input_tokens (cache writes, 5m and 1h) | Yes |
cache_read_input_tokens (cache hits) | No |
output_tokens | No |
The part that surprises Claude API veterans
On the input side, Foundry's arithmetic will feel familiar: Anthropic's own rate-limit docs describe cache-aware ITPM the same way for most models — uncached input and cache writes count, cache reads don't. The structural difference is what's missing. The first-party Claude API enforces a separate output-tokens-per-minute (OTPM) limit alongside ITPM; Foundry's documented limit set is RPM and ITPM only, with output tokens escaping token metering entirely. A workload that generates long responses from short prompts — report writers, code generators — is ITPM-cheap on Foundry, constrained mainly by RPM. The same workload on the Claude API has to budget against an OTPM pool, and on Bedrock's endpoints output tokens are metered too (a combined input+output TPM on bedrock-runtime, a dedicated output-TPM quota on bedrock-mantle). Cross-platform capacity comparisons that treat "TPM" as one interchangeable number will misestimate somewhere.
Estimating headroom, correctly
To forecast a workload against a Foundry limit, compute for each request class: uncached input tokens + cache-write tokens, multiply by requests per minute, and compare the sum across the whole Azure subscription against your ITPM allocation — remembering that all deployments of the same model version share one subscription-level pool. Then check the RPM dimension separately; with generous ITPM, chatty low-token workloads can hit the RPM wall first. Published defaults vary enormously by agreement type (Microsoft's current table ranges from 40 RPM / 40,000 ITPM on pay-as-you-go Opus-class models up to 4,000 RPM / 4,000,000 ITPM on enterprise agreements for the Sonnet 4.x/Haiku tier, with Fable 5 at zero on pay-as-you-go). These figures change; treat the Microsoft page linked below as the source of truth.
Two practical consequences of the accounting:
Prompt caching multiplies effective ITPM. Because cache reads are exempt, a workload whose prompts are mostly a shared cached prefix consumes ITPM only for the uncached remainder — the same effective-throughput lever documented on other platforms. But cache writes do count (and bill at a premium), so a workload that constantly rewrites cache entries — prefixes that change per request, TTLs that keep expiring — gets the ITPM cost without the exemption.
max_tokens is ITPM-neutral. Since output isn't metered, a generous max_tokens carries no rate-limit penalty on Foundry — unlike Bedrock's mantle endpoint, where the full value is reserved against quota upfront.
usage object from every response and derive your own ITPM series as input_tokens + cache_creation_input_tokens per minute. Foundry gives you no per-response headroom signal — it omits Anthropic's rate-limit headers — so self-computed consumption is your gauge.Watching it in Azure Monitor
Azure Monitor collects Foundry model deployment metrics automatically, including InputTokens, OutputTokens, and TotalTokens, sliceable by dimensions like ModelDeploymentName and StatusCode. Correlating a rising 429 count with your computed ITPM series tells you which dimension — tokens or requests — you're exhausting, which in turn determines whether the fix is caching, prompt slimming, or a quota increase via Microsoft's request form.
Where to go next
See Foundry rate-limit handling for the 429/backoff side, cache reads vs writes for the caching economics, and Azure Monitor for Foundry for the observability setup.