GitHub Models Shuts Down July 30: The Migration Is Bigger Than an Endpoint Swap

Rohit Ramachandran

Jul 17, 2026Updated Jul 17, 2026

• ai
• github
• github-models
• microsoft-foundry
• copilot
• developer-tools

GitHub Models Shuts Down July 30: The Migration Is Bigger Than an Endpoint Swap

GitHub Models is not deprecating a few old model IDs. On July 30, 2026, GitHub is removing the control plane that made a catalog of models feel like one GitHub-native service: the playground, model catalog, inference API, bring-your-own-key path, and related interface.

The visible code change may look small. Replace models.github.ai, change a credential, and pick a model at the new provider. That is the easy part.

The dangerous part is everything the old endpoint was doing quietly: GitHub authentication, organization attribution, model naming, rate limits, content filtering, streaming behavior, tool-call formatting, prompt evaluation, billing, and embedding generation. If you migrate only the URL, the request may succeed while the product contract changes underneath it.

GitHub's own recommendations reveal the right decision tree. It points projects that need model access toward Microsoft Foundry and GitHub-native workflows toward GitHub Copilot. Those are different products for different jobs. Foundry is a model deployment platform. Copilot is a developer and agent workflow. Neither is a universal drop-in replacement for GitHub Models.

There is also less timing precision than some coverage suggests. GitHub has announced the date, but not the cutoff hour, timezone, final error code, or duration of the remaining July 23 brownout. The safe deadline is therefore not a guessed midnight on July 30. It is a tested cutover before then.

This guide maps the exact blast radius, separates the migration routes, and gives builders a test plan that catches the failures a successful curl command will miss.

The deadline, without invented precision

GitHub is retiring access in two stages.

On June 16, it closed GitHub Models to new customers. New organizations and enterprises without previous usage could no longer start using the product on free or paid plans. Existing customers with active usage were allowed to continue.

On July 1, GitHub announced the hard retirement date: July 30, 2026. This second notice applies to everyone, including existing customers with active usage.

GitHub scheduled brief brownouts for July 16 and July 23. During them, Models requests temporarily return errors and then recover. The first date has passed. The second is the last official failure rehearsal before retirement.

What is actually disappearing

The retirement notice names four surfaces and then says the related UI will be removed. GitHub's product overview describes a larger suite around them: prompt development, side-by-side comparison, evaluators, repository-stored prompt configurations, and production integration.

The careful reading is straightforward. The whole GitHub Models product is retiring. The playground, catalog, inference API, and BYOK are definitely in scope. Secondary behavior—such as how long UI-only evaluation history remains accessible—is not individually documented, so export what matters instead of assuming a retention promise.

The documented REST surface contains five routes:

GET  https://models.github.ai/catalog/models
POST https://models.github.ai/inference/chat/completions
POST https://models.github.ai/orgs/{org}/inference/chat/completions
POST https://models.github.ai/inference/embeddings
POST https://models.github.ai/orgs/{org}/inference/embeddings

Those routes are defined in GitHub's catalog, chat inference, and embeddings references.

GitHub has not published the URL shape of internal BYOK management endpoints. Its current BYOK documentation presents the feature through organization settings and says custom models feed Prompts, Playground, and Models in Actions. That is enough to inventory the dependency, but not enough to promise an automated export.

The blast radius hides in developer tooling

The obvious search string is models.github.ai. It will not find everything.

The official gh models extension wraps the service for listing models, running prompts, evaluating .prompt.yml files, and generating tests. Its implementation points at the Models host. A shell script that only says gh models eval is still an API dependency.

GitHub's actions/ai-inference action has also defaulted to a github-models provider. An Actions file may never contain the endpoint because the action chooses it internally. GitHub Apps and fine-grained tokens can carry a models: read permission, while Actions jobs can use their built-in GITHUB_TOKEN with the same capability.

The ecosystem is already unwinding these integrations. LangChain4j opened a pull request to remove its GitHub Models module, including chat and embedding documentation. The llm-github-models plugin opened a retirement issue, and Microsoft's .NET documentation has an open cleanup issue.

