Copilot update: rate limits + fixes

Update: April 20, 2026

We have provided more details about changes to Copilot Individual Plans in this discussion, which may be updated if new information becomes available.

To keep conversations all in one place and to ensure you receive timely updates and recommend you subscribe to the discussion linked above.

We'll be closing this discussion as information may be outdated.

---

Hey folks, given the large increase in Copilot users impacted by rate limits over the past several days, we wanted to provide a clear update on what happened and to acknowledge the impact and frustration this caused for many of you.

What happened

On Monday, March 16, we discovered a bug in our rate-limiting that had been undercounting tokens from newer models like Opus 4.6 and GPT-5.4. Fixing the bug restored limits to previously configured values, but due to the increased token usage intensity of these newer models, the fix mistakenly impacted many users with normal and expected usage patterns. On top of that, because these specific limits are designed for system protection, they blocked usage across all models and prevented users from continuing their work. We know this experience was extremely frustrating, and it does not reflect the Copilot experience we want to deliver.

Immediate mitigation

We increased these limits Wednesday evening PT and again Thursday morning PT for Pro+/Copilot Business/Copilot Enterprise, and Thursday afternoon PT for Pro. Our telemetry shows that limiting has returned to previous levels.

Looking forward

We’ll continue to monitor and adjust limits to minimize disruption while still protecting the integrity of our service. We want to ensure rate limits rarely impact normal users and their workflows. That said, growth and capacity are pushing us to introduce mechanisms to control demand for specific models and model families as we operate Copilot at scale across a large user-base. We’ve also started rolling out limits for specific models, with higher-tiered SKUs getting access to higher limits. When users hit these limits, they can switch to another model, use Auto (which isn't subject to these model limits), wait until the temporary limit window ends, or upgrade their plan.

We're also investing in UI improvements that give users clearer visibility into their usage as they approach these limits, so they aren't caught off guard.

We appreciate your patience and feedback this week. We’ve learned a lot and are committed to continuously making Copilot a better experience.

[DaveMBush]

What would be helpful is if there were some sort of auto restart once the limit was removed or a long running process flag that would slow things down on the client based on current overall load on the server. I don't mind the rate limiting so much as the disruption it causes.

One frustration I had this morning...

I run each story (I use the BMAD Method framework) in a subAgent in a separate worktree. When I resumed, it decided to continue its work in my main branch outside of a subAgent 😠

[Krishnamurthy-sfdx]

The recent changes in GitHub Student Copilot makes absolutely zero sense.

You give us access to the actual capable models (Claude Opus, Sonnet) through the Student Pack. We integrate it into our workflows, we start relying on it to learn and build proper architecture... and then overnight, you silently restrict access to push everyone toward the paid premium tiers.

If the goal is just to use students for an upsell funnel, you might as well completely kill your useless, nerfed Student Pack. Giving us a crippled tool that throws model_not_supported errors the second we need to do real work is just insulting.

Typical Microsoft move. Give with one hand, take with the other. Do better.

[Vedantc21]

Thanks for the transparency and detailed breakdown — really appreciated.

That said, I think the core frustration from users wasn’t just about the limits themselves, but how suddenly and broadly they were enforced. Since the fix applied system-level limits across all models, it disrupted even normal workflows, which made it feel unpredictable from a user standpoint.

A couple of thoughts that might improve the experience going forward:

Graceful degradation instead of hard blocking
Instead of cutting off access across all models, allowing fallback (even to lower-tier models automatically) could help maintain continuity.
Real-time visibility into usage
The planned UI improvements sound great — especially if they include clear token consumption tracking per model, not just overall limits.
Advance communication for impactful changes
Even a short heads-up about potential disruptions or system adjustments could help teams plan better.
Model-specific isolation of limits
If a user hits limits on a high-intensity model, restricting only that model (instead of all access) would significantly reduce friction.

Overall, it’s good to see quick mitigation and acknowledgment. Hopefully, future changes can balance system protection with a smoother user experience.

[Lorkiyn]

Still experiencing rate-limits when using 5.4 and building apps. It occurs after some time of frequent use.

[FelixDombek]

Switching agent models doesn't fully work: I just switched from Claude to GPT 5.3 for the agent run, and the agent now works, but the automatic review it starts as the last step is still rate limited and runs into 429. The agent also says it cannot control the LLM of the code-review tool. So no agent can complete its work properly.

In general, the code-review rate limit should be much more transparent, it confuses the agents trying to use it:

[ReenigneArcher]

I'm still experiencing rate limit errors as well. I am not doing anything crazy, and only using one agent at a time, no sub-agents.

Please clarify if receiving these errors still counts against the usage. Requests with errors like this should be refunded.

[DaveMBush]

I'm still experiencing rate limit errors as well. I am not doing anything crazy, and only using one agent at a time, no sub-agents.

Oddly, today seems to be better for me 🤷‍♀️

[husseinrashwan102-pixel]

I'm still experiencing rate limit errors as well. I am not doing anything crazy, and only using one agent at a time, no sub-agents.

Please clarify if receiving these errors still counts against the usage. Requests with errors like this should be refunded.

[ulrickpsp]

These rate limit changes are too drastic. I'm finding it nearly impossible to work efficiently anymore.

[MuhammadUmar1204]

I'm still experiencing rate limit errors as well. I am not doing anything crazy, and only using one agent at a time, no sub-agents.

Please clarify if receiving these errors still counts against the usage. Requests with errors like this should be refunded.

These rate limit changes are too drastic. I'm finding it nearly impossible to work efficiently anymore.

[abhsingh26071996-jpg]

Agreed

[DaveMBush]

Further frustrations...

I'm running GitHub agents and subAgents. The agent is mostly a driver to spawn the subAgents that run sequentially (i.e., I'm not attempting parallelism, or I'd have even more issues) and run within my own defined worktree. One worktree per story.

I get rate-limited in the middle of a subAgent, which shows no indication that I've been rate-limited other than that everything stops. I can't tell if that's because the AI process got confused (lost context) about where it is, or because it is rate-limited, now, it is more often because of the rate limit. Some time later, I type continue, and it picks up where it left off, but it has forgotten it is in a worktree and starts processing (or should I say reprocessing) the story in the main branch/worktree, and therefore starts the story over from scratch.

Now that I know this, I just start my process over from the top and let it know what story it is on. But you'd think "continue" would pick up where it left off.

As I said above, I don't begrudge the rate-limiting but it would be great if the client side knew how to work with it better.

Also, I'd be happy to work with you all to make this work smoother.

[abhsingh26071996-jpg]

Any idea after how much time it start working when the user is shown with rate limit error.

[miaokela]

This update has been a very poor experience. Claude is overthinking far too much, and I’m completely not used to it. The frequency control is disrupting my work and making it impossible to proceed normally.

[Silicom-11]

SOLUCIONEN ESTO

[yuan0981]

Did you resolve it?

[lwmouneyrac]

Copilot has done barely any work this morning and it is already striking... 🥐

[markandrewkato]

+1, I switched to pro+ only to get this

[lwmouneyrac]

Yes I am on pro+ too :)

