Repository navigation
PRU Quota Wiped Out, very likely related to enabling Assisted Permissions #4802
Description
Describe the bug
I believe the issue is very likely related to enabling assisted permissions, since there were no problems before it was turned on.
- Subscription: Copilot Pro (Annual Plan / Legacy Request-based PRU).
- August 11 Incident: With 234 PRUs remaining in my allowance, I sent 1 single prompt, and my remaining quota was instantly wiped out to 0.
- September 2 Incident (Today): My quota reset today for the new billing cycle. I sent 1 single prompt in a brand-new session, and my entire September PRU allowance was instantly wiped out to 0 again.
- Historical Context: Prior to August 11, I had used this annual plan for over 16 months without any issue. This is a newly introduced recurring bug, not a normal usage behavior.
The request consumption shown in Copilot CLI is correct, but the actual backend consumption is wrong.
Affected version
No response
Steps to reproduce the behavior
- Legacy Request-based PRU Account
- Switch to Assisted Permissions
- Send Prompt
Since a single prompt wiped out my entire monthly quota, I’m unable to repeat the test.
Expected behavior
No response
Additional context
Github Support Ticket #4720186
Activity
aw75479 commentedon Oct 8, 2026
I’m seeing what looks like the same issue on a legacy annual Copilot Pro+ plan, but in VS Code Copilot Chat rather than Copilot CLI.
Environment at the time:
A long agent session consumed the entire remaining monthly PRU quota.
This also looks related to:
#4161 is especially interesting because autonomous
isAutopilotContinuationevents were counted as additional premium requests there and the issue was later fixed in Copilot CLI.My incident happened in VS Code Copilot Chat 0.68.0, so it may be worth checking whether the corresponding fix was also present in the VS Code implementation.
cason-wu commentedon Oct 8, 2026
Hi aw75479,
When the VS Code Session Target is set to
Copilotinstead ofLocal, it is still using the Copilot CLI Agent under the hood.After the quota reset in October, I disabled Assisted Permissions and have not experienced any further quota wipe-out issues.
Based on my observations, the frontend usage metrics reported by Copilot CLI are accurate. the root cause appears to be that prompts generated by Assisted Permissions are not properly excluded as non-user prompts in the backend metering system. As a result, they are incorrectly counted against user usage. I am not sure whether the root cause is that these agent-generated prompts are not being properly labeled as system-generated prompts.
Besides Assisted Permissions, I have also observed that other agent-generated prompts do not appear to be excluded from metering either. This includes prompts automatically generated by UI-triggered actions. Consequently, a significant discrepancy arises between the PRU reported by
/usageand the PRU calculated by the backend.aw75479 commentedon Oct 8, 2026
Thanks, that helps. I checked the VS Code side as well.
For the affected setup (VS Code 1.140.0 / Copilot Chat 0.68.0), the bundled
@github/copilotruntime is 1.0.73. VS Code 1.141.0 / Copilot Chat 0.69.0 still appears to bundle the same 1.0.73 runtime.That is interesting because #4161 was still reproducible in Copilot CLI 1.0.74-1 and was only reported fixed in 1.0.76.
So at least for the Copilot session target, VS Code may still be running a runtime version older than that fix. This seems consistent with your observation that the issue is in the backend/runtime metering path rather than just the VS Code UI.
Maybe if someone bumps up the bundled version at least the Assisted Permission is fixed, so not everyone runs into this trap. But it seems that there are more metering issues hidden in copilot cli.
samvallad33 commentedon Oct 22, 2026
Hi cason-wu,
Since you turned Assisted Permissions off after the October reset, has your PRU count stayed in line with what /usage shows?
Two whole allowances gone on a single prompt each, with /usage looking correct the entire time, sounds maddening to chase down. A while back something similar caught me, and afterward what I wanted most was a plain log showing which step, or which hidden agent-generated prompt, actually burned the requests. If you had a per-step record like that for the August and September prompts, do you think your support ticket would have moved any faster?
Sam
cason-wu commentedon Oct 24, 2026
Hi samvallad33,
Even after disabling Assisted Permissions, the total PRU shown by /usage still did not match the Session PRU. Some none user messages was continuing to consume my PRU. I suspected the cause might have been the proactive Git diff prompts that appeared, but I canceled my annual PRU subscription before I was able to confirm it.
After running into these issues, and with models being retired one after another, I noticed that newer versions of the CLI no longer display Session PRU usage at all. This gives me the impression that the development team is no longer taking customers on the legacy PRU-based plans into consideration.
Fortunately, the Support Team eventually opened an issue and began a formal investigation into the problem. Before that, I encountered several support representatives who appeared to respond with canned messages without even reading the details of the issue. Some seemed more interested in closing the case than understanding the problem, and would make claims that were clearly inconsistent with the evidence.
I was lucky that my case eventually reached a Support Team member who took the issue seriously and investigated it properly. In my experience, they only start asking for logs and other diagnostic information once they decide to open an issue for formal investigation. Before that point, even if you provide logs and supporting data, nobody seems to actually analyze them.
aw75479 commentedon Oct 24, 2026
Face it, Github/Microsoft is not interested in fixing any bugs, that saves them money... No answer to any support request. Somehow by now i have the suspicion that the "bug" wasn't introduced by accident.... and that they do not answer isn't an accident either...I wonder if this could be called fraud.
i created a support ticket more than 2 Week ago... zero reaction, multiple tried to get an reaction, no ways of escalation... no movement at all.
samvallad33 commentedon Oct 26, 2026
Hi cason-wu,
Thanks for the full picture. Glad your case finally reached someone who read the evidence and opened a formal investigation. That's the hard part with these tickets.
Your point about newer CLI versions dropping Session PRU stands out. Without a per-session number, nobody can line backend charges up against what they actually sent, which is how you spotted the non-user prompts in the first place.
That gap is what I work on: a record that walks a charge back to the step that caused it, like a proactive Git diff prompt, instead of just a total. I hope the investigation confirms your theory.
Sam
davidwkj commentedon Oct 29, 2026
+1 — Confirming this exact same catastrophic bug on a Copilot Pro+ Annual Plan ($390/year)!
Notice that both #4802 (Ticket #4720186) and my case (Ticket #4838700) are on Annual Plans with "Assisted permissions" enabled. There is clearly a critical backend billing/metering bug when Assisted Permissions evaluates tool risks on annual accounts.
Could a GitHub staff member or maintainer please urgently escalate Support Ticket #4838700 and #4720186 to the Copilot Billing & Engineering team?
cason-wu commentedon Nov 11, 2026
I finally received a reply from the Support Team. They've acknowledged that the quota wipeout was caused by a bug on their side, but they still refuse to compensate me or issue a refund. Unfortunately, despite admitting responsibility, they don't seem willing to make affected users whole.
cason-wu commentedon Nov 13, 2026
After communication, I was finally able to secure a refund.
If anyone else encounters the same issue, I recommend reaching out to customer support and asking them to refer to my resolved support ticket, #4720186, as a reference for your case.
aw75479 commentedon Nov 13, 2026
My ticket 5 Weeks ago #4834170 was still not even touched. No reply, not even acknowledgement that someone is working on it, I see no way of escalation...