GitHub Models Retires July 30: AI Migration Plan
GitHub Models shuts down on July 30, 2026. Migrate APIs, models, identities, tests and secrets safely with this production-ready checklist.
- AUTHOR
- Karol Rapacz / CEO, Penetration Tester (OSCP, PNPT)
- PUBLISHED
- 18 July 2026
- READING TIME
- 14 min read
- TOPIC
- AI in business
GitHub Models will be retired completely on 30 July 2026. The playground, model catalogue, inference API, BYOK endpoints and related interface will disappear, including for existing customers with active usage. For a production application, this is not a simple URL replacement. Identity, model catalogue, quotas, content filtering, observability and operational ownership all change.
The official GitHub announcement lists two test brownouts on 16 and 23 July. The first has passed; the second is the final controlled opportunity to discover processes without a fallback. GitHub points applications needing model access towards Microsoft Foundry and recommends GitHub Copilot for AI workflows directly within GitHub.
What will stop working
After 30 July, the following will be unavailable:
- the playground for manual prompt testing;
- the model catalogue and its interface;
- the inference API for chat completions and related operations;
- bring your own key (BYOK);
- endpoints and UI used by current customers.
The GitHub Models REST API documentation shows that applications could use the models.github.ai host, publisher/model_name identifiers, GitHub tokens with models:read, streaming and tool calls. Each element may have a different equivalent at the next provider. Replacing the base URL mechanically is insufficient.
Distinguish GitHub Models from GitHub Copilot
GitHub Models provided a model catalogue and inference platform for custom applications and experiments. GitHub Copilot assists software development in editors, CLI and GitHub workflows. If a backend application calls models.github.ai, moving to Copilot is generally not a one-to-one replacement.
Build a consumer inventory from code, secrets, proxies and billing. Search for:
models.github.aiand earlier Azure inference endpoints;- the
models:readscope in tokens, GitHub Apps and workflows; - model names containing a publisher prefix;
- client libraries and
GITHUB_TOKENorGITHUB_MODELS_*variables; - notebooks, evaluation scripts, demos and CI tests;
- BYOK tooling and organisation settings;
- dashboards and alerts tied to GitHub response codes.
Do not limit discovery to application repositories. The playground may have become an informal business process, while an analyst’s notebook may process production data. Record such dependencies in an AI model and system registry.
Why moving a model changes system behaviour
Even where a new endpoint implements an OpenAI-style API, output may differ. Models interpret system prompts, JSON Schema, tool ordering, temperature and limits differently. Providers can use different safety filters, error formats, stop reasons, tokenisation and retention policies.
A platform move changes at least seven contracts:
| Contract | What to compare |
|---|---|
| transport | base URL, TLS, proxy, streaming and timeout |
| authentication | PAT/GitHub App vs Entra ID or API key |
| model | name, version, context, modalities and region |
| payload | supported fields, tool calls and response format |
| security | content filters, privacy, retention and DLP |
| operations | quotas, retry, capacity, SLA and monitoring |
| quality | correctness, cost, latency and workflow regressions |
Without contract tests, an application can “work” while returning different JSON, skipping a tool call or truncating context. Treat the migration as a critical dependency change, not cosmetic maintenance.
Is Microsoft Foundry an automatic replacement
GitHub recommends Microsoft Foundry, but the organisation must still verify model availability, region, provider terms, filtering and cost. The Microsoft Foundry endpoints documentation describes model deployments, a common endpoint and keyless authentication through Microsoft Entra ID.
Foundry uses deployment names. A deployment combines model, version, capacity type, filtering configuration and rate limits. That name becomes an application contract, so avoid an ambiguous latest label. Record the model and version in both configuration and telemetry.
The documentation also warns that the beta Azure AI Inference SDK retires on 26 August 2026 and recommends the stable OpenAI/v1 API. Migrating from GitHub Models to a retiring SDK would create another urgent project one month later. Select an interface with a confirmed lifecycle.
A six-stage migration plan
Stage 1: inventory and ownership
For each client, record repository, environment, owner, model, average and peak traffic, data, tools, required region and outage impact. Classify production applications, experiments and resources to retire. An ownerless system should not be migrated automatically; it should trigger a retirement decision.
Stage 2: a new contract and adapter
Separate business code from the provider SDK. An internal interface should accept standardised messages, tools, deadline, budget and task identity. An adapter translates these into GitHub or Foundry requests. This enables dual-run and future provider changes without rewriting the application.
Where an organisation already operates an LLM gateway, the migration may become a routing change. Still verify that the gateway does not hide differences in errors and content filtering.
Stage 3: identity and secrets
GitHub Models used GitHub tokens. Foundry supports Entra ID and keys. Microsoft recommends keyless authentication for production because it enables RBAC and removes a long-lived application secret. Keys are simpler for initial testing, but documentation notes their broad resource access and rotation requirements.
Use managed identity or workload identity where possible. Grant a minimal inference-only role. Remove old PATs after the rollback observation window, with a firm revocation date. A Vault and KMS secret-management process supports the transition.
Stage 4: contract and evaluation testing
Contract tests cover response codes, streaming, timeout, retry, JSON, tool calls and rate limits. Evaluation tests assess meaning: facts, format, refusals, citations, safety and cost. Use a representative set from the LLM evaluation process.
Do not stop at “hello world”. Include long context, non-English characters, large JSON Schema tools, concurrent calls, stream cancellation, 429 and 5xx responses, missing permissions and invalid models. Confirm that retry cannot repeat an irreversible action.
Stage 5: dual-run, canary and rollback
Begin with shadow requests to the new endpoint using data approved for that destination. Compare output without presenting it to users. Then send a small percentage of reversible tasks to the new platform. Increase traffic only after quality, cost and error gates pass.
Rollback cannot depend on GitHub Models after 30 July. Prepare a second supported endpoint or graceful degradation such as a manual-work queue. Use the 23 July brownout as a continuity test, but do not wait until that date for the first check.
Stage 6: remove the old dependency
After stabilisation, remove endpoints, models:read tokens, BYOK configuration, unused SDKs, alerts and GitHub Models documentation. Update the runbook, data-flow diagram, DPIA or risk register where provider or region changes. Retain the comparison report and owner approval.
Security testing before cutover
The new endpoint should pass a minimum control set:
- confidential data is blocked or redacted under policy;
- tenants and projects are separated correctly;
- the workload identity cannot manage deployments;
- logs do not retain secrets, full prompts or personal data without a lawful need;
- tool calls use an allowlist and approval for write actions;
- prompt injection from a document cannot replace system rules;
- timeout and retry cannot duplicate transactions;
- model and content-filter versions are pinned;
- outbound traffic uses controlled DNS, proxy and TLS.
Our enterprise AI security guide contains the broader threat model. Migration is a good opportunity to remove earlier shortcuts rather than reproducing them with a new provider.
Observability after migration
Record task ID, provider, model deployment, prompt version, tokens, cost, latency, retry count, tool calls, approval decisions and outcome score. Do not make the provider dashboard your sole source. An independent trail is required to compare before and after migration.
Set SLOs for successful tasks, not merely HTTP availability. An endpoint may return 200 while the model emits an invalid format. Our OpenTelemetry guide for AI agents provides instrumentation patterns.
Alert on increases in 401/403, 429, 5xx, timeouts, cost per success, escalation rate and policy violations. Monitor unexpected model or content-filter changes separately.
Common migration failures
The first is changing the URL without evaluating the model. The second is placing a production API key in a repository variable despite workload identity being available. The third is selecting an SDK with its own imminent retirement. The fourth is ignoring tokenisation and cache-cost differences. The fifth is depending on the retiring service for rollback.
The sixth failure is overlooking “temporary” processes. A notebook or CI script may fail at a critical moment. The seventh is failing to update AI coding-agent supply-chain security when migration adds a new SDK, image and permissions.
Timeline to 30 July
| Date | Outcome |
|---|---|
| 18–20 July | complete inventory, owners and target selection |
| 21–22 July | adapter, identity, deployments and contract tests |
| 23 July | brownout verification and degradation test |
| 24–26 July | shadow traffic, evaluation and security testing |
| 27–28 July | production canary and observation |
| 29 July | complete cutover with independent rollback |
| 30 July | dependency, token and BYOK removal |
Do not schedule the primary cutover for the final day. Regional quota, model approval, RBAC and filtering issues may require time and decisions from other teams.
Test the shutdown before the deadline
Before 30 July, run a controlled exercise in which the old endpoint is unavailable to a selected application. Verify that traffic reaches the new deployment, the correct on-call team receives an alert and fallback does not bypass security policy. The exercise should cover throttling, timeouts, an invalid response format and regional unavailability, not just one successful demonstration request.
Record detection time, cutover time, lost jobs and the replay method. If recovery requires one person to change a secret manually, material operational risk remains. The goal is to prove that the application degrades in a controlled way after GitHub Models disappears, not merely that it works in an ideal integration test.
The decision today
Closure evidence should list former consumers, the new endpoint and model, test results, token-revocation date and rollback owner. Only that package demonstrates that the organisation did not leave a hidden dependency on the retiring service.
If logs, code or secrets show GitHub Models use, assign an owner and destination immediately. Treat 23 July as a chaos test, not the first warning. Migration is complete only when the application uses a supported endpoint, passes evaluations, has observability and retains no obsolete tokens.
Need to move enterprise AI applications safely? Contact BreachRoad to assess data flows, identities, gateway, tools, regression tests and fallback before GitHub Models is retired.
