Claude usage in Microsoft Foundry bills through an Azure Marketplace meter — Claude Consumption Units (CCU) — that is recorded hourly and invoiced monthly in arrears, with no prepaid credits. In plain terms: usage happens first, the bill follows. Nothing in the platform stops a runaway workload at a dollar threshold. That makes Azure budgets less of a nice-to-have and more of a basic operational control for any team putting Claude traffic into production.
What an Azure budget does — and does not do
A budget in Azure Cost Management is a monitoring object, not a circuit breaker. You set an amount for a period (commonly monthly), attach it to a scope, and define alert thresholds. When accumulated or forecasted cost crosses a threshold, Azure notifies the recipients or action groups you configured. Crucially, a budget never stops the spending by itself — Claude requests keep succeeding after the alert fires. If you need a hard stop, a human or an automation you build (for example, an action-group-triggered runbook that disables keys or removes a deployment) has to act on the alert.
Choosing the scope
Budgets can be created at subscription or resource-group scope (and higher management scopes). For Claude, the right scope follows how you organized your Foundry resources:
- Resource-group budgets work well when each team or application keeps its Foundry resource in its own resource group — the budget then maps one-to-one to an owner who can act on the alert.
- Subscription budgets act as the backstop: one number that catches anything the per-team budgets miss, routed to the platform or FinOps team.
- Tag-filtered budgets let you track a project or environment that spans resource groups — this only works if your tagging strategy is applied consistently.
Because Claude charges are marketplace consumption rather than native Azure service usage, verify in your tenant that the budget's cost view includes marketplace charges for your agreement type — behavior differs across billing account types, so check the official Cost Management documentation for your setup.
Foundry-specific caveats
Expect lag. The CCU meter is emitted hourly and flows through marketplace billing; cost data in the portal trails real traffic. A budget alert tells you a threshold was crossed, not the moment it happened. For near-real-time signals, monitor request and token volume in the Foundry portal's Monitoring tab and via Azure Monitor, and translate volume into dollars using Anthropic's published per-model rates.
Rate limits are your only built-in ceiling. Foundry enforces throughput quotas per model — for example, default pay-as-you-go limits of 40 requests per minute and 40,000 uncached input tokens per minute for Opus-family and Sonnet 5 models (higher on enterprise agreements). These limits exist for capacity, not cost, but they do bound the worst-case burn rate: a workload cannot spend faster than its quota allows. Factor that ceiling into how aggressive your budget thresholds need to be, and remember that a quota increase also raises your maximum possible spend.
Discounts change the math silently. Negotiated discounts arrive as Azure Marketplace private offers applied when tokens convert to CCUs. If your organization signs one mid-year, historical budget numbers calibrated to list rates will be too high — recalibrate.
A sensible starter setup
For a first production deployment: one resource-group budget per Claude-owning team sized from a two-week traffic baseline plus headroom; alert emails to the team plus an action group that posts to their operations channel; and one subscription-level backstop budget owned by FinOps. Review monthly against Cost Analysis, and tighten as the workload's shape becomes predictable.
Where to go next
Read analyzing Foundry spending with Azure Cost Management for what the alerts are measuring, and how Azure Marketplace billing works for where these charges land on your invoice.