Observability, Usage & Analytics

Rate-Limit Visibility on Foundry Without anthropic-ratelimit-* Headers

On the direct Claude API, every response tells you how much rate-limit headroom you have left. On Microsoft Foundry, it doesn't. Here is what to use instead.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Well-built clients for the first-party Claude API often do something clever: they read the anthropic-ratelimit-* response headers and pace themselves — slowing down as remaining token budget shrinks, rather than blindly sending requests until a 429 arrives. If you port such a client to Claude on Microsoft Foundry, that logic silently goes blind, because Foundry does not return these headers at all. This is documented, deliberate, and it changes how you should design throttling on Azure.

What's missing, exactly

The direct Claude API returns a family of rate-limit headers on every response: anthropic-ratelimit-requests-* plus nine token-limit variants — anthropic-ratelimit-tokens-*, anthropic-ratelimit-input-tokens-*, and anthropic-ratelimit-output-tokens-*, each in -limit, -remaining, and -reset forms — along with retry-after on 429s (see rate-limit headers explained). Anthropic's Foundry documentation is explicit that Foundry does not include these standard rate-limit headers in responses, and tells you to manage rate limiting through Azure's monitoring tools instead.

Why the difference? Rate limiting on Foundry is Azure's job, not Anthropic's. Quota lives at the Azure subscription level, measured in requests per minute (RPM) and uncached input tokens per minute (ITPM), shared across deployments of the same model and version. The enforcement point is Azure's infrastructure, so Anthropic's header mechanism — which reports on Anthropic's own token buckets — has nothing meaningful to report. Note that Bedrock and Vertex do not document these headers either; this header family is a first-party API feature, so treat its absence as the 3P norm, with Foundry simply being the platform where Anthropic documents the omission explicitly.

The signals you get instead

SignalWhereWhat it tells you
HTTP 429 responsesYour applicationYou have exceeded RPM or ITPM — the definitive, if late, signal
ProvisionedUtilization metricAzure MonitorUtilization of provisioned capacity; crossing 100% means requests get throttled with 429s (documented for provisioned/PTU deployment types)
InputTokens, OutputTokens, ModelRequestsAzure MonitorActual consumption to compare against your known RPM/ITPM quota
Quota pageAzure portalYour configured limits per model, and the path to request increases

One caveat on ProvisionedUtilization: Microsoft's monitoring page documents it against provisioned (PTU) deployment types, while Claude on Foundry uses Global Standard and Data Zone Standard deployments — so verify which metrics your deployment type actually emits rather than assuming. The token and request count metrics (InputTokens, OutputTokens, TotalTokens, ModelRequests) are documented for standard deployments as well, and slicing ModelRequests by the StatusCode dimension gives you a 429 counter you can alert on — the closest Foundry equivalent to watching -remaining headers trend toward zero.

Back-off without a token budget readout

Without -remaining and -reset headers, you cannot compute "sleep exactly until the bucket refills." The documented approach is simpler: exponential back-off on 429s, plus quota increases through the Azure portal or support when you are persistently capacity-bound.

import time, random
from anthropic import AnthropicFoundry, RateLimitError

client = AnthropicFoundry(api_key="...", resource="example-resource")

def create_with_backoff(**kwargs):
    for attempt in range(6):
        try:
            return client.messages.create(**kwargs)
        except RateLimitError:
            time.sleep(min(60, 2 ** attempt) + random.random())
    raise RuntimeError("still throttled after retries")

Three design notes for the header-less world. First, pace by what you can count locally: you know your quota (say, 40 RPM / 40,000 ITPM on pay-as-you-go for Opus-family models) and you know your own request sizes, so a client-side token bucket approximating ITPM consumption prevents most 429s before they happen — remember ITPM counts uncached input and cache-write tokens, not output tokens or cache reads. Second, watch trends in Azure Monitor, not per-response state: an alert on rising 429 counts or token throughput approaching quota replaces the header-based early warning. Third, jitter your retries — synchronized clients retrying in lockstep after a throttling event re-create the spike that caused it.

Migration check: grep your codebase for anthropic-ratelimit before moving a workload to Foundry. Any logic reading those headers needs replacing with 429 handling plus Azure Monitor alerting — it will not error on Foundry, it will just never fire.

Where to go next

See Foundry rate-limit handling for the broader throttling playbook, Foundry quota increases for raising limits, and Azure Monitor for Claude for the metrics pipeline this article leans on.

Sources