GitHub Copilot Pro+: New Usage Limits and Opus 4.6 Fast Retirement
GitHub CopilotGitHub has enforced new usage limits for Copilot Pro+ subscribers and permanently retired Opus 4.6 Fast from the plan, citing infrastructure strain caused by high-concurrency, intensive usage patterns. Two types of limits are now active: service reliability limits (requiring a session reset when exceeded) and model-specific capacity limits (allowing users to switch models or fall back to Auto mode). These changes affect all Copilot Pro+ subscribers and are intended to preserve service quality across the platform.
Key Takeaways
- Two distinct limit types now apply to Copilot Pro+: service reliability limits (requiring a session reset) and model-specific capacity limits (prompting a model switch or Auto mode fallback).
- Opus 4.6 Fast has been permanently retired from the Copilot Pro+ plan due to its outsized contribution to infrastructure strain from high-concurrency usage.
- Service reliability limits are not permanent — once the session is reset, access to Copilot is restored, making them a temporary throttle rather than a hard ban.
- Auto mode is now the recommended fallback for subscribers who frequently hit model capacity limits, as it dynamically routes to whichever capable model has available capacity.
- The changes are driven by infrastructure pressure from a subset of intensive Pro+ users whose usage patterns degraded service quality for the broader subscriber base.
- These limits will evolve over time as GitHub tunes capacity, meaning thresholds and affected models may change as the platform scales its infrastructure.
Sources & Mentions
5 external resources covering this update
What Changed
GitHub has introduced two new categories of usage limits for Copilot Pro+ subscribers, alongside the permanent retirement of the Opus 4.6 Fast model from the plan. These changes take effect immediately and apply to all Pro+ accounts.
Two Types of Usage Limits
Service Reliability Limits
The first category is service reliability limits. When a subscriber's usage reaches this threshold, Copilot will display a notification and require a session reset before the user can continue. These limits are designed to protect the overall health of the service infrastructure during peak load periods. They are not permanent bans — resetting the session restores access.
Model-Specific Capacity Limits
The second category is model-specific capacity limits. These apply on a per-model basis when a particular model is under heavy demand. When this limit is hit, GitHub Copilot will prompt the user to either switch to a different model or fall back to Auto mode, which automatically selects an available model with capacity. This mechanism allows GitHub to dynamically balance load across its model fleet without fully cutting off access.
Opus 4.6 Fast Retirement
In addition to the new limits, GitHub has permanently retired Opus 4.6 Fast from the Copilot Pro+ plan. The retirement was triggered by the model's disproportionate contribution to infrastructure strain — its combination of speed and capability made it a target for high-concurrency usage patterns that degraded reliability for other users on the platform.
Subscribers who relied on Opus 4.6 Fast for latency-sensitive workflows will need to migrate to alternative models available within Pro+. GitHub's Auto mode can serve as a fallback, routing requests to whichever capable model currently has available capacity.
Why GitHub Is Making These Changes
GitHub has attributed these changes to sustained infrastructure pressure caused by a subset of Pro+ users running intensive, high-volume workloads. The platform was not architected for the usage patterns that emerged at scale, and these guardrails are intended to ensure consistent quality of service for all subscribers rather than allowing a small number of intensive users to degrade the experience for the majority.
Recommendations for Pro+ Subscribers
Copilot Pro+ subscribers who regularly hit model capacity limits are encouraged to:
- Enable Auto mode to let GitHub route requests to available models automatically
- Diversify across multiple models rather than relying exclusively on one
- Monitor GitHub's status and community channels for updates on model availability
- Expect the limits to evolve as GitHub tunes infrastructure capacity over time