GitHub Models has been retired for all customers

GitHub Models has been retired for all customers. On July 30, 2026, GitHub ended the playground, model catalog, inference API, and bring-your-own-key (BYOK) option for every customer, including organizations that had active usage. That supersedes the earlier June notice, which only closed the service to new customers. The durable answer for a reader arriving here now is not how to start a free trial: it is how to retire an integration safely and choose a replacement for the job it used to do.

What GitHub Models was, and what changed

GitHub Models was a GitHub-hosted surface for trying selected models and calling an inference API. It was useful for early experiments because a team could compare outputs without first building separate provider integrations. That is historical context, however, not a current product recommendation.

The retirement happened in two stages:

The first-stage detail remains useful when reading older posts: GitHub’s June customer-closure announcement explicitly said existing users were unaffected at that moment. It is no longer a statement about present access. The subsequent retirement timeline made the end state unambiguous.

GitHub’s current GitHub Models documentation also draws an important boundary: GitHub Models was a separate service from GitHub Copilot. A Copilot subscription or a Copilot model picker does not resurrect a retired GitHub Models API, endpoint, rate limit, prompt format, or evaluation result.

Do not treat the old free tier or catalog as a buying guide

Older descriptions of free, rate-limited access, model availability, token prices, supported providers, and BYOK setup are archival facts. They should not be used to estimate current cost or availability. There is no live GitHub Models price card against which to compare provider pricing, and an old model name in a historical catalog is not evidence that the same model, version, region, throughput, or terms are available elsewhere.

That distinction matters especially for evaluation work. Results collected in the old playground may still be useful as internal historical observations if the team retains the prompt, input set, model identifier, parameters, date, and evaluation method. They are not a current cross-provider benchmark. Rerun the representative suite after migration before making a model or cost decision.

GitHub’s general GitHub Changelog remains the appropriate place to watch for GitHub product changes, but it cannot make the retired service available again.

The direct API migration: move to Microsoft Foundry deliberately

For an application that called the old inference API, Microsoft’s current migration guidance is the most concrete starting point. It says the services use the same inference API shape in many cases, so an endpoint-and-credential change may be small in code. That is not the same as a drop-in production guarantee: the guide also says Foundry usage is billed to an Azure subscription, models must be configured in the resource, and model availability or deployment options can differ.

Use this migration sequence:

1. Inventory every former GitHub Models endpoint, credential, model identifier, prompt asset, CI secret, and fallback path. Revoke or replace old credentials rather than leaving failed calls to retry indefinitely.
2. Create the needed Foundry resource, deploy the exact candidate model, and record its deployment name, region, deployment type, quota, and billing owner. Start with Azure AI Foundry only after checking the model card and regional availability for the workload.
3. Replace the endpoint and authentication in a non-production environment. The Microsoft guide directs teams to copy the Foundry project endpoint and API key, then test an actual prompt; where the security model permits it, consider its documented keyless authentication rather than treating a copied key as permanent infrastructure.
4. Rerun a representative evaluation set with acceptance criteria that matter to the application: output structure, tool-call behavior, latency, safety behavior, error handling, and cost at the expected traffic shape. A side-by-side answer is not enough to establish equivalence.
5. Roll out with observability and an explicit rollback target. Keep old evaluation records as context, but make the go/no-go decision on the new deployment’s results and current terms.

Microsoft Foundry can offer a broad catalog, but catalog breadth is not a compatibility promise. The relevant decision is whether a specific model deployment meets the application’s requirements in the required region, under its current billing, policy, and throughput constraints. The old assumption that all models were preconfigured is specifically called out as different in the migration guide.

When GitHub Copilot is the better replacement

Choose GitHub Copilot when the missing workflow is developer assistance inside GitHub or a supported editor, not an application-owned inference endpoint. GitHub says access to Copilot models depends on the plan, client, and any organization or enterprise policy; its model-access documentation also describes BYOK options for Copilot. Those are product and governance choices, not a guarantee that a former Models API workload will run unchanged.

For a team that needs code assistance or an agent workflow on GitHub, evaluate Copilot’s current plan and policy controls. For a service that needs programmatic inference, model deployment control, or a separately governed API surface, assess Foundry or another provider directly. If cost is the deciding constraint, price the actual replacement deployment and workload rather than carrying forward retired GitHub Models token tables.

For related reading, see how GitHub Copilot’s move to token-metered AI credits reshapes agent workflow costs. Its title is navigation only here, not evidence for a Copilot billing claim.

Preserve what is worth preserving

The sensible part of the former workflow was not the free tier. It was the habit of keeping prompts, test inputs, expected outputs, and acceptance criteria under review. Carry those artifacts forward, with dates and model/deployment identifiers, and do not claim that an old GitHub Models result predicts a new deployment.

For teams starting fresh, Microsoft Foundry is GitHub’s named destination for broad model access. Treat it as a platform to evaluate, not a shortcut around model selection, security review, or production validation. For the broader practical choice among code-assistant products, see the comparison of GitHub Copilot, Cursor, and Claude Code.