Microsoft is steadily moving a whole family of AI experiences over to usage-based billing, metered in a common currency called Copilot Credits. Cowork, advanced work in SharePoint and OneDrive, the Work IQ API, apps running on the Copilot Managed Runtime, Teams Phone Agent and Copilot Code all draw from the same credit pool. That is great for flexibility, because you pay for what you actually use instead of buying another per-user SKU. However, it also means your tenant now has a variable AI bill. Without a Copilot Credits spending policy in place, one enthusiastic department can quietly consume the budget for the entire organization.

The guardrail Microsoft gives you is the Copilot Credits spending policy, which you configure in the Cost Management dashboard in the Microsoft 365 admin center. In this post I will walk through how spending policies work and what actually happens when someone hits a limit. After that, I will describe a real-world case where a pilot rollout would have ended in a very awkward finance meeting without them.

What consumes Copilot Credits?

Copilot Credits are the metering unit for eligible AI experiences enabled by usage-based billing. As of late October 2026, the services managed through the Microsoft 365 admin center include:

• Cowork (Copilot license required)
• Advanced work in SharePoint and OneDrive (Copilot license required)
• Work IQ API for custom apps and agents
• Copilot Managed Runtime (building apps consumes credits in the product where you build; running apps is governed separately in the admin center)
• Teams Phone Agent
• Copilot Code (Copilot license required)

Microsoft keeps adding services to this list, which is exactly why one specific policy setting matters more than any other – more on that below.

Note the boundaries, though. You manage Copilot Chat, SharePoint agents and the Copilot Retrieval API through the separate Copilot pay-as-you-go billing policies. Meanwhile, Copilot Studio agents have their own pay-as-you-go model, which you govern in the Power Platform admin center. So depending on your agent landscape you may be managing consumption in three different places. The Cost Management dashboard covers the Copilot Credits family, and that is what spending policies apply to.

How you pay: prepaid first, then pay-as-you-go

You can fund Copilot Credits in several ways and combine them:

• Copilot Credit Pre-purchase Plan (P3) – buy credits up front
• Prepaid capacity packs
• Pay-as-you-go against a connected Azure subscription

The consumption order never changes: the system always burns prepaid credits first, whether they come from capacity packs or a pre-purchase plan. Only then does billing move to pay-as-you-go. This matters for forecasting, because your Azure invoice stays at zero until the prepaid pool is empty. Then it starts climbing. If nobody is watching the prepaid balance, the switch to pay-as-you-go is where the surprises live.

Anatomy of a Copilot Credits spending policy

Spending policies live under Microsoft 365 admin center > Copilot > Cost Management > Configuration. You activate a default spending policy during initial setup, and you can then create any number of additional policies. In short, each Copilot Credits spending policy is built from six parts:

1. Scope

A policy targets all users or specific groups. You can only target individual users and resource accounts through security groups, so plan your group design before you plan your policies.

2. Agents and services

You pick which of the supported services the scoped users can access and bill against this policy. Here sits the single most important toggle in the whole feature: Auto-apply new services, which is on by default. When Microsoft adds a newly supported service or agent, it automatically joins every policy that has the toggle on. It is the same pattern we saw with Microsoft-managed Conditional Access policies: the default is on, and the review is on you. If you want to review new AI services before your users can burn credits on them, turn this off and accept the operational duty of reviewing new services manually.

3. Limits and alerts

You set a monthly spending limit for the policy as a whole (limited or unlimited), and optionally a monthly budget limit per user so a single person cannot drain the pool. In addition, the product enforces minimums. A per-user limit must be at least 2,000 credits per month, and the in-product guidance currently recommends 7,000 or higher based on industry usage trends. The wizard also calculates a policy-level minimum from the number of eligible users in scope. When users hit their limit, they lose access to the covered agents and services for the rest of the month, and credits reset on the first of the month. On top of the limits you configure threshold alerts: email notifications to admins and stakeholders at a chosen utilization percentage. Users also get separate notifications as they approach their own cap.

4. Model profiles

Currently these exist only for Cowork. They are reusable sets of model providers and models that control which models the experience may use. You must pick at least two models. You also decide whether Microsoft may substitute a comparable model during a model-specific outage.

5. Billing method

Global and Billing administrators can override the default billing method per policy – point one policy at capacity packs and another at a different Azure subscription. This is how you do departmental chargeback: marketing’s credits land on marketing’s subscription.

6. Review and create

The policy applies to scoped users immediately on creation.