Run an inventory that looks for wrappers as well as hosts:

rg -n --hidden \
  'models\.github\.ai|models\.inference\.ai\.azure\.com|gh models|github/gh-models|actions/ai-inference|models:[[:space:]]*read|\.prompt\.ya?ml' \
  . .github

The older models.inference.ai.azure.com host matters because stale tutorials still mention it. GitHub deprecated that endpoint in July 2025 and later removed it in favor of models.github.ai. If you find it now, you have an older broken dependency as well as a 2026 migration task.

GitHub's two replacements answer different questions

GitHub's retirement notice gives two high-level destinations. Microsoft Foundry offers a broad model catalog for projects that need model access. GitHub Copilot offers models for workflows directly on GitHub.

That wording is more useful than it first appears. It separates AI inside your product from AI doing work on your repository.

Copilot is not being retired. GitHub names it as an alternative. GitHub Actions is not being retired either; only Actions workflows that call the Models service are in scope. The wider GitHub Marketplace remains. The affected catalog is the Models catalog, not every app and action sold through Marketplace.

Route one: move application inference to Microsoft Foundry

Microsoft Foundry is the closest official destination for teams that used GitHub Models as a general inference platform. It can expose multiple model deployments behind one Foundry resource and supports API-key or Microsoft Entra ID authentication.

It is still not an endpoint swap.

GitHub Models accepted a GitHub token and a catalog ID such as openai/gpt-4.1. Foundry requires a resource, a deployed model, a deployment name, a supported region and capacity type, credentials, and a content-filter configuration. Microsoft states that deployments are Azure resources subject to Azure policies, and that model availability varies by region and deployment type.

The stable path is the OpenAI/v1 API. A minimal Python shape looks like this:

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://<resource>.openai.azure.com/openai/v1/",
    api_key=os.environ["AZURE_OPENAI_API_KEY"],
)

response = client.chat.completions.create(
    model="my-production-deployment",  # deployment name, not a GitHub catalog ID
    messages=[{"role": "user", "content": "Summarize this release."}],
)

For Entra ID, Microsoft documents DefaultAzureCredential with a bearer token provider. That is usually preferable to a long-lived API key for production workloads because access can be governed through Azure roles and workload identity.

The important migration artifact is not a global search-and-replace. It is a model manifest:

logical_name: support-summary
old_github_id: openai/gpt-4.1-mini
new_provider: microsoft-foundry
new_deployment: support-summary-2026-07
region: approved-data-zone
auth: managed-identity
input_contract: text
output_contract: json-schema-v3
fallback: support-summary-secondary
owner: customer-platform

That manifest prevents provider-specific names from leaking into every feature. It also gives operations, security, and finance one place to see what actually replaced the retired route.

Foundry does preserve an OpenAI-like request shape, but test the actual deployment. A matching family name does not guarantee a matching model version. On July 17, GitHub's live catalog returned 37 entries across OpenAI, Meta, Microsoft, Mistral AI, DeepSeek, and Cohere. Microsoft's current Foundry catalog includes many of those families, but not a guaranteed one-to-one copy of every older GitHub entry. Foundry uses deployment names in requests, not GitHub's publisher/model identifiers.

If you already used GitHub Models BYOK with OpenAI or AzureAI, going directly to the provider may be simpler than creating a new intermediate layer. The decision should come from required models, data residency, procurement, quotas, support, and operational ownership—not from the fact that GitHub mentioned Foundry first.

Route two: move repository automation to Copilot

Some Models workloads were never really application inference. They were repository jobs: summarize issues, draft release notes, classify pull requests, create reports, or generate documentation inside GitHub Actions.

Copilot is a better conceptual replacement for that work because it brings a tool-using agent and repository context. But it changes the abstraction from “send messages to a model” to “delegate a task to an agent.”

The distinction matters:

GitHub Models request
  -> prompt + model + parameters
  -> completion

Copilot workflow
  -> task + repository context + tools + permissions
  -> agent actions and result

