The first-party Claude API attaches a family of headers to every response — anthropic-ratelimit-requests-remaining, anthropic-ratelimit-input-tokens-remaining, their -limit and -reset siblings, plus retry-after on 429s — that lets a client see its remaining capacity in real time and shed or shape load before hitting the wall. Anthropic's Foundry documentation is explicit that Microsoft Foundry does not include these standard rate-limit headers in responses, and advises managing rate limiting through Azure's monitoring tools plus exponential backoff on 429s instead.
That single omission invalidates a common architectural pattern. Client-side throttles, gateway-level admission controllers, and load balancers that read the remaining-capacity headers to make routing decisions all degrade to blind operation on Foundry. The first signal you get that quota is exhausted is the 429 itself.
What replaces the headers
Azure Monitor metrics. Foundry deployments emit metrics to Azure Monitor automatically — Microsoft documents that no configuration is required, though viewing them needs the Monitoring Reader role. The useful set for quota work: ModelRequests (with a StatusCode dimension, so you can chart 429s specifically), InputTokens, OutputTokens, and TotalTokens, sliceable by ModelDeploymentName, ModelName, Region, and more. From these you can reconstruct a consumption curve against your known limits — remembering that Foundry meters uncached input tokens plus cache writes, so the raw InputTokens metric and your ITPM consumption are related but not identical, and that the limit being consumed is a subscription-wide shared pool, not per deployment.
The Foundry portal's monitoring surfaces. Each deployment has a Metrics tab in the portal (My assets → Models + endpoints → your deployment), and the resource-level Monitoring tab carries per-model token and request detail — the same place Microsoft points to for reconciling Claude's consumption-unit billing.
Diagnostic settings for history and queries. Routing the RequestResponse log category (per-inference-request logs including status codes and latency) and metrics to a Log Analytics workspace lets you run KQL over your traffic — for example, 429 counts per deployment per hour. Two caveats from Microsoft's docs: Log Analytics ingestion is billed, so collect only what you need, and data can take up to 15 minutes to appear.
Client-side usage accounting. The response body still carries the standard Anthropic usage object on every platform. Logging input_tokens + cache_creation_input_tokens per minute from your own responses gives you a real-time ITPM estimate with zero Azure plumbing — the closest substitute for the missing headers.
Designing for blind throttling
Without headroom signals, the client strategy shifts from predictive to reactive:
Treat 429 as the normal flow-control signal, not an incident. Implement exponential backoff with jitter; the official Anthropic SDKs (including AnthropicFoundry) already auto-retry 429s and 5xxs with backoff, so start by not defeating that behavior with aggressive outer retry loops that amplify load.
Build the early warning in Azure instead of in the response path: an Azure Monitor alert on the 429 rate (via ModelRequests filtered to status 429) approximates what header-watching gave you elsewhere — a signal that you're near the ceiling — just with metric latency instead of per-request freshness.
Ramp gradually and smooth bursts at your own gateway. Since you can't see the bucket, don't gamble on its depth: queue or pace spiky producers (batch jobs, backfills) rather than letting them slam the shared subscription pool that your interactive traffic depends on.
request-id (Anthropic's) and apim-request-id (Azure API Management's). Log both: Anthropic advises providing the pair to support so a problem request can be traced across both companies' systems — including throttling disputes.If you're porting code between platforms
Audit for header dependencies before migrating a Claude integration to Foundry. Code that parses anthropic-ratelimit-* should degrade gracefully when the headers are absent — and note the reverse gap too: Bedrock's and Vertex's docs don't document these headers either, so header-driven throttling is effectively a first-party-API pattern (see rate-limit headers explained). Cross-platform clients should treat the headers as an optional optimization, never a required signal.
Where to go next
See Azure Monitor for Foundry and Log Analytics for Foundry for the observability build-out, and Foundry rate-limit handling for the client-side patterns in depth.