Spending policy fine print that bites

Three behaviors are worth knowing before you design your first Copilot Credits spending policy:

Users in multiple policies do not get combined settings. If several policies cover a user for the same service, exactly one wins. First, the highest per-user limit decides. After that, the largest overall policy limit breaks the tie, and finally the most recently created policy wins. A user who hits their limit stays on their assigned policy – they do not fall through to the next one.

Moving groups does not reset consumption. If a user moves between Entra ID groups mid-month and lands under a different policy, their consumption history travels with them and counts against the new policy’s limit. Nobody gets a fresh allocation by hopping departments.

Deleting a policy does not delete limits elsewhere. A deleted policy simply stops limiting its users. If another policy covers them through group membership, that policy takes over. Prior consumption still counts for the current billing period.

There is also a Cost Management API in Microsoft Graph. With it, you can read spending policies and tenant and user-level credit consumption programmatically. That is useful for feeding a FinOps dashboard, though the API reports credits, not currency.

A case: the Cowork pilot that stayed on budget

A Danish organization I worked with – around 600 users, Microsoft 365 E3 with a few hundred Copilot licenses – wanted to pilot Cowork with 40 users across IT and one business unit. Finance had one condition after reading about usage-based billing: a hard monthly ceiling, in writing, before anything was enabled.

The spending policy design

Here is the design we landed on, and it maps one-to-one to the policy anatomy above:

• Two security groups: one for the pilot users, one empty holding group documented as the way into the pilot. No direct user assignments anywhere.
• Default spending policy locked down: the default policy that activates with usage-based billing was scoped so that users outside the pilot had no credit-consuming services enabled. The pilot policy was the only road to consumption.
• Pilot policy: a Copilot Credits spending policy scoped to the pilot group, Cowork only, with Auto-apply new services turned off. The whole point of a pilot is a known scope; we did not want a newly supported service silently joining the policy mid-pilot.
• Limits: a limited monthly budget for the policy sized to the finance-approved ceiling, plus a per-user monthly limit of 3,000 credits so no single user could consume the pilot’s entire pool.
• Alerts: admin notifications at 50% and 80% of policy utilization to the IT operations mailbox and the finance controller, and user notifications at 80% of their personal cap.
• Billing method: a dedicated Azure subscription for the pilot, so the invoice line was unambiguous and finance could see the exact cost without untangling it from other Azure spend.

What the pilot taught us

Three weeks in, the alerting proved its worth. One pilot user had discovered that Cowork was rather good at churning through a backlog of document comparisons. As a result, they single-handedly reached 80% of their personal cap. They got the user notification, the admins got nothing – because the policy as a whole was only at 40%. That is the system working as designed. The per-user limit contained the enthusiasm, the policy limit protected the budget, and nobody had to play AI police.

The second lesson came from the fine print. A pilot user transferred from the business unit to IT mid-month, which moved them between Entra groups. Their consumption carried over seamlessly, with no reset and no double allocation. That is exactly what you want. However, it is also something to explain up front, so nobody expects a fresh budget after a reorganization.

The pilot finished within the approved ceiling. When the organization later expanded Cowork, they kept the same pattern: one policy per department, departmental Azure subscriptions as billing methods, and Auto-apply new services off everywhere. The only exception is a sandbox policy scoped to IT, which deliberately keeps the toggle on so IT sees new services first.

My recommendations

1. Activate usage-based billing deliberately, not reactively. Design groups and policies before users ask for the features.
2. Decide on Auto-apply new services per policy. On for an IT sandbox policy, off for everything else, and put the review of newly supported services on a recurring operations task, the same way you track Message Center changes like the SMS and voice MFA retirement.
3. Always set per-user limits. The policy-level limit protects the budget; the per-user limit protects the user experience for everyone else.
4. Alert early and alert finance. 50% and 80% thresholds, and include the people who own the money, not just the admins.
5. Use billing methods for chargeback. One Azure subscription per department turns a governance argument into a line on an invoice.
6. Watch the prepaid-to-PAYG transition. Prepaid credits burn first and silently; the pay-as-you-go phase is where unmonitored cost lives.

A Copilot Credits spending policy will not make AI cheap, but it makes the cost predictable – and predictable is what gets AI projects approved.

References

• Usage-based billing and Cost Management for Copilot Credits
• Managing AI experiences enabled by usage-based billing
• Set up usage-based billing for Copilot Credits
• Copilot Credits licensing guide