GitHub Models will stop working for every customer on July 30, 2026. The retirement covers more than the free inference endpoint: GitHub says the playground, model catalog, inference API, and bring-your-own-key endpoints will all be removed. Existing users are not exempt.
The immediate task is not to pick the most impressive replacement model. It is to find every dependency on the GitHub Models surface, decide whether that dependency belongs in Microsoft Foundry, GitHub Copilot, or another provider, and prove the replacement before the shutdown.
GitHub has also scheduled a final brownout for July 23, when Models requests will temporarily return errors. Treat it as a ready-made failure test rather than an inconvenience. The facts and migration guidance below were checked against GitHub and Microsoft documentation on 2026-07-20.
What disappears on July 30
GitHub’s retirement notice names four affected surfaces:
- The browser playground used to compare prompts and models.
- The model catalog shown inside GitHub Models.
- The hosted inference API.
- Bring-your-own-key endpoints routed through the product.
The same notice says the shutdown applies to all customers with active usage. GitHub had already closed Models to new customers in June; July 30 is the end of service for the remaining users, not another enrollment restriction.
This scope matters because a repository may depend on GitHub Models without making a production API call. Prompt experiments, evaluation scripts, documentation examples, CI smoke tests, and internal demos can all contain an endpoint, model identifier, or workflow that will become stale.
Choose the replacement by workload
GitHub points users in two directions, but they solve different problems.
Use Microsoft Foundry when an application needs model inference. Foundry exposes deployable models behind an inference endpoint and lets a team choose deployment types, capacity, region, and content-filter configuration. Microsoft’s GitHub Models upgrade guide describes a path from the free GitHub surface to a Foundry resource. That path requires an Azure subscription, and usage is billed to it after the move.
Use GitHub Copilot when the real workload is repository assistance. If a workflow exists to generate code, review a pull request, or help a developer inside GitHub, replacing it with a general inference endpoint may add infrastructure without improving the job. Copilot offers access to multiple models inside GitHub, but it is not a generic replacement API for an application backend.
Evaluate another model provider when Foundry does not fit the constraint. Region availability, model catalog, data policy, authentication, latency, or cost may justify a direct provider API or a self-hosted model. Do not turn the deadline into a rushed platform commitment. Preserve a small provider-neutral request contract where practical, then test candidates against the same prompts and acceptance checks.
Do not assume the endpoint swap is the whole migration
Microsoft’s guide says an application can upgrade without changing the rest of its code in the documented path, but that should not be read as a guarantee for every GitHub Models integration. Verify at least these boundaries:
- Authentication. Replace GitHub credentials and endpoint configuration with the selected service’s supported authentication. Do not reuse or copy tokens into source files.
- Model identity. Confirm the exact model and version available in the target region. A similar display name does not prove identical behavior.
- Request and response fields. Compare streaming, tool calls, structured output, error objects, token limits, and finish reasons used by your application.
- Safety behavior. Content filters and refusal behavior can differ by provider or deployment. Run the cases your product expects to accept and reject.
- Operational limits. Measure rate limits, concurrency, latency, and retry behavior under the traffic shape you actually serve.
- Billing controls. The GitHub Models experiment tier was rate-limited; Foundry is a billed Azure service. Set a budget and alert before directing normal traffic to it.
Microsoft’s resource setup documentation also notes that partner and community models can require Azure Marketplace access. Foundry models sold by Azure do not use that same Marketplace requirement. Check the offering you intend to deploy rather than treating all catalog entries alike.
A five-step migration checklist
1. Inventory every reference
Search source, environment templates, CI configuration, documentation, notebooks, and internal runbooks for GitHub Models URLs, SDK usage, model names, and tokens. Classify each result as production inference, testing, playground-only work, or dead code.
2. Record a behavioral baseline
Save representative prompts and the acceptance criteria for their results. Record latency, error handling, tool-call behavior, and structured-output validity. Outputs do not need to match word for word; the replacement must satisfy the same product contract.
3. Build the replacement behind configuration
Keep the provider endpoint, deployment name, and credentials outside application logic. A reversible configuration switch makes testing safer and prevents this deprecation from forcing a broad rewrite.
4. Exercise the July 23 brownout
During the scheduled interruption, verify that requests fail visibly, retries stop after a defined limit, and the application degrades safely. If the old endpoint can disappear without an alert, the migration is not operationally ready even if the new provider works.
5. Remove the old path after comparison
Run both paths on the fixed evaluation set, inspect failures, and switch only when the replacement meets the documented floor. Then remove stale GitHub Models examples and monitoring checks so they do not produce confusing failures after July 30.
The practical deadline
July 30 is the service cutoff, not the target date for a first migration attempt. The useful target is July 23: by the final brownout, an application should either be on its replacement or demonstrate a controlled failure with a tested recovery path.
The retirement is broad, but the response can stay narrow. Inventory the four removed surfaces, route each workload to the service that matches its job, and verify behavior rather than trusting compatible-looking names. That is enough to turn a forced shutdown into a bounded infrastructure change.