Most Azure services bill through a forest of meters — one per SKU, tier, and region. Claude in Microsoft Foundry went the other way. Microsoft's billing documentation describes a single billing dimension: the Claude Consumption Unit, or CCU, which replaced the previous per-model token meters. Every Claude token your deployments consume is converted into CCUs and lands in Azure Cost Management as one meter through Azure Marketplace. That simplicity is great for procurement and initially frustrating for FinOps — until you know where the per-model detail actually lives.
How the CCU meter works
The CCU has a fixed USD price published on the Claude offer on Azure Marketplace. Token usage is converted to CCUs using Anthropic's published per-model token rates (Microsoft's docs link to Anthropic's pricing rather than publishing dollar rates of their own), after any contractual discounts are applied. Anthropic's pricing page states the unit economics plainly: CCUs are billed at $0.01 per CCU, so 100 CCU equals $1.00 of fees at standard per-model rates after discounts.
Mechanically: the meter accrues hourly and is invoiced monthly in arrears, pay-as-you-go. There are no prepaid CCU credits or balances to manage. Negotiated discounts arrive as Azure Marketplace private offers, applied at the token-to-CCU conversion step, and can carry different rates per model — so two organizations with identical token usage can see different CCU counts. One nuance for older estates: deployments created before CCU became generally available continue on their previous per-model plan; new deployments bill in CCU automatically. During a transition you may see both shapes on one invoice.
Cost analysis views: one line, then drill down
In Azure Cost Management's cost analysis, Claude appears as a single CCU line — a Marketplace charge scoped to the subscription and resource group containing your Foundry resource. That gives you resource-level attribution for free at the granularity of Foundry resources: if each team or product has its own Foundry resource (or its own resource group or subscription), Azure's standard grouping by resource, resource group, and subscription splits Claude spend without any extra machinery. Deployments live inside a resource, so spend from multiple deployments on one resource is aggregated at the CCU line; structure resources along the boundaries you want to report on.
For per-model and per-request detail, Microsoft points you out of Cost Management entirely: token and request breakdowns by model live in the Foundry portal's Monitoring tab. The practical workflow is Cost Management for dollars and trend, the Monitoring tab for the token-level "why," and — if you need request-level attribution — your own application logs capturing the usage object from each API response, which Foundry returns in the standard Claude API format (see logging token counts for internal FinOps).
Budgets and alerts
Because CCU charges flow through Azure Cost Management like other Marketplace consumption, Azure's native budgeting and alerting features can be scoped to the subscriptions and resource groups that hold your Foundry resources — set a monthly budget matching your forecast and alert thresholds below it. The mechanics are standard Azure Cost Management functionality rather than anything Claude-specific, so follow Microsoft's current documentation for exact configuration. Two Claude-specific realities to design around: metering is hourly and invoicing is monthly in arrears, so alerts trail usage rather than gating it; and there is no hard spend cap on the Anthropic side of this surface — throttling comes from rate limits (RPM and uncached input tokens per minute), which bound burn rate but are a capacity control, not a budget control.
What to verify before your first invoice
Three checks save a support ticket later. First, confirm which billing plan each deployment is on (CCU vs. a legacy per-model plan) if your resource predates CCU general availability. Second, if you negotiated a private offer, confirm the discounted conversion is active before scaling traffic — discounts apply from acceptance, and the conversion step is where they take effect. Third, run a small controlled workload and reconcile: tokens from the Monitoring tab, converted at Anthropic's published per-model rates, should explain the CCU quantity on the invoice. The general methodology is in reconciling cloud invoices against internal token logs.
Where to go next
Compare with AWS billing for Bedrock and Claude Platform on AWS billing — the latter also uses CCUs. For the Foundry platform itself, start at the platform overview.