GitHub has added a concrete bridge for Actions users. actions/ai-inference v2.1.0 and later supports provider: copilot. The action's documentation explains that this route installs and authenticates Copilot CLI, uses Copilot-compatible model names, and ignores some inputs that applied to the GitHub Models provider.

For broader automation, GitHub recommends Agentic Workflows or Copilot CLI in Actions. Organization-owned repositories can use the built-in GITHUB_TOKEN with copilot-requests: write when the organization policy is enabled. That preserves the useful “no stored PAT” property, but billing moves to Copilot AI credits and the permission contract changes.

Do not route embeddings, a customer-facing chatbot, or a low-level structured-output service through Copilot merely because the old call ran in Actions. Copilot is the right destination when the job is developer automation. It is not GitHub's replacement public embeddings endpoint.

BYOK does not remove the migration

BYOK can create a false sense of safety: “The key was already ours, so nothing changes.”

The provider key may be yours, but GitHub Models supplied the brokerage layer around it. Organization owners could store keys, define custom models, control publishers, and expose those models across Prompts, Playground, and Models in Actions. That control plane disappears with the service.

There are two clean exits:

• Call the existing OpenAI or Azure endpoint directly from your application, with your own secret management and policy layer.
• Configure the separate Copilot BYOK mechanisms if the workload belongs in Copilot Chat, CLI, SDK, or supported IDEs.

Copilot BYOK is a separate feature. It does not keep models.github.ai alive and does not turn Copilot into a drop-in public inference API.

Before the Models UI disappears, record each custom model's provider, base URL, model/deployment name, allowed teams, key owner, billing owner, and data-handling approval. After the replacement is verified, remove the old GitHub configuration and rotate the provider credential. GitHub has not documented how stored BYOK secrets will be deleted or exported at retirement, so rotation is the defensible cleanup.

Preserve the work around the model

GitHub Models encouraged teams to store prompt configurations as .prompt.yml or .prompt.yaml files in repositories. Those files are normal Git content. GitHub has not said it will delete them, and the retirement of a UI should not be described as deletion of repository files.

The runtime around those files is the fragile part.

A prompt file can preserve messages, variables, a model ID, parameters, test data, and evaluator definitions. It does not guarantee that another platform understands every field or calculates relevance, groundedness, and custom prompt scores the same way. UI-created presets may also contain parameters and optional chat history that never became a committed file.

Before cutover, preserve four layers:

This is also the useful connection to OpenAI Skills and portable workflow packages: a file format can move while permissions, tools, versions, and runtime behavior remain platform-specific. Portability is something you test, not something a YAML extension grants automatically.

Embeddings are the silent high-risk migration

Chat failures are visible. A request errors or the answer looks wrong. Embedding failures can stay hidden while retrieval quality decays.

GitHub Models currently documents two OpenAI embedding entries, text-embedding-3-small and text-embedding-3-large. Microsoft Foundry also supports these model families. That still does not justify assuming every existing vector can be mixed with every new vector.

An embedding index depends on more than output dimensions. It depends on the exact model and version that produced the vectors, any dimension reduction, normalization, chunking, preprocessing, and query strategy. If document vectors came from one embedding space and new queries come from another, the numbers can have the same length and the retrieval can still be wrong.

Treat the vector store as a migration boundary:

same exact model/version and dimensions
  -> validate a sample, then continue cautiously

different model, version, or dimensions
  -> create a parallel index
  -> re-embed the corpus
  -> compare recall and ranking
  -> switch queries only after acceptance tests

Measure recall on real queries, not just cosine similarity on two hand-picked sentences. Check top-k overlap, relevant-document rank, language coverage, latency, storage growth, and cost. Keep the old index read-only until the new one is proven, but do not plan a rollback that depends on GitHub Models after July 30.

A green response is not a completed migration

The first successful request proves networking and authentication. It says almost nothing about application compatibility.

Use a contract suite that reflects the feature your users see:

Freeze the test inputs before tuning the new provider. Otherwise a prompt rewrite, model change, and endpoint migration happen at once, and you cannot tell which change caused the result.

This is the same broader lesson behind Kimi K3's hidden harness contract: an OpenAI-compatible request shape is useful, but the system contract includes state, tools, caching, parsing, and operational behavior. Compatibility reduces syntax work. It does not remove evaluation work.

The migration plan I would run now

With one brownout and the final date left, the goal is controlled cutover, not architectural perfection.

Start by creating a dependency ledger. Include owner, repository, environment, call volume, model, modality, authentication method, billing account, data classification, fallback, and business impact. A low-volume embeddings job that updates a search index may deserve higher priority than a high-volume internal summarizer because its bad output persists.

Then separate shadowing from side effects. It is safe to send the same summarization prompt to two providers. It is not safe to let two agents both comment on issues, modify files, call customer systems, or send notifications. Capture the candidate output without executing its external actions.

For July 23, do not wait for GitHub Status to tell you when the test starts. GitHub Status has no dedicated Models component, and the public maintenance feed did not list a Models-named event as of July 17. Keep failover enabled for the day, alert on the endpoint directly, and inject synthetic 429s, 5xx responses, timeouts, malformed streams, and authentication failures in your own test environment.

After cutover, remove the old dependency in layers. Stop traffic first. Observe the replacement. Then remove models: read, gh models calls, provider defaults, obsolete secrets, and runbook instructions. A hurried credential rotation before the new path is stable turns a reversible migration into an outage.

The product lesson is larger than this shutdown

GitHub launched Models as a limited beta in August 2024, moved it into public preview, added GitHub Actions token integration, exposed a REST API, and introduced pay-as-you-go billing and BYOK. In June 2025, GitHub described the paid tier as production-ready inference. Roughly a year later, it announced retirement.

That history does not prove that every preview or platform API is unsafe. It does prove that “production-ready capacity” is not the same promise as “durable product surface.” GitHub has not explained why Models is retiring, and it has not said the product is being merged into Copilot or Foundry. Any strategic explanation must be labeled as interpretation.

Here is mine: Microsoft and GitHub appear to be separating two markets that GitHub Models briefly joined.

AI used to build software
  -> Copilot, Copilot CLI, coding agents, Agentic Workflows

AI embedded inside software
  -> Microsoft Foundry, direct model APIs, internal gateways

That boundary is commercially clean. Copilot owns the developer workflow. Foundry owns deployment, governance, regions, quotas, and enterprise inference. GitHub Models sat between them as a convenient experiment-and-proxy layer.

The builder response should not be cynicism. It should be a small portability budget:

• Keep business logic outside provider SDK wrappers.
• Use logical model names and an explicit deployment map.
• Maintain a frozen cross-provider eval set for critical workflows.
• Log provider, deployment, model version, fallback, finish reason, latency, and cost.
• Design a degraded mode before the preferred provider disappears.
• Treat prompt files, tool schemas, and labeled eval data as product assets.

RohitAI has argued for this kind of resilience before. Sakana Fugu's learned orchestration shows why routing becomes valuable when models and providers change. The earlier Fable 5 shutdown analysis framed model access as infrastructure risk. GitHub Models makes the lesson more ordinary and therefore more useful: a service can disappear because of a product decision, not only a geopolitical crisis.

Final recommendation

If an application still calls GitHub Models, treat the migration as an active reliability issue now—not as a July 30 maintenance ticket.

Use Microsoft Foundry or a direct provider for application inference. Use Copilot when the job is repository-aware agent work. Preserve prompt and evaluation assets before the UI disappears. Give embeddings their own re-index decision. Use the stable OpenAI/v1 path in Foundry, not the retiring Azure AI Inference beta SDK. Test the contract under failure, then cut over with time to observe it.

Most importantly, keep the facts precise. GitHub has announced a date, two brownout dates, and the surfaces being removed. It has not announced the final hour, error code, reason, redirect, data-export path, or compatibility shim.

The deadline is real. The invented details are not.

Frequently asked questions