[yuan0981]

Did you resolve it?

[lwmouneyrac]

no it is obviously a bug on copilot side

[lwmouneyrac]

back working for me

[DreamFulFil]

I made my 1st request to add one single unit test and got rate limited, switching models doesn't fix anything, apparently the bug is still not fixed. I'm seriously considering unsubscribing if this isn't fixed ASAP.

[MatthewFYD]

早上第一次请求就这样了！！怎么处理呢

[MatthewFYD]

每次重试也是会扣用量的！pro+

[yuan0981]

你们解决了吗？

[SidStraw]

I'm a GitHub Copilot Pro+ user

I just woke up and started my workday, and I’ve already triggered the usage limit.

I only sent two extremely small requests:

1. Debugging a single console error.
2. Fixing one failing unit test.

That’s it. Both were minor tasks.

[yuan0981]

why？

[AADI0009]

5 minutes into session and i got ratelimited? how?

[rolellscd]

codex: hello

[seanchann]

It interrupted my session. Is it possible to control the rhythm smoothly instead of abruptly interrupting the current session?

[ReenigneArcher]

Imagine rejecting requests from paying customers...

[gragra33]

I'm equally frustrated, like everyone else, even when paying for extra tokens in my budget. One would think that blocking usage would prevent income from those willing to pay extra! I am confused.

[chokevin]

It would be convenient if the actual rate-limit usage for the sessions could be shared so we can plan around the usage. It seems counter intuitive to building long running agent design

[webidextrousdev]

