Claude deployments on Microsoft Foundry are rate-limited on two axes: requests per minute (RPM) and input tokens per minute (ITPM). Microsoft's documentation defines the ITPM calculation precisely, and the definition is where caching-heavy workloads win or lose. ITPM counts uncached input tokens plus 5-minute and 1-hour cache-write tokens. It excludes cache-read tokens, and output tokens do not count against ITPM at all.
What the accounting means in practice
Prompt caching lets you mark a stable prefix of your prompt — a long system prompt, tool definitions, a reference document — so the platform stores it and serves it back on subsequent requests instead of reprocessing it. On Foundry, the rate-limit consequences split three ways:
| Token category | Counts toward ITPM? |
|---|---|
| Uncached input tokens | Yes |
| Cache writes (5-minute TTL) | Yes |
| Cache writes (1-hour TTL) | Yes |
| Cache reads (hits) | No |
| Output tokens | No |
So the first request that populates the cache pays for the full prefix as cache-write tokens; every request that hits the cache afterwards pays ITPM only for the uncached suffix (the user's actual question, recent conversation turns, and so on). A workload with a high cache hit rate therefore processes far more total input per minute than its nominal ITPM suggests. The first-party Claude API applies the same directional logic — cache reads excluded, writes counted — as covered in the ITPM cache-read exclusion article; Foundry's twist is spelling out that both TTL variants of cache writes count.
Sizing against Foundry's default quotas
The exclusion matters more on Foundry than elsewhere because the default pay-as-you-go quotas are small. Microsoft documents defaults of 40 RPM and 40,000 ITPM for Opus-family models and Sonnet 5, and 80 RPM / 80,000 ITPM for Sonnet 4.6, Sonnet 4.5, and Haiku 4.5 (Claude Fable 5 defaults to zero on pay-as-you-go — see the Fable 5 zero-quota article). Enterprise Agreement / MCA-E subscriptions get 2,000 RPM / 2,000,000 ITPM for Opus-family, Sonnet 5, and Fable 5, and 4,000 RPM / 4,000,000 ITPM for the Sonnet 4.6/4.5 and Haiku 4.5 group.
Run the numbers on a concrete case: a 50,000-token cached system prefix on a pay-as-you-go Sonnet 5 deployment (40,000 ITPM). The initial cache write alone exceeds a full minute of ITPM budget. Once written, though, requests that hit the cache consume ITPM only for their uncached tail — perhaps a few hundred tokens each. The failure mode to design against is cache churn: if the prefix keeps changing (timestamps in the system prompt, per-user tool sets) or expires between requests, every "hit" silently becomes another full-price write, and a workload that penciled out comfortably starts throwing 429s. Quota is also shared at the subscription level across Global Standard deployments of the same model and version, so a sibling team's traffic draws from your pool.
Monitoring it: no Anthropic headers, use Azure Monitor
One observability gap to plan around: Foundry does not return Anthropic's standard anthropic-ratelimit-* response headers, so you cannot watch remaining quota per response the way you can on the first-party API. Anthropic's guidance is to manage rate limiting through Azure's monitoring tools and exponential backoff on 429s. Azure Monitor's TokensCacheMatchRate metric reports the percentage of prompt tokens served from cache — the single best signal that your cache-hit assumptions (and therefore your effective ITPM) are holding in production. The per-request usage object in each response still breaks out cache_creation_input_tokens and cache_read_input_tokens if you want to reconstruct the accounting yourself.
Where to go next
Foundry quota types covers the broader quota model, Foundry prompt caching the caching feature itself, and the missing rate-limit headers article the monitoring workaround in depth.