GitHub Models is being retired: what it means and where to go

GitHub is killing GitHub Models. The notice went up on June 16, 2026, and the first cut is already live: new customers can't touch it anymore.

If your org never used GitHub Models, it's gone from your account. You won't see it, and you can't start. If you're already on it, nothing breaks today. The playground, the API, and the models keep working. GitHub says it will share retirement timelines later, which is the polite way of saying the clock has started.

Here's what changed, who it actually hits, where to move, and the lesson worth taking from it.

What GitHub actually announced

The change is staged, not a single switch-off.

Step one, already in effect: new organizations and enterprises with no prior GitHub Models usage have no access, on both free and paid plans. Step two, no date yet: full retirement for everyone, existing customers included.

For new AI model access, GitHub points people at Azure AI Foundry, which makes sense. Both are Microsoft. GitHub Models always ran on Azure inference underneath, so this reads less like a shutdown and more like a herd toward the bigger, paid platform.

If you only ever used GitHub Models as a free playground to compare models, you've lost a convenient testbed. If you wired it into something real, you've got a migration coming, and the smart move is to start now while your access still works.

Who this actually affects

Not everyone who says "I use GitHub" is affected. Three groups are.

People prototyping against the GitHub Models API. You picked it because it was free and sat right next to your repos. That convenience is the thing going away.

Teams running it inside GitHub Actions. If a workflow calls GitHub Models for code review, PR summaries, issue triage, or test generation, that workflow has a dependency with an expiry date on it. Find those calls before a future deprecation finds them for you.

New teams who were about to adopt it. You're already locked out. Don't waste a sprint planning around a product you can't sign up for.

One group is mostly fine for now: existing paid customers with active usage. You keep going until GitHub announces the full retirement date. "For now" is the operative phrase. Treat it as a runway, not a reprieve.

Where to migrate

Pick based on how locked-in you want to be, not just on what's cheapest this month.

Azure AI Foundry is the official off-ramp. Big model catalog, proper SLAs, enterprise billing. If you're already in the Microsoft world (Azure, Entra, Copilot), it's the path of least friction. The trade is that you've swapped one Microsoft dependency for another, slightly deeper one.

OpenRouter is the portability play. One API key, one OpenAI-compatible endpoint, hundreds of models from different providers behind it. If a model gets pulled or repriced, you change a string, not your codebase. For anyone who got burned by GitHub Models disappearing, that's the point.

Direct provider APIs, like Anthropic, OpenAI, or Google, when you've settled on one model and want the best price and newest features without a middleman. Less flexible, more control.

Local models when the data shouldn't leave your machine, or you just want zero per-token cost. Tools like Ollama and LM Studio run capable open-weight models on a normal laptop. I walked through the whole setup in the easiest way to run LLM models locally with Ollama and LM Studio. For a lot of prototyping, this is all you ever needed.

The cleanest pattern: don't call any of these directly from your business logic. Put a thin layer in between.

# Bad: GitHub Models hard-wired into your app
import requests

resp = requests.post(
    "https://models.inference.ai.azure.com/chat/completions",
    headers={"Authorization": f"Bearer {GITHUB_TOKEN}"},
    json={"model": "gpt-4o", "messages": messages},
)

# Better: one provider variable, swap it without touching app code
PROVIDER = os.environ["LLM_PROVIDER"]  # "azure" | "openrouter" | "local"

BASE_URLS = {
    "azure": "https://YOUR-RESOURCE.openai.azure.com",
    "openrouter": "https://openrouter.ai/api/v1",
    "local": "http://localhost:11434/v1",  # Ollama
}

client = OpenAI(base_url=BASE_URLS[PROVIDER], api_key=os.environ["LLM_KEY"])
resp = client.chat.completions.create(model=MODEL, messages=messages)

Most of these speak the OpenAI-compatible format, so a single client and a base-URL swap covers the switch. The day GitHub announces a hard date, you change one env var instead of rewriting a service. That's the difference between a five-minute change and a bad week.

The real lesson: don't build on someone else's free tier

GitHub Models was free, sat next to your code, and felt permanent. None of those are the same as "safe to depend on." Free preview products are the easiest things for a company to cut, because nobody's paying and there's no contract to honour.

This isn't only a GitHub story. Governments and vendors switch off model access for their own reasons, and your build is collateral. dsrpt wrote about exactly that in the day a government switched off an AI model and what it means for your business. The takeaway is the same at both scales: if you can't swap the provider in an afternoon, you don't own your stack, they do.

I've made this argument before in the vibe coding lie: wrapper tools vs foundation tools. A thin wrapper around someone else's API has no moat and no exit. When that API moves, you move, on their schedule.

Three habits keep you out of this trap. Abstract the provider behind your own interface so swapping is a config change. Prefer open standards and open weights where you can: open-weight models you can self-host can't be retired out from under you, which is half the reason open source software is worth caring about. And treat any free tier as a prototype, never as production infrastructure.

If you're plumbing AI into real tools, MCP is the more durable layer to build on than any single vendor's playground, because it standardises how models talk to your systems regardless of which model you run. And if all of this feels like jargon, these 10 AI concepts are the vocabulary to get fluent in before the next platform gets retired.

What to do now

Three moves, in order.

1. Grep your codebase and your GitHub Actions for any GitHub Models calls. Usually a hit on models.inference.ai.azure.com or the gh models CLI. Write down every place it shows up.
2. Pick a replacement by how portable you need to be. OpenRouter if you want to never get stuck again, Azure AI Foundry if you're already Microsoft-deep, local models if the data should stay home.
3. Put a provider abstraction in front of it now, while your old access still works. Migrating calmly beats migrating in a panic when the hard date lands.

GitHub gave existing users a window. Use it. The teams that get hurt by retirements like this are the ones who treated a free tool as permanent and only looked up when it was already gone.

Frequently asked questions

Is GitHub Models being shut down completely?

Yes, eventually. As of June 16, 2026, GitHub announced it is retiring GitHub Models. The first step blocks new customers. Existing customers with active usage can keep using the playground, API, and models for now. GitHub says it will share full retirement timelines later, so a complete shutdown is coming but has no public date yet.

I already use GitHub Models. Does anything break today?

No. If you have active usage, nothing changes immediately. The playground, API, and models all keep working. The change so far only blocks new organizations and enterprises that never used it. Treat your continued access as a migration runway and move before GitHub announces a hard cutoff.

What's the official alternative to GitHub Models?

GitHub points new projects to Azure AI Foundry, which offers a broad model catalog and runs on the same Microsoft infrastructure GitHub Models used. If you want provider portability instead of staying in the Microsoft ecosystem, OpenRouter gives you one API for many models, and local tools like Ollama or LM Studio let you run open-weight models with no per-token cost.

How do I migrate off GitHub Models without rewriting my app?

Most alternatives speak the OpenAI-compatible API format, so the switch is usually a base-URL and key change rather than a rewrite. Put a thin provider abstraction in front of your model calls, controlled by one environment variable, so you can swap between Azure, OpenRouter, or a local model without touching your business logic.

Why does GitHub keep pointing people to Azure AI Foundry?

GitHub is owned by Microsoft, and GitHub Models always ran on Azure inference underneath. Retiring the free, GitHub-branded layer and steering users to Azure AI Foundry consolidates AI access onto Microsoft's main paid platform, with enterprise billing and SLAs, rather than maintaining a separate free product next to your repos.