Understand admin cost governance
Monitoring what an agent consumes doesn't stop at the agent you build. Administrators watch the same Copilot Credit consumption across the whole tenant, fund the capacity your agents draw from, and govern how that capacity is shared. In this unit, you explore how credits are funded, allocated, and monitored so you can manage usage with clarity.
How credits pool and flow to environments
Copilot Credits aren't tied to a single agent or a single maker. An organization funds a pool of credits at the tenant level, and that pool is allocated down to environments. Agents draw from their environment's share as they run, and on the GitHub Copilot harness they also draw from it while makers author, preview, and evaluate.
This pooled model is why capacity is a shared resource, not a fixed per-agent budget. The credits your agent consumes come from the same tenant pool that funds every other Copilot Studio agent in the organization. Administrators can bound a single agent when they need to, by capping how much an environment draws or setting a per-agent monthly limit, but capacity starts as a shared pool. When you reason about cost, you're reasoning about your slice of that shared pool.
Two funding models for the tenant pool
An organization fills the tenant pool through one of two funding models. Which one an organization uses shapes how administrators think about commitment and forecasting, so knowing both helps you frame your estimates in terms they recognize.
| Funding model | How it's paid | Commitment |
|---|---|---|
| Pay-as-you-go | Usage is billed to an Azure subscription after the billing month | No upfront commitment; the organization pays for what it consumes |
| Prepaid capacity | Organizations purchase Copilot Credit packs in advance and draw them down as used | Upfront commitment; capacity is bought before it's consumed |
One detail matters for planning: Microsoft 365 usage-based experiences are also metered in Copilot Credits through Copilot Studio, so your agent isn't the only draw on the capacity an organization funds. That shared currency is why capacity planning spans more than the Copilot Studio picture alone.
Two admin surfaces that govern the pool
Administrators govern the pool across two surfaces, and each one gives a different view. Understanding what each surface controls tells you which questions to ask and where an administrator finds the answer.
| Admin surface | What it governs | What to ask your admin for |
|---|---|---|
| Microsoft 365 admin center (Copilot > Cost Management) | Capacity available to Microsoft 365 usage-based experiences and the spending policies that apply to them | Whether any spending policy applies to the experiences your agent touches |
| Power Platform admin center (Licensing > Copilot Studio) | Copilot Studio capacity: consumption by agent and environment, prepaid allocation to environments, overage behavior, and per-agent monthly limits | The credit allocation for your environment, any per-agent limit on your agent, and the consumption an administrator already sees for it |
The Power Platform admin center is the surface most relevant to your work. It provides a unified capacity view across every Copilot Studio harness, including Copilot chat, standard, and GitHub Copilot. It rolls up consumption at the tenant, environment, and agent levels, and it's where an administrator allocates prepaid credits and sets per-agent monthly limits.
What happens when credits run out
When an environment has no credits or exhausts its allocation, its credit-requiring experiences stop: published agents stop responding, and makers can't author with natural language, run Preview or test, or run evaluations. Microsoft allows some overage as a grace period, so activity doesn't halt the instant a pool empties, but that grace isn't a substitute for planned capacity.
Because build-time activity on the GitHub Copilot harness consumes credits before publish, an environment that runs dry stops maker work, not just production traffic. That's why administrators govern at the environment level, not only the published agent. They often classify each environment by purpose (exploration and prototyping, test and validation, or funded production) and match the capacity posture to each. Environment-level planning protects the work you do while designing an agent as much as the agent itself.
What to bring to a capacity conversation
Because administrators plan capacity against real behavior, the most useful thing you contribute is an accurate picture of how your agent works. You already hold that picture from the earlier units.
Bring four things to the conversation:
- The workload profile: The kinds of requests the agent handles and the representative scenarios that describe them.
- Expected traffic: How often those scenarios run, so capacity reflects real volume.
- Your design choices: The model, organizational context, and tools each scenario involves — the runtime consumption drivers you control.
- Your build cadence: How much authoring, Preview, and evaluation the work involves, all of which consume credits before publish.
With those inputs, an administrator can allocate an environment's credits, set a sensible per-agent limit, and choose a funding model against representative behavior. That's the builder-admin partnership at the heart of managing agent cost: you design the agent and understand what it consumes, administrators fund and monitor the capacity, and the estimate holds because both sides work from the same picture.