The Claude models behave the same on every platform, but the question "how close am I to my rate limit right now?" has four different answers depending on where you run. The Claude API tells you in response headers on every call. Amazon Bedrock tells you in CloudWatch. Google Vertex AI tells you in Cloud Monitoring. Microsoft Foundry tells you in Azure Monitor — and explicitly does not return Anthropic's rate-limit headers. This article maps the signals so you can build the right dashboard for your platform.
Claude API: read the headers
On Anthropic's first-party API, every response carries rate-limit headers of the form anthropic-ratelimit-{requests,tokens,input-tokens,output-tokens}-{limit,remaining,reset}. The remaining values tell you how much headroom the token bucket has right now (token counts rounded to the nearest thousand), and reset is an RFC 3339 timestamp. Usefully, the anthropic-ratelimit-tokens-* headers reflect the most restrictive limit currently in effect — if a workspace-level limit binds before the organization limit, that is what you see. When you do hit a limit, the 429 response names which limit was exceeded and includes a retry-after header in seconds.
For trend analysis rather than per-request signals, the Claude Console's Usage page shows rate-limited (blocked) request counts and hourly maximum uncached input tokens per minute against your configured limits, and the Usage and Cost Admin API lets you poll usage programmatically (data typically appears within about 5 minutes; sustained polling is supported at once per minute). See the Usage API's dimensions and filters for what you can group by.
Amazon Bedrock: CloudWatch, in two namespaces
Bedrock publishes runtime metrics to CloudWatch. On the legacy bedrock-runtime surface, the AWS/Bedrock namespace carries Invocations, InputTokenCount, OutputTokenCount, and — the key throttling signal — InvocationThrottles. Two subtleties matter for quota work. First, CacheReadInputTokens are documented as not counting toward your TPM quota, so raw token counts overstate quota burn on cache-heavy workloads. Second, the EstimatedTPMQuotaUsage metric approximates consumption but does not reflect the reservation-based accounting that actually drives throttling — AWS says not to use it as your sole capacity-planning signal (more on that caveat here).
The current "Claude in Amazon Bedrock" surface (the bedrock-mantle endpoint) publishes to a separate namespace, AWS/BedrockMantle, with Inferences, TotalInputTokens, TotalOutputTokens, and per-inference token distributions. Dashboards and alarms built on AWS/Bedrock will silently miss mantle traffic — if you use both surfaces, monitor both namespaces. The two endpoints also have independent quota allocations for the same model.
Google Vertex AI: quota is itself a metric
On Vertex AI, Claude quota consumption is metric-based: lineage quota metrics such as global_online_prediction_requests_per_base_model and global_online_prediction_input_tokens_per_minute_per_base_model (with base_model dimensions like anthropic-claude-opus) are viewable on the console's Quotas & System Limits page. One documented caveat: because of Anthropic's token estimation and refund system, the token usage shown on the console Quota page may be inaccurate — Google directs you to token_count metrics in Metrics Explorer or the token counting API for accurate figures (details here).
For service health alongside quota, the prebuilt model observability dashboard covers managed partner models including Claude, showing requests per second, token throughput, first-token latencies, and API error rates. Alerting uses standard Cloud Monitoring policies — Google's own example alerts when more than 1% of requests return 429, a direct capacity-exhaustion signal.
Microsoft Foundry: Azure Monitor, no Anthropic headers
Anthropic documents explicitly that Foundry does not return the anthropic-ratelimit-* headers; the guidance is to manage rate limiting through Azure's monitoring tools and exponential backoff on 429s. Azure Monitor collects Foundry deployment metrics automatically — ModelRequests, ModelAvailabilityRate, and the usage metrics InputTokens, OutputTokens, and TotalTokens — sliceable by dimensions such as ModelDeploymentName and StatusCode, which is how you count 429s per deployment. Viewing metrics requires the Monitoring Reader role. For spend rather than tokens, Azure Cost Management shows per-deployment consumption with roughly a five-hour delay from the billing event. More in rate-limit visibility on Foundry.
Claude Platform on AWS: Console pages, not APIs
Claude Platform on AWS uses Anthropic-managed rate limits (organizations stay on the Start tier until you ask Anthropic for more), but the programmatic Usage and Cost API endpoints are not available there — you monitor consumption on the Usage and Cost pages in the Claude Console instead.
| Platform | Real-time signal | Trend tooling |
|---|---|---|
| Claude API | anthropic-ratelimit-* headers, 429 + retry-after | Console Usage page; Usage & Cost Admin API |
| Amazon Bedrock | 429s / throttle metrics | CloudWatch AWS/Bedrock and AWS/BedrockMantle |
| Vertex AI | 429s; quota metrics | Quotas & System Limits page; Metrics Explorer; observability dashboard |
| Microsoft Foundry | 429s (no Anthropic headers) | Azure Monitor metrics; Cost Management |
| Claude Platform on AWS | Anthropic-managed limits | Claude Console Usage/Cost pages (no Usage/Cost API) |
Where to go next
For what the limits themselves look like on each platform, start with Quotas and Rate Limits: How Each Platform Meters Claude, then Capacity Planning: Throughput, Quotas, and Peak Load for turning these signals into a plan.