Agent Credit Limits and Alerts - Copilot Studio

The agent limit and the capacity used by its flows need to be checked separately. Microsoft documents that an agent's monthly limit does not stop the agent flows it calls, and that the limit is not enforced instantly.

For this incident, I would first separate agent interactions from Agent flow actions in the consumption report. Then check the configured limit, Stop usage setting, notification time and last successful invocation in a controlled test. Billing timestamps and execution timestamps should remain distinct: a delayed accounting update does not mean that execution continued until that moment.

This should help identify whether the spike came from delayed reporting, delayed enforcement or flows governed by a different capacity boundary. The dashboard refresh cadence alone cannot establish the alert-delivery interval.

Microsoft documentation: https://learn.microsoft.com/en-us/power-platform/admin/manage-copilot-studio-copilot-credits-capacity

Hello MB12345​ , here is what I'd recommend to set tight controls. Of course with time, some of these settings can evolve/change and we'd have to adapt.

Approach

• Set limits at environment level
• Set limits to specific agents (if needed)

1 - Set credit limits to "Production" environments

• Depending on your environment strategy, set X number of credits in the environment capacity. For e.g. if you have Production environments where you know Y number of agents are deployed, based on the estimates, allocate the number of credits.
• Make sure that "Draw from the available capacity in my tenant" is unchecked - this way, you can control that agent(s) don't consume beyond the X number of credits assigned to the environment

2 - Set credit limits to "Developer" environments

• If you don't want Developer environments to use usage based billing elements like GitHub Copilot harness, make sure that you don't assign any credits to these environments & also turn off "Draw from the available capacity in my tenant".
• If you want some Developer environments to use usage based billing elements like GitHub Copilot harness, then assign credits to the selected environments accordingly. I'll still recommend keeping "Draw from the available capacity in my tenant" as off here too
  • For this case, I'd additionally recommend checking which agents are using GitHub Copilot harness so you can check with the Makers if this was an intentional choice or an accidental one. Here you can guide your Makers to choose the right harness to build agents. I've seen multiple instances where Makers chose the GitHub Copilot harness because that was the most obvious button on the screen & they didn't have a legitimate use case for this. All they wanted was to build basic agents.

3 - Set credit limits and notification at Agent level

• With (1) and (2), you are sort of already covered. But if you have a case where there are multiple agents running in the same Production environment, you might want to set limits at the "Agent" level so you don't let one Agent use up all credits. This really depends on what agents are live and what they are doing.
• Also, set "overage notification" so you will get notified when the agent is nearing capacity usage. Setting it to 80% is a good number

I build Vaze. One addition to Jamony's answer: check the environment's access to shared capacity, not only the individual agent's limit.

Microsoft's current guidance for agents using the GitHub Copilot harness says that per-agent limits don't cap aggregate environment consumption. For a prepaid boundary it describes allocating a defined amount, turning off 'Draw from the available capacity in my tenant', and not connecting that environment to pay-as-you-go.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/govern-credit-consumption

That changes the review question from 'did this agent stop?' to 'can this environment keep consuming through other agents or the tenant pool?' Before changing allocation or billing settings, check every workload in that environment, because those settings affect more than the agent being investigated.

I'd include the environment's funding mode and a named cost owner in the incident review, alongside the agent limit and stop setting.

You need protection against rapid credit spikes and want to know whether limits act immediately. Microsoft documents monthly per-agent limits, approaching-limit notifications, and an optional hard stop. The agent is automatically turned off at the configured limit only when Stop usage is enabled; otherwise the limit status is monitoring, not enforcement.

Final consumption data is processed through the billing pipeline and can take several hours to appear. Microsoft publishes no evaluation interval or alert-delivery SLA, so neither is guaranteed real time.

For production, set a conservative limit below the true budget, enable Stop usage, assign a named admin owner, and review environment allocation and pay-as-you-go settings. Monitor estimated usage during testing, restrict high-frequency triggers and expensive actions, and keep a documented kill switch for disabling the agent. Validate the policy with a controlled non-production agent before relying on it for a high-volume workload.