On the GitHub Copilot harness, a Copilot Studio agent spends credits while you build, test and evaluate it, not only when it runs. At one organization, two brand-new agents in a Default environment crossed 400,000 credits in a single day against a 150,000-credit balance. No one had “used” them in any sense the word normally means. They were being built.
That sentence is the whole post. The rest is why it happens and where the trap is.
What happened
Two agents were created in the Default environment on Monday. Default is a production environment, so consumption is billed immediately, and it had no credit allocation of its own, which means it drew straight from the tenant’s unallocated pool with no ceiling. Everyone is a maker in Default by default. So two people building two agents, in the one environment nobody governs, pulled the entire tenant’s capacity in a day and froze every other agent in the tenant.
Nothing here was misuse. It was building.
Why the old intuition is wrong now
If you have run Copilot Studio on the standard harness, your instinct is that an agent costs nothing until you publish it. That instinct is correct for the standard harness. Billing there is licence-based and the meter starts at publish. Building and testing are free.
The GitHub Copilot harness inverts that. Microsoft’s documentation states that usage-based billing “applies to using, building, testing, and evaluating agents.” The meter starts at build. The most expensive phase of an agent’s life (the iterating, the test runs, the evaluations you run dozens of times) is now the phase that bills, and it bills before anyone outside the maker has ever touched the thing.
So the cost does not land where you are watching for it. You are watching production. It lands in development.
How the two harnesses actually bill
| GitHub Copilot harness | Standard harness | |
|---|---|---|
| Billing | Copilot credits, usage-based | Licence-based |
| Meter starts | Building | Publishing |
| Build / test / evaluate consume | Yes | No |
One more rule matters more than either row: the harness is chosen when you create the agent, and it locks. An agent built on one harness cannot be moved to the other. There is no migrate button. Choosing wrong means rebuilding from scratch.
Which interface this happens in
This is the part that turns a billing detail into an accident. The new Copilot Studio experience is the GitHub Copilot harness. The homepage Agent tile and New Agent both create a harness agent, and that is the default path the new UI puts in front of you. The standard harness is still fully supported, but you only reach it deliberately: Other ways to build, or turning the New experience toggle off.
So the harness that bills while you build is the one you land on if you click the obvious button, and the choice is irreversible after creation. The people who ran up 400,000 credits did not opt into an expensive mode. They created an agent the way the interface invited them to.
The date on the calendar
If your development happens to sit in a developer or trial environment today, note this: from 1 September 2026, developer and trial environments move to usage-based billing too. Production already bills. Standard harness agents are unchanged. After that date there is no free corner of the new harness to iterate in.
What actually fixes it
Not training people to click carefully. The fix is structural: give every environment a fixed credit allocation, and close the tenant-pool fallback so an environment stops at its own allocation instead of borrowing the tenant’s. Do that and no single environment, Default included, can ever spend the whole tenant again. It caps the blast radius regardless of who builds what, or which button they press.
We set ours to a flat allocation across every environment with the pool draw switched off. It does not stop anyone building. It stops one runaway environment taking everyone else down with it.
Two things made that practical, both open source under MIT. A PowerShell script that sets the allocation and closes the tenant-pool draw on every environment in one pass, instead of clicking through them one at a time in the admin center: Set-CopilotCreditCaps.ps1 (under tools/). And a scheduled flow that watches the tenant and flags the environments that have no cap of their own, so you hear about an uncapped environment before it burns, not after: copilot-credit-alerts. The same flow closes a second gap I wrote about earlier, that the built-in credit alerts reach an administrator but never the person who built the agent: Your Copilot Studio credit alert is going to the wrong person.
The credit crisis was not a story about careless people. It was a billing model that starts the meter one phase earlier than the last one did, reached through a button that does not say so, on a choice you cannot take back. Set the caps in time, and no single environment can do to your tenant what these two did to one organization’s.