DEV Community

Ahab
Ahab

Posted on • Originally published at indieseek.co

GitHub Models retirement: migrate before July 30, 2026

#ai #opensource #productivity #programming

Quick answer

GitHub Models will shut down completely on July 30, 2026. The playground, catalog, inference API, and bring-your-own-key endpoints will all disappear for existing customers. GitHub has also scheduled short brownouts on July 16 and July 23, when requests will deliberately fail.

If an application calls models.github.ai, do not treat this as a model-name update. Inventory the dependency, choose a replacement provider, move authentication and billing, put the provider behind one adapter, run contract tests, and use the brownouts as a controlled failover rehearsal.

Find every GitHub Models dependency
-> choose a replacement by workload
-> move endpoint, auth, and model mapping
-> compare outputs and tool calls
-> rehearse failure before July 30
-> remove the GitHub token only after production verification
Enter fullscreen mode Exit fullscreen mode

Who this is for

This checklist is for indie developers and small teams that used GitHub Models for a prototype, GitHub Action, evaluation script, chatbot, coding workflow, or production API.

It is not about GitHub Copilot's model picker. GitHub says Copilot remains the path for AI workflows inside GitHub. This guide covers applications that call the GitHub Models inference API or rely on its playground, catalog, or BYOK surface.

What changes, and why now

GitHub's retirement notice is unusually concrete: all customers lose access on July 30, and the two brownouts occur before the final cutoff. Requests that survive only because an old token or endpoint still works today are already migration risks.

The current GitHub REST example calls an organization endpoint under https://models.github.ai/.../inference/chat/completions, authenticates with a GitHub token, and uses publisher-prefixed IDs such as openai/gpt-4.1. A replacement may use an OpenAI-compatible request shape, but the endpoint, credential, deployment name, rate limits, model availability, and billing owner can all change.

GitHub recommends Microsoft Foundry for applications that need model access. Microsoft documents an upgrade path, but new Foundry integrations should use its OpenAI v1-compatible endpoint. Another practical option for a small multi-model product is an OpenAI-compatible gateway such as OpenRouter. Direct provider APIs remain a good choice when you want fewer routing layers and accept provider-specific code.

Step 1: find the real dependency

Search code, CI, documentation, and local configuration. Do not print secret values into logs.

rg -n --hidden \
  'models\.github\.ai|models\.inference\.ai\.azure\.com|GITHUB_MODEL|models: read' \
  .github src app scripts test docs .env.example

rg -n --hidden \
  'chat/completions|stream: true|tool_choice|response_format' \
  src app scripts test
Enter fullscreen mode Exit fullscreen mode

Record each call site with these fields:

Field Why it matters
Owner and environment A forgotten scheduled job can fail after the main app is migrated
Endpoint and auth source GitHub tokens cannot simply be relabeled as provider keys
Model ID and required capabilities Tool calling, structured output, vision, and context limits vary
Streaming behavior SSE chunk shapes and error handling need contract tests
Rate and cost assumptions Free prototype limits rarely match production billing
Fallback and timeout Brownouts should degrade deliberately, not hang users

Also export prompts or evaluation examples from the playground. The playground disappears too; a working endpoint migration does not preserve experiments that only exist in the UI.

Step 2: choose the replacement by workload

Use a decision rule instead of choosing from a logo list.

Need Starting point Tradeoff to verify
Closest official upgrade path and Azure governance Microsoft Foundry Azure subscription, region, deployment setup, and new auth surface
One OpenAI-compatible endpoint across many providers OpenRouter or another gateway Routing policy, data handling, provider availability, and gateway dependency
Maximum control over one model provider Direct provider API More provider-specific code and a separate fallback plan
AI assistance inside GitHub rather than an app inference API GitHub Copilot Not a drop-in backend for your product API
Local or offline development A local OpenAI-compatible server Hardware, model quality, tool support, and production parity

For model selection, separate the provider migration from the model upgrade. First preserve the old task's behavior with the closest supported model. Then compare quality and cost. The GPT-5.6 model choice guide shows how to route hard reasoning, everyday generation, and bounded high-volume work without using one expensive default.

