GitHub Copilot: check model access before changing plans
GitHub Copilot model access depends on the plan, product surface, and current availability matrix.
Check the model and workflow you need before upgrading a subscription or moving a team to another client. A model’s presence in a rate card does not establish that your plan enables it, and a dated release announcement is not a permanent availability guarantee.
The current supported-model guide says availability depends on the Copilot plan and where it is used, including GitHub.com and IDEs. It also says model availability can change. For a procurement decision, those are more useful constraints than assuming that an April announcement still describes every October entitlement.
What the April change actually said
GitHub’s April 20, 2026 individual-plan announcement paused new signups for Student, Pro and Pro+, while leaving Copilot Free open and permitting existing users to upgrade between plans. It also said Opus models were removed from Pro, with Opus 4.7 remaining on Pro+ at that time.
The same announcement described tighter limits and a refund option with a May 20 deadline. Those details belong to that historical change. They should not become present-day signup instructions, a current refund offer or a statement that a named model remains indefinitely available under the same plan.
If you are investigating why a workflow stopped working, record when the failure began, the client, the selected model, the account’s plan and any organization policy. Compare that configuration with the current matrix. A historic removal is a plausible lead for a historical incident, but it does not diagnose a different account or a newer model-selection failure by itself.
For the older commercial context, GitHub Copilot’s Opus pricing history concerns past request-based pricing. It should not be used as the current tariff for a token-metered account.
Identify the billing route before estimating usage
The current models and pricing documentation meters input, output and cached tokens by model and converts the cost to AI credits. It says one AI credit represents $0.01 USD. Included allowances and their scope vary by plan; organizational plans can pool their users’ allowances at the billing-entity level.
The legacy request documentation now explicitly applies to existing annual Pro and Pro+ subscribers who remained on premium-request billing after June 1, 2026. Its rules cannot be applied wholesale to an account using token-metered credits.
That creates two separate checks: which model the account can use, and how its use is billed. An account can have access but insufficient allowance or a restrictive budget. Conversely, a price listed for a model does not establish access to that model in every product surface.
Use the actual account’s usage and billing records to distinguish access restrictions, exhausted allowance, rate limits and client configuration problems. An error message is more useful when it is retained with the exact model selection and account route. Do not automatically buy a higher plan to resolve a failure whose cause has not been identified.
Compare migration paths with an explicit workload
| Path | What to verify before committing | Cost or operational question |
|---|---|---|
| Keep the current Copilot plan | Whether an allowed model can complete the required task on the needed surface | Does the alternative require more attempts or review? |
| Change the Copilot plan | Current entitlement, allowance and organization controls | Is the extra recurring and usage cost justified by accepted work? |
| Use another coding client | Model route, data handling, tools and repository integration | How much workflow and security setup must change? |
| Use a directly metered API | Exact model ID, current rates, client implementation and applicable terms | Who owns metering, credentials and operational support? |
This is a proposed migration checklist, not a measured performance comparison or a guarantee that a particular plan solves an incident. Use the same repository revision and acceptance criteria when testing the paths. Include failed attempts and human repair in the comparison.
Direct API access is a separate purchasing route. The Claude Platform rate card documents model-specific input, output, caching and feature charges. Verify the supported model ID and current commercial terms rather than assume a subscription includes every API model or that historic availability continues. A direct API route requires its own client configuration, credentials and billing controls; it does not inherit a Copilot plan’s entitlements.
An API migration also does not by itself settle data retention, region or access requirements. Review the selected provider and deployment configuration before sending repository data. Verify the provider’s current availability and access terms.
Preserve the useful parts of an existing workflow
If an alternative model is available within the current setup, first test whether it meets the acceptance rule for the tasks that actually changed. A different model can alter context use, output length and failure behavior, so keep the pilot’s checks and reviewer decisions with the result. This is a way to limit migration scope, not a prediction that the substitute will perform equally well.
If the required capability is unavailable, separate the urgent workaround from the durable platform choice. A bounded task can be moved temporarily while the team verifies a long-term plan, data path and integration. The cost of switching includes human review and configuration work as well as model charges.
Groundy’s GitHub Copilot vs Cursor vs Claude Code: workflow comparison covers the broader selection decision. For the immediate incident, finish with an account-specific answer: the required model and surface, the applicable billing route, the documented restriction, and the smallest tested change that restores acceptable work.
Join the discussion
Share a useful perspective or ask a question about this article.