GitHub Models Is Retired: How to Migrate Safely in 2026

GitHub Models reached full retirement on July 30, 2026. If an application, evaluation workflow, or internal demo still depended on its inference API, playground, model catalog, or bring-your-own-key feature, the right response is not to keep retrying the old service. Those surfaces are no longer available, including for customers that previously had active usage.

This guide explains how to choose the correct replacement, move an application to Microsoft Foundry without treating migration as a simple URL swap, and avoid confusing GitHub Models with GitHub Copilot.

What exactly stopped working?

GitHub’s final retirement notice says that four parts of GitHub Models became unavailable to every customer on July 30, 2026:

• The interactive playground
• The model catalog
• The inference API
• Bring your own key, commonly called BYOK

This completed a retirement process announced on July 1. GitHub had also scheduled temporary brownouts on July 16 and July 23 so teams could observe how their systems behaved when requests failed. The final shutdown is different from a brownout: recovery logic cannot restore a service that has been retired.

GitHub’s current GitHub Models documentation also makes an important distinction: GitHub Models was separate from GitHub Copilot, and the retirement does not mean that Copilot has been retired.

Choose the replacement based on the workload

The fastest safe migration begins by identifying what GitHub Models was doing for you.

GitHub itself points customers that need model access to Microsoft Foundry and customers that want AI-powered GitHub workflows to Copilot. Do not replace an application’s inference endpoint with Copilot: the two products solve different problems.

For a current view of Copilot’s model controls, see NextPJ’s GitHub Copilot enterprise model policy checklist. If you are comparing hosted OpenAI models instead, our GPT-5.6 API pricing guide explains why model tier, token volume, and workload shape matter more than a headline rate.

A seven-step GitHub Models migration plan

1. Inventory the real dependency

Search application configuration, deployment secrets, CI variables, notebooks, scheduled jobs, and internal documentation for references to GitHub Models. Record the following for each workload:

• Model name and provider
• Endpoint and authentication method
• Input and output formats
• Streaming or non-streaming behavior
• Expected context size and output length
• Average and peak request volume
• Latency and error-rate expectations
• Safety filters or moderation steps
• Data residency and retention requirements

Also identify the owner and business impact. A forgotten weekend demo should not receive the same migration effort as a customer-facing support workflow.

Treat authentication credentials as sensitive during this inventory. Record where a secret is stored, not the secret itself. Do not paste keys into tickets, chat messages, migration documents, or logs.

2. Map capabilities, not just model names

A model with the same family name on another platform can behave differently because the deployed version, system instructions, safety settings, tokenizer, context limits, or serving configuration may differ. Build a short requirement sheet for each workload before selecting a replacement.

At minimum, compare output quality, supported modalities, structured-output reliability, tool use, latency, regional availability, throughput, and cost. If your application relies on a particular model revision, verify that revision in the destination catalog rather than assuming the newest model is compatible.

Microsoft says its Foundry catalog includes models sold by Azure as well as models from partners and the community. The categories differ in support, terms, deployment requirements, and integration. Review the model card and provider terms before committing.

3. Create the Foundry foundation with least privilege

Microsoft’s Foundry deployment guide lists an Azure subscription with a valid payment method, a Foundry project, and suitable role-based access as prerequisites. The guide identifies Cognitive Services Contributor, or equivalent permissions, for creating and managing deployments.

Use separate development and production resources where practical. Give engineers only the access they need, and separate deployment administration from application runtime access. Partner and community models may require an Azure Marketplace subscription and permission to accept the offering’s terms; models sold by Azure do not have that Marketplace requirement.

Before deployment, confirm region support, data residency, quota availability, provider terms, and whether your organization allows that model category.

4. Deploy and test in the playground

In the current Foundry portal, Microsoft directs users to Discover, then Models. Review the model card, choose a supported deployment type, set a clear deployment name, and deploy it into the intended project.

The deployment name matters because applications use it to route requests to that deployment. A stable naming convention should identify the environment and purpose without embedding secrets or personal data.

After the deployment reports success, use the Foundry playground to run representative prompts. Confirm basic behavior before changing any application configuration. This catches unsupported features, unexpected safety refusals, output-format changes, and region or permission problems while traffic is still isolated.

5. Update the integration as a controlled change

A production migration usually changes more than the endpoint. Review authentication, request schema, deployment identifier, timeout, retry behavior, streaming events, error parsing, rate limits, and observability.

Prefer identity-based access when the platform and hosting environment support it. If keys are required, store them in a managed secret store, rotate them, and prevent them from reaching source control or application logs.

Retries should be limited, use backoff, and apply only to errors that may succeed later. A retired endpoint, invalid credential, malformed request, or policy rejection should fail clearly rather than entering an expensive retry loop. Set explicit connection and response timeouts so one stalled inference call cannot exhaust application workers.

For agentic systems, preserve tool allowlists, approval gates, network restrictions, and audit trails during the move. The NextPJ AI agent sandbox security checklist covers the controls that should remain independent of the model provider.

6. Evaluate before sending full traffic

Create a fixed evaluation set from realistic, properly sanitized requests. Include routine cases, difficult cases, malformed inputs, prompt-injection attempts, long inputs, and outputs that must follow a schema. Remove personal, confidential, and regulated data unless the test environment is approved to process it.

Compare the old baseline, if you have saved non-sensitive results, with the new deployment. Measure task success, factual accuracy, format compliance, latency, token use, safety behavior, and estimated cost. Human review is especially important for legal, medical, financial, security, and customer-facing content.

Move traffic gradually when the architecture permits it. Start with internal users or a small canary share, watch error rate and quality, then increase traffic. Keep an application-level rollback path to a tested alternative deployment. The old GitHub Models endpoint is not a rollback option.

7. Remove dead configuration and close the migration

Once the replacement is stable, delete obsolete GitHub Models endpoints, variables, feature flags, dashboards, and runbooks. Revoke keys that are no longer needed. Update architecture diagrams and incident procedures so responders do not waste time attempting to restore a retired service.

Record the chosen model, provider, deployment type, region, owner, evaluation date, spending alert, and rollback target. Set a review date because model availability, pricing, and terms can change.

Cost and plan considerations

There is no single GitHub Models migration price. Microsoft’s Foundry pricing page says listed prices are estimates and can vary by agreement, purchase date, currency, region, model, and related services. Use the Azure pricing calculator for the specific deployment and include input tokens, output tokens, provisioned capacity if applicable, evaluations, content-safety services, logging, and network charges in the estimate.

Copilot pricing is seat-based rather than a substitute for application inference billing. As of August 3, 2026, GitHub’s Copilot plans page lists Copilot Pro at $10 per month, Pro+ at $39 per month, Max at $100 per month, Business at $19 per granted seat per month, and Enterprise at $39 per granted seat per month. Each plan has its own AI credit allowance and feature access. GitHub also notes that new self-serve Copilot Business sign-ups for organizations on GitHub Free and Team have been temporarily paused since April 22, 2026, so verify purchasing eligibility before planning a rollout.

Limitations to expect

Migration cannot guarantee identical outputs. Models are probabilistic, and platform-level system behavior may change quality even when prompts remain unchanged. A destination may also lack the exact model revision, region, throughput option, or content policy your old prototype used.

Foundry adds production controls, but it also introduces Azure resource management, role assignments, quota planning, billing, and possibly Marketplace terms. Copilot is convenient for coding workflows, but it is not a general-purpose inference endpoint for your product. These constraints are reasons to classify the workload first, not reasons to rush into the closest-looking replacement.

Conclusion

GitHub Models is not experiencing a temporary outage; it has been retired for all customers since July 30, 2026. Move application inference and model evaluation to a supported platform such as Microsoft Foundry, while reserving GitHub Copilot for coding and repository workflows.

The safest sequence is straightforward: inventory dependencies, select by capability, deploy with least privilege, evaluate realistic cases, canary the change, monitor cost and quality, and remove dead configuration. That process takes longer than changing a URL, but it avoids turning a service retirement into a security incident or a silent quality regression.