Yep, that's me. You're probably wondering how I ended up in this situation. Well, I was just using Copliot for the first two days after switching from Windsurf/Cascade (following their quota fiasco). Everything was humming along smoothly when I suddenly got rate-limited twice in 4 minutes. I'm not using sub-agents. I'm in and out of the code as I multitask, so it's not like I'm DDoS-ing anything. Either we need a way to set our rate intervals or you need to bump the tolerances up more. I'm totally blocked in doing my work. I have no idea how long I need to wait for this problem to go away.

[DaveMBush]

The latest version of the copilot chat plugin for vscode seems to be working worse. I have instructions to wait between calls to MCP servers or calls to the terminal that are now being ignored. I'm using version 0.42.2. When the instructions are obeyed, I avoid the rate limit. Now that they don't work, I hit the rate limit.

I do appreciate that I always get the retry prompt. But it doesn't pick up where it left off in a subAgent so retrying after the time it specifies expires almost immediately rate limits, and make no meaningful context. If I wait several hours, it is clear it is not picking up from where it left off in the subAgent and skips important steps that work otherwise.

Yesterday was an EXTREMELY frustrating day.

[gragra33]

The latest version of the copilot chat plugin for vscode seems to be working worse. I have instructions to wait between calls to MCP servers or calls to the terminal that are now being ignored. I'm using version 0.42.2. When the instructions are obeyed, I avoid the rate limit. Now that they don't work, I hit the rate limit.

I do appreciate that I always get the retry prompt. But it doesn't pick up where it left off in a subAgent so retrying after the time it specifies expires almost immediately rate limits, and make no meaningful context. If I wait several hours, it is clear it is not picking up from where it left off in the subAgent and skips important steps that work otherwise.

Yesterday was an EXTREMELY frustrating day.

Check that both VS Code & the Plugin are up to date - this has caught me out once before!

[DaveMBush]

Thanks. That helps. But I'm still seeing instructions ignored. Aside from the waits, I have instructions to run e2e tests that I no longer see running. This could be the model, but it seems correlated to these 0.42.x changes

[husseinrashwan102-pixel]

• - - [ ] @gragra33 ****

[bearaujus]

Im not sure if this is fair.

See that 3 premium requests of each retries?
To be honest, I just want to automate something & go sleep after writing a good prompt. And this is what happen when I woke-up:

---

[wawrkam]

[cp2718]

Account Downgrade (not a miscount)

This is a downgrade on accounts, plain and simple. Sorry, I don't believe anyone miscounted. What's worse is that the bot tells customers to "Please upgrade your plan" to address the limit; this is a lie. And most users aren't going through bundles of docs to see that this is in fact a lie and not consistent with the actual policy. Bottom line, users can't work because the tools don't work as a consequence of the company changing the terms.

To make things worse, it does this mid-runtime/generation, so who knows what task it stopped mid-stream. Can you track it down? Sure. Will everyone be able to? Probably not. When this happens, there is no easy way to see it coming and no way to upgrade around it. Bad form and a bug, imho.

[b14ckyy]

This really drives me mad now.
I am using Copilot for 1 1/2 months now and made some great small projects and currently started with something larger. Few days ago suddenly i started to hit rate limits with Opus 4.6 while I was totally fine paying every single request. I decided to upgrade from my Free Github Pro (heritage from a big open source project) to Pro+ to be more cost effective and benefit from a higher priority..... and now?
Not Only did I get a weekly rate limit kicked in last evening but now, just an hour after the payment for Pro+ was pulled, Claude Opus 4.6 is NOT AVAILABLE anymore and tells me to "Upgrade" to Pro???

Are you guys serious? I pay 40$ to you and you take away the most important model from my access?

This is ridiculous!

[DaveMBush]

https://github.blog/news-insights/company-news/changes-to-github-copilot-individual-plans/

Opus 4.6 is no longer available on any personal plan. I agree, saying "Upgrade" when you are already on the most expensive plan is a bit crazy.

[DaveMBush]

It appears we could all upgrade to the $20/mo enterprise plan and have what we've had in the past with the $10 plan.

Update: April 20, 2026

We have provided more details about changes to Copilot Individual Plans in this discussion, which may be updated if new information becomes available.

To keep conversations all in one place and to ensure you receive timely updates and recommend you subscribe to the discussion linked above.

We'll be closing this discussion as information may be outdated.