Step 3: put inference behind one adapter

Do not replace a hard-coded GitHub URL with a different hard-coded URL at every call site. Centralize the differences:

type ChatRequest = {
  messages: Array<{ role: "system" | "user" | "assistant"; content: string }>;
  task: "critical" | "default" | "bounded";
};

const provider = {
  baseUrl: process.env.LLM_BASE_URL!,
  apiKey: process.env.LLM_API_KEY!,
  models: {
    critical: process.env.LLM_MODEL_CRITICAL!,
    default: process.env.LLM_MODEL_DEFAULT!,
    bounded: process.env.LLM_MODEL_BOUNDED!
  }
};

export async function createChat(request: ChatRequest) {
  return fetch(`${provider.baseUrl}/chat/completions`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${provider.apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: provider.models[request.task],
      messages: request.messages
    })
  });
}
Enter fullscreen mode Exit fullscreen mode

For Microsoft Foundry, the model value is the deployment name, not necessarily the catalog model name. Microsoft also documents a different endpoint and credential scope for its current OpenAI v1 route. Treat those as configuration and test them explicitly.

Step 4: run a migration test matrix

Run the old and new paths against a small set of real tasks before switching traffic.

plain response
streaming response
tool call with valid arguments
structured output or JSON schema
long input near your real percentile
rate-limit response
timeout and provider 5xx
unsafe or policy-sensitive input
Enter fullscreen mode Exit fullscreen mode

Compare task success, tool-call validity, latency, token usage, and human correction time. Exact wording is not a useful pass condition for generative output. For agent workflows, keep permissions and secret access narrow during the migration; the untrusted repository sandbox checklist remains relevant even when the model endpoint changes.

Step 5: use the brownouts as a rehearsal

Before July 16, configure a short timeout and an intentional failure path. During a brownout, verify that:

  • health checks detect the provider failure;
  • retries are bounded and use jitter;
  • non-critical work queues safely instead of duplicating jobs;
  • the fallback model receives compatible inputs;
  • users see a truthful degraded-state message;
  • alerts identify the affected provider and call site.

Do not wait for GitHub's brownout to test this. Simulate a 503, timeout, and invalid credential locally first. The scheduled interruption should confirm your controls, not introduce the first failure you have seen.

Cutover and rollback checklist

  1. Send a small percentage of production traffic to the new provider.
  2. Compare success, cost, latency, and corrections for at least one representative workload window.
  3. Switch the default while retaining a time-bounded rollback flag.
  4. Verify scheduled jobs, GitHub Actions, and rarely used admin paths.
  5. Remove GitHub Models secrets and permissions only after no callers remain.
  6. Delete the old fallback before July 30 so it cannot create false confidence.

Common mistakes

  • Updating only the model ID while leaving the GitHub endpoint and token in place.
  • Migrating the main web request but missing an Action, cron job, or evaluation script.
  • Assuming "OpenAI-compatible" means identical streaming, tools, errors, or safety behavior.
  • Choosing a provider before listing required capabilities and regions.
  • Copying production secrets into migration scripts or CI logs.
  • Waiting until July 30 instead of using the brownouts to verify failover.
  • Keeping a dead GitHub Models fallback after the final cutover.

FAQ

When does GitHub Models shut down?

GitHub says the full retirement is July 30, 2026. Short brownouts are scheduled for July 16 and July 23.

Does this also remove GitHub Copilot?

No. The retirement notice covers GitHub Models, including its playground, catalog, inference API, and BYOK endpoints. GitHub points users who want AI workflows inside GitHub toward Copilot.

Is Microsoft Foundry a drop-in replacement?

It is GitHub's recommended application-model path and Microsoft documents an upgrade workflow, but you still need to verify subscription access, deployment names, endpoint format, authentication, regional model availability, limits, and billing. Treat it as a migration, not a key swap.

Can I move to OpenRouter instead?

OpenRouter exposes an OpenAI-compatible chat-completions API and a broad model catalog, so it can reduce code changes for a multi-model prototype. Verify its privacy, routing, model support, cost, and fallback behavior against your product requirements before cutover.

Sources

Top comments (0)