GitHub Models retired: what to use now

GitHub Models retired: decide whether to migrate to Microsoft Foundry Models, use GitHub Copilot, or choose another inference API.

Faisal Karkoh · 12 Oct 2026 · 9 min read

If an older tutorial tells you to use GitHub Models, do not start by changing token scopes or looking for a new GitHub endpoint. The right replacement depends on what the tutorial was doing: application inference, model comparison, GitHub Actions automation, prompt evaluation, or developer assistance inside GitHub and an IDE.

The practical outcome is simple. Application code needs a real inference API replacement, usually Microsoft Foundry Models or another provider API. GitHub Copilot is the right replacement only when the old workflow was about coding help, repository work or chat inside supported developer surfaces. If the decision is really about the day-to-day coding stack rather than API inference, the comparison in GitHub Copilot vs Cursor is the more relevant next read.

This note is researched from official documentation, pricing pages and changelogs accessed on 2026-10-12. The worked migration example is illustrative and was not executed against a live service.

The short answer: GitHub Models is gone

GitHub's changelog says GitHub Models was fully retired on July 30, 2026. The playground, model catalog, inference API and bring-your-own-key support are no longer available to any customer, including customers that previously had active usage.

That means an old GitHub Models tutorial is not recoverable by creating a fresh personal access token, changing fine-grained token permissions or relying on the default GITHUB_TOKEN in GitHub Actions. The service path itself has gone.

GitHub Copilot was not retired. GitHub Docs describes GitHub Models as a separate service from GitHub Copilot and unrelated to Copilot services. The retirement breaks GitHub Models-specific playground, catalog and inference workflows, not Copilot seats or Copilot Chat.

First identify what the old tutorial was using

The main mistake is to treat this as a generic GitHub-to-GitHub migration. It is not. Identify the old job first, then choose the replacement.

Old tutorial pattern	What it probably needs now	Why
Application code calling a GitHub Models inference endpoint	Microsoft Foundry Models or another provider API	The app needs an endpoint, credentials, a deployed or selected model and quota.
GitHub Models playground used to compare prompts or model outputs	Microsoft Foundry, Copilot model switching, or provider playgrounds	The replacement depends on whether the comparison is for production inference or developer exploration.
GitHub Actions workflow making model calls	A workflow using explicit provider credentials or Azure identity	A GitHub token cannot restore a retired inference service.
Prompting or evaluation lesson using GitHub Models examples	Any supported model API with the lesson adapted to its response format	The teaching concept may survive, but the endpoint will change and model identifiers may need to change; in Foundry, the deployment name is used in the model parameter to route requests.
Editor chat, code explanation or repository assistance	GitHub Copilot	This is a developer-assistance workflow, not an application inference API.

GitHub's own next-step guidance makes the same split: projects that need model access should look at Microsoft Foundry, while AI-powered workflows directly on GitHub should use Copilot, according to GitHub Docs. For maintenance work that stays inside repository issues, branches and pull requests, AI agent GitHub use cases gives a better frame than trying to revive a retired inference endpoint.

Migration path for application code: move the endpoint, credential and model name

For code that still calls the retired GitHub Models inference endpoint, Microsoft documents Microsoft Foundry Models as the migration path. Microsoft Learn says both services use the same inference API, so migration usually means changing the endpoint and credentials.

In practice, expect more than one environment variable change. A small app or script normally needs these decisions made explicitly:

Create or use a Microsoft Foundry resource backed by an Azure subscription.
Deploy or add the model before the app references it.
Update the base endpoint to the Foundry endpoint.
Use the documented /openai/v1/ route for OpenAI v1 API calls.
Pass the Foundry deployment name in the model field, not an assumed catalog model name copied from the old GitHub tutorial.
Choose either a Foundry key or Microsoft Entra ID authentication.
Move secrets into the runtime or CI secret store instead of hard-coding them.

Two details catch many migrations. First, Foundry Models does not automatically expose every model at an endpoint. Microsoft states that teams must add the models they plan to use before indicating them in the model parameter. Second, the deployment name routes inference requests to the specific deployment, as explained in Microsoft's Foundry deployment documentation.

For OpenAI v1-style calls, Microsoft's deployment documentation says to call the /openai/v1/ route, pass the deployment name in the model field and omit an api-version parameter because the route uses implicit versioning.

What changes when you move to Microsoft Foundry

Old GitHub Models tutorials often hide operational work because the tutorial experience was designed around a GitHub-hosted catalogue and playground. Moving to Microsoft Foundry makes the cloud boundary explicit.

The prerequisites change first. Microsoft's migration guide says the Foundry path requires an Azure subscription with a valid payment method. Partner and community models require Azure Marketplace access, while Foundry Models sold by Azure do not have that Marketplace subscription requirement.

Deployment choices also matter. Microsoft's deployment type documentation describes Standard as pay-per-token, Provisioned as reserved capacity and Batch as discounted asynchronous processing. It also states that deployment type affects billing, throughput and where prompts and responses may be processed, including global, data-zone and geography options.

Quota is another migration issue, not just a scaling issue. Foundry quota is assigned per subscription on a per-region, per-model basis in tokens per minute, and model availability can vary by region. If the desired model is unavailable in the required region or the TPM quota is too low, the correct fix may be to change region, model, deployment type or provider rather than repeatedly retrying the old GitHub Models path.

Do not estimate Foundry production cost from Copilot pricing. Foundry Standard, Provisioned and Batch costs vary by model, region, agreement and currency. The only safe cost statement from the supplied sources is the billing shape: pay-per-token for Standard, reserved capacity for Provisioned and discounted asynchronous processing for Batch. Microsoft documents Global Batch as 50% less cost than Global Standard with a 24-hour target turnaround where supported, which makes it relevant for non-real-time workloads rather than interactive app features.

When GitHub Copilot is the better replacement

Choose GitHub Copilot when the old GitHub Models workflow was really about helping a developer write, understand or change code. Examples include IDE chat, repository questions, code explanation, branch work or choosing a model for development assistance.

Copilot is not the resurrected GitHub Models inference API. It should not be used as the replacement for application code that needs to send production requests from your own backend, worker or GitHub Actions job. That code needs provider credentials and an inference endpoint outside the retired GitHub Models service.

Copilot model availability is conditional. GitHub's Copilot model documentation says the available models depend on the user's plan, the Copilot client or surface, administrator policies and model availability over time. GitHub's Copilot Chat documentation also says Business users need their organisation to grant members the ability to switch models.

Copilot can also add models from providers such as Anthropic, Gemini and OpenAI or from the AI Toolkit for VS Code, but GitHub says AI Toolkit use is in public preview and subject to change. GitHub documents that provider keys, model IDs or a GitHub PAT may be required depending on the provider or model. For Business and Enterprise BYOK use in supported IDEs, the relevant policy must be enabled.

Cost belongs in the decision only when Copilot is replacing a developer workflow. GitHub's Copilot plan documentation lists Copilot Pro at $10 USD per month with 1,000 base GitHub AI Credits and 1,500 total monthly AI credits as of 2026-10-12. Copilot Business is listed at $19 USD per granted seat per month with 1,900 GitHub AI Credits per user per month, and usage beyond the enterprise pool is charged at $0.01 USD per AI credit. These numbers help budget seats; they should not be used to estimate production inference cost.

Worked migration checklist

Illustrative example, not observed: a developer finds an older tutorial for a small script with one chat-style model call that previously used the GitHub Models inference endpoint. The goal is to keep the app behaviour roughly equivalent while replacing the retired service.

Inventory the old dependency. Search the repository for GitHub Models endpoint strings, old environment variable names, tutorial comments, playground references, catalog references and BYOK instructions.
Classify the job. If the code is part of the app runtime or a CI workflow, treat it as application inference. If it is only editor chat or repository assistance, move the workflow to Copilot instead.
Choose the replacement. For Foundry, confirm the Azure subscription, payment method, Marketplace access if the chosen model requires it, target region and TPM quota.
Deploy or add the model. Do this before changing the app to reference it. Record the deployment name because it becomes the value passed in the model field.
Update configuration. Replace the retired GitHub Models endpoint with the Foundry endpoint and the documented /openai/v1/ route for OpenAI v1 calls. Replace the old token variable with either a Foundry key or Microsoft Entra ID configuration.
Move secrets deliberately. Store the key or identity settings in the runtime secret store or CI secret store. Do not leave old GitHub Models token names in place if they make the workflow look recoverable.
Run a smoke prompt. Use a short prompt with a simple expected shape, such as a one-sentence JSON-safe answer. The expected output is a valid response from the replacement service, not an exact wording match.
Run a small regression set. Use the app's own important prompts to catch changed response format, latency, refusal behaviour or parsing assumptions.
Remove dead instructions. Delete README steps that tell developers to open the GitHub Models playground, browse the retired catalog, configure BYOK in GitHub Models or create a GitHub PAT for model inference.

The expected final state is clear: the app no longer references the GitHub Models endpoint, catalog, playground or BYOK configuration; the request points to the replacement endpoint; the model field contains the Foundry deployment name; and secrets are provided by the runtime or CI environment.

Failure cases to expect

The old endpoint remains unavailable. The GitHub Models inference API was retired for all customers, so a new token does not bring it back.
The model was never deployed. Foundry will not behave like the old GitHub Models catalog if the target model has not been added or deployed first.
The model parameter is wrong. In Foundry, the model field should contain the deployment name for the target deployment, not a copied catalog name from an old tutorial.
Marketplace access is missing. Partner and community models require Azure Marketplace access unless the model is a Foundry Model sold by Azure.
The region or quota blocks the workload. Model availability can vary by region, and TPM quota is assigned per subscription on a per-region, per-model basis.
Authentication fails. Check the endpoint, secret name, key and Entra role assignment before changing application logic. For keyless authentication, Microsoft's Entra ID documentation says developers making authenticated inference API calls need the Cognitive Services User role at the Foundry resource scope.
CI assumes GitHub credentials are enough. A GitHub Actions workflow needs explicit provider credentials or Azure identity for the new service. It should not assume GITHUB_TOKEN or a fresh GitHub PAT can call the retired GitHub Models API.
Copilot is chosen for the wrong job. Copilot can be the right developer-workflow replacement, but it is not a drop-in application inference endpoint.

If the retired workflow lives in GitHub Actions, the migration is also a CI safety problem: replace implicit GitHub credentials with explicit provider access, scope the secrets, and review the pattern against a safer workflow such as running AI coding agents in GitHub Actions safely.

Next action: open the old tutorial or repository and classify the dependency first. If it is runtime inference, plan an API migration. If it is developer assistance, move the workflow to Copilot and check plan, client and admin policy before standardising it for the team.