GitHub Models dies July 30. Migrate before your AI app breaks
Prepare for the GitHub Models shutdown with a step-by-step migration guide covering Microsoft Foundry, GitHub Actions, structured outputs, quotas, and BYOK.
GitHub Models will stop working on Thursday, July 30, 2026. GitHub is removing the playground, model catalog, inference API, bring-your-own-key endpoints, and related interface for every customer, including organizations with active production usage.
This is a permanent shutdown, rather than a temporary outage or one-model deprecation. Any application, script, GitHub Action, evaluation job, or internal tool that still calls models.github.ai needs a replacement before the cutoff. A safe GitHub Models migration covers authentication, model identifiers, structured outputs, tool calls, evaluation tests, rate-limit handling, observability, costs, and fallbacks. Changing one endpoint will not cover those differences.
GitHub Models shutdown quick fix
Search every repository, deployment configuration, secret store, and CI workflow for GitHub Models references. Put the existing inference call behind one provider adapter, connect that adapter to Microsoft Foundry or another chosen provider, and run your production evaluation set against the replacement before changing live traffic. Keep both providers selectable through configuration until the new path passes schema, tool-call, load, and failure tests.
Do not wait for July 30 to discover whether the application survives an authentication error, an unavailable deployment, a different tool-call payload, or a slightly changed JSON response. Complete the smallest end-to-end migration first, then move the remaining workloads behind the same adapter.
What the GitHub Models shutdown means
GitHub closed Models to new customers on June 16. Existing customers were initially allowed to continue using the playground, API, and models while GitHub prepared the full retirement.
That first phase is ending. GitHub’s July 1 retirement notice says the following services disappear after July 30:
The GitHub Models inference API will no longer be available.
The playground and model catalog will be removed.
BYOK endpoints will stop working.
The retirement applies to every customer, including active existing users.
GitHub’s official changelog account confirms that GitHub Models, including its inference API and BYOK endpoints, ends July 30, 2026.
GitHub scheduled brownouts for July 16 and July 23, during which requests were expected to return errors before service was restored. Those dates were designed to expose unhandled dependencies before the final cutoff. If an application failed during either interruption, the failure path was a preview of what will happen permanently after July 30. At that point, recovery depends on your replacement provider and fallback design, because GitHub will not restore GitHub Models.
GitHub recommends Microsoft Foundry for applications that need model access and GitHub Copilot for AI workflows that live directly inside GitHub. Those options serve different use cases. Copilot may replace some repository, issue, pull-request, or CI workflows. It is not a general drop-in inference API for an application backend.
Microsoft’s current platform direction separates GitHub-based development from deployment and production management in Microsoft Foundry.
The operational risk extends beyond one hostname. A GitHub Models dependency can hide inside a shared library, prompt file, scheduled workflow, deployment secret, API gateway, or central configuration service. A migration is complete only when every reachable production path uses the replacement and the old token can be revoked without causing a failure.
Diagnose every dependency before changing anything
Start with a codebase search. The following commands use ripgrep, which is available on Windows, macOS, and Linux:
rg -n --hidden \
-g '!node_modules' \
-g '!dist' \
-g '!build' \
'models\.github\.ai|models\.inference\.ai\.azure\.com|actions/ai-inference|gh models|models:\s*read|openai/[A-Za-z0-9._-]+'
rg --files -g '*.prompt.yml' -g '*.prompt.yaml'The first search catches the current GitHub Models endpoint, the older Azure inference endpoint, GitHub Actions integrations, CLI commands, workflow permissions, and GitHub-style model IDs. The second finds prompt configurations stored in repositories.
A clean repository search does not prove the application is clear. The endpoint, token, model ID, or provider choice may be injected at runtime through environment variables, Terraform, Bicep, Kubernetes secrets, deployment settings, an API gateway, a feature-flag service, or a centralized configuration store.
Inspect runtime configuration for names such as:
GITHUB_TOKEN
GITHUB_PAT
GITHUB_MODELS_ENDPOINT
AZURE_AI_MODEL
MODEL_ENDPOINT
MODEL_API_KEY
LLM_BASE_URL
AI_PROVIDER
Search application logs for models.github.ai as well. Logs can reveal old code paths that remain reachable after the obvious source references have changed. They can also expose low-frequency jobs that run only nightly, weekly, or after a specific customer action.
Check deployment manifests, worker images, serverless functions, queue consumers, cron jobs, notebooks, internal CLI tools, test harnesses, and disaster-recovery environments. An endpoint can remain embedded in an old container image or copied into a second repository even after the main service is migrated.
Create a dependency inventory that maps each GitHub Models call to its task, owner, runtime, secret, model ID, schema, tools, expected latency, and fallback behavior. That inventory becomes the migration checklist and prevents teams from treating every call as interchangeable.
Choose the right replacement path
▪ Microsoft Foundry is the closest official migration
GitHub explicitly points application developers toward Microsoft Foundry. It is the most natural replacement when a team wants Azure identity, deployment controls, regional resources, centralized billing, and access to models from several providers.
Microsoft recommends moving from the older Azure AI Inference SDK to its OpenAI-compatible v1 path. Microsoft’s SDK migration guide documents API-key and Microsoft Entra ID authentication, a unified OpenAI client pattern, deployment names in the model parameter, and the /openai/v1/ endpoint format.
There is still meaningful migration work. Foundry exposes models through deployments, and applications address those deployments by name. GitHub Models used catalog IDs in the publisher/model_name format. Foundry also has its own quota scopes, regional availability, content filtering, monitoring, and identity configuration.
Foundry is the closest official route, but “closest” does not mean “identical.” Test every feature your application depends on instead of assuming OpenAI-compatible request shapes guarantee identical model or provider behavior.
Microsoft’s Foundry walkthrough covers the platform’s build, evaluation, safety, deployment, and post-deployment workflow.
▪ Direct provider APIs may preserve model-specific behavior
Use a direct model-provider API when the application depends heavily on provider-specific request parameters, caching, batch processing, model versions, reasoning controls, tool behavior, or response formats.
This removes the GitHub abstraction layer, but it creates an explicit integration with each provider. Teams using several providers should keep separate adapters and expose only the internal contract the application genuinely needs. A supposedly universal schema can erase useful features or hide incompatibilities until production.
Hosted APIs also introduce account, policy, billing, telemetry, and regional dependencies. Popular AI’s report on the Alibaba Claude Code ban and private-repository risk shows why hosted AI tooling should be treated as operational infrastructure with access rules, rather than as a permanent utility.
Choose a direct provider when feature fidelity matters more than a unified platform layer. Keep the provider replaceable through configuration, and maintain tests that distinguish a provider change from a model change.
More on the risks of hosted AI tools:
▪ A local API can provide an emergency fallback
A local OpenAI-compatible endpoint can keep bounded functions available when a hosted provider is unavailable, rate-limited, or no longer accessible. It is most realistic for summaries, classification, extraction, private document work, basic coding assistance, and other tasks with narrow contracts.
Foundry Local demonstrates how an application can run selected AI workloads locally instead of depending entirely on a hosted endpoint.
Local inference will not automatically match a hosted frontier model. Tool calling, JSON-schema compliance, long-context behavior, model quality, memory use, and throughput vary by model and server. Popular AI’s comparison of Ollama, LM Studio, and llama.cpp explains which local server fits API integrations and how their tradeoffs differ.
Model selection matters too. Popular AI’s GLM-5.2 analysis illustrates the gap between an open model’s promise and the hardware, quantization, runtime, and serving work needed to use it reliably. For coding-specific continuity, GGUF Loader Agentic Mode is one example of a local file-aware workflow that avoids a cloud account, while still requiring strict workspace boundaries and review.
Treat local inference as a tested fallback tier. Define which tasks can degrade to it, which tasks must fail closed, and which output contracts it can satisfy. A local model that has never passed the same fixtures as the hosted path is not a fallback. It is an untested second system.
Related articles:
Migrate authentication and the endpoint together
The retiring GitHub Models API accepts GitHub credentials. Its REST documentation describes bearer authentication using a token with Models read permission, a GitHub API-version header, and calls to endpoints such as:
https://models.github.ai/inference/chat/completionsA Foundry deployment does not accept that GitHub token. Depending on the resource and configuration, it uses a Foundry or Azure OpenAI API key, or Microsoft Entra ID.
For a basic API-key migration using Python and the OpenAI SDK:
import os
from openai import OpenAI
required = (
"AZURE_OPENAI_API_KEY",
"AZURE_OPENAI_BASE_URL",
"AZURE_OPENAI_DEPLOYMENT",
)
missing = [name for name in required if not os.getenv(name)]
if missing:
raise RuntimeError(f"Missing required environment variables: {', '.join(missing)}")
client = OpenAI(
api_key=os.environ["AZURE_OPENAI_API_KEY"],
base_url=os.environ["AZURE_OPENAI_BASE_URL"],
)
response = client.chat.completions.create(
model=os.environ["AZURE_OPENAI_DEPLOYMENT"],
messages=[
{
"role": "system",
"content": "Return a concise answer.",
},
{
"role": "user",
"content": "Reply with the word ready.",
},
],
)
content = response.choices[0].message.content
if not content:
raise RuntimeError("The model returned an empty response.")
print(content)Set AZURE_OPENAI_BASE_URL to the exact OpenAI v1 URL supplied for your resource, normally in this form:
https://<resource>.openai.azure.com/openai/v1/Install or update the client with:
python -m pip install --upgrade openaiThe critical changes belong together. Your GitHub PAT becomes a provider credential. The GitHub API-version header disappears when using Foundry’s OpenAI v1 path. The GitHub model ID becomes a Foundry deployment name. The base URL comes from the Foundry resource rather than GitHub.
Do not reuse the same secret name and silently replace its contents. Names such as GITHUB_TOKEN imply GitHub permissions and will confuse the next person debugging the deployment. Use provider-specific names, restrict each secret to the runtime that needs it, and rotate the retired credential after the old path is removed.
Community reports of 403 “No access to model” errors show how easily endpoint, token, permission, and model access can be confused. A token can be valid for one service and completely wrong for the service receiving it. A successful secret lookup therefore proves only that the secret exists. It does not prove the credential type, resource, role, endpoint, or deployment is correct.
Test authentication from the deployed runtime, rather than from a developer laptop alone. Network controls, managed identity, secret injection, proxy behavior, and private endpoints often differ between those environments.
Replace GitHub model IDs with deployment aliases
GitHub Models used identifiers such as openai/gpt-4.1. Its API documentation requires the publisher/model_name format.
Microsoft Foundry uses deployments to make models available. Each deployment has a name, model version, capacity configuration, filtering configuration, and rate-limit configuration.
That means this substitution is unsafe:
openai/gpt-4.1 -> gpt-4.1The correct Foundry value may be a deployment name chosen by your organization, such as:
support-summary-primaryKeep application-facing aliases separate from provider identifiers:
AI_TASK_SUMMARY_MODEL=summary-primary
AI_TASK_EXTRACTION_MODEL=extraction-primary
AI_TASK_FALLBACK_MODEL=summary-localResolve those aliases inside the provider adapter. The application should ask for a stable task alias, while configuration maps that alias to a provider, resource, region, deployment, and fallback. This lets you replace a model, deployment, region, or provider without editing prompts and business logic throughout the codebase.
A task alias also makes canary testing easier. You can route a small percentage of summary-primary traffic to a new deployment, compare contract and quality metrics, then promote or roll back without changing the caller.
This separation prevents a future model retirement from becoming another emergency search-and-replace operation. It also gives logs a stable business label even when the provider deployment changes.
Re-test structured outputs
GitHub Models supported plain text, JSON objects, and JSON-schema response formats through its response_format field. The retiring inference API also exposed structured JSON schemas.
Do not assume the replacement interprets the same schema identically. OpenAI-compatible syntax does not guarantee identical support for every JSON Schema keyword, refusal shape, truncation behavior, or validation promise.
Test required properties, nested objects, arrays, enums, nullable fields, additional properties, empty responses, truncated responses, and refusal cases. Include examples that are difficult for the model, rather than testing only a happy-path object with two strings.
Validate every response in your own code even when the provider claims strict schema support. A model returning syntactically valid JSON does not mean it returned the correct application contract. Your code should reject a missing customer ID, an invented enum value, a duplicate identifier, or a string where an array is required before that output reaches a database or downstream service.
Keep the validator independent from the provider SDK. Normalize the provider response into one internal representation, run the same validation rules against every provider, and log the sanitized reason for rejection. This makes hosted and local fallbacks easier to compare.
Decide what happens after validation fails. Some workloads can retry with a repair prompt. Others should fail closed because a guessed repair could create a wrong business action. Put a strict ceiling on repair attempts and record the original failure separately from any recovery attempt.
Re-test every tool call
GitHub Models supported function tools described through JSON Schema, together with tool_choice settings such as auto, required, and none.
A replacement model may choose tools differently. Its SDK may serialize arguments differently. It may emit several calls in one response, refuse to call a required tool, repeat a call after receiving the result, or place malformed JSON inside an otherwise valid tool-call object.
Test the whole loop in sequence. The model requests a tool. Your application validates the tool name and arguments. The tool executes. The result is returned using the replacement provider’s required message format. The model then produces a final response. Duplicate, unauthorized, or out-of-order calls are rejected.
This is especially important when tools create records, send messages, modify files, issue refunds, query private systems, or perform billable actions. Treat every model-generated tool request as untrusted input. Check authorization in application code, rather than assuming the model followed the system prompt.
Use idempotency keys for side-effecting tools when possible. Preserve the relationship between a provider tool-call ID and the application operation it triggered. A network retry or repeated model turn must not send the same message twice or create two customer records.
Changing providers without rerunning these tests can turn a harmless response-format difference into a real side effect. Tool success should be measured by the application outcome, not by whether the SDK parsed an object.
Move evaluation tests out of the retiring service
GitHub Models stored prompt settings in .prompt.yml files and provided comparisons and quantitative evaluations. GitHub’s Models documentation describes prompt configurations, side-by-side comparisons, evaluator scores, and repository-backed prompt files.
The files committed to a repository remain ordinary repository files. GitHub’s guide to storing prompts in repositories confirms that .prompt.yml and .prompt.yaml files can contain prompt templates, model parameters, test data, and evaluator definitions. The service that interprets, compares, and evaluates them is the dependency at risk.
Preserve the useful parts before July 30. Convert test inputs into a provider-neutral fixture format. Store expected schemas and hard invariants in the repository. Record current outputs for important cases. Keep scoring thresholds in code or CI configuration. Run the same corpus against the old and new providers while the old endpoint still responds.
GitHub’s documentation for evaluating AI models describes repeatable comparisons and the gh models eval command. Recreate the checks you rely on in a runner that does not depend on the retiring service.
Use deterministic checks for anything that can be checked deterministically. Validate JSON, required phrases, prohibited fields, numerical bounds, tool names, citations, and business rules directly. LLM-as-judge scoring can supplement those checks, but it should not be the only gate for an application contract.
Separate contract tests from preference tests. Contract tests answer whether the response is safe and usable. Preference tests compare qualities such as tone, concision, or style. A new provider does not need to imitate every sentence the old model produced. It needs to satisfy the application’s requirements with acceptable quality, latency, reliability, and cost.
Fix rate limits and retry behavior
Do not carry GitHub’s retry assumptions into the new provider.
GitHub Models users repeatedly asked how its model-specific limits worked, including in discussions about request and context limits and lower-than-expected paid limits. The replacement provider will have its own quota scope, burst behavior, concurrency rules, response headers, and billing consequences.
Microsoft says Foundry limits can be scoped by subscription, region, model, and deployment type. Its quota documentation recommends exponential backoff for HTTP 429 responses and honoring the Retry-After value.
Retry only failures that may succeed later, such as 429 responses, selected 5xx errors, and network timeouts. Do not repeatedly retry authentication failures, invalid schemas, unavailable deployment names, unsupported parameters, or malformed requests.
Add randomized jitter so a fleet of workers does not retry simultaneously. Put a hard ceiling on attempts, elapsed time, and total output tokens. An automatic retry should not quietly triple the cost of every request or keep a user waiting after the request has already exceeded its useful deadline.
Respect workload priority. A background summarization queue may wait and retry. An interactive request may need a faster fallback. A side-effecting tool flow may need to stop and ask for human review. One global retry policy rarely fits all three.
Load-test the new deployment with representative concurrency and token sizes. A request that succeeds one at a time can still fail under a burst because token-per-minute, request-per-minute, or deployment capacity limits are reached.
Improve logging before the cutover
A useful migration log should record the provider, configured deployment alias, actual provider deployment, region, SDK version, response status, request ID, latency, input tokens, output tokens, retry count, finish reason, structured-output validation result, and tool-call outcome.
Do not log API keys, authorization headers, full private prompts, customer documents, raw tool credentials, or unredacted provider error bodies. Apply the same redaction rules to success logs, error logs, traces, and support bundles.
Keep provider errors distinguishable in your application. Converting every 401, 403, 404, 429, and 500 response into “AI request failed” removes the information needed to fix the problem.
A practical error boundary might classify failures as:
Configuration failure.
Authentication failure.
Model or deployment unavailable.
Schema or tool-contract failure.
Rate limiting.
Provider outage.
Application timeout.
Content or policy rejection.
The user-facing response may remain simple. The operator-facing logs should preserve the status code, provider request ID, selected deployment, retry decision, and sanitized error category.
Add migration-specific metrics before the cutover. Track traffic by provider, validation-failure rate, tool-call failure rate, fallback activation, p50 and p95 latency, tokens by task, retry volume, and cost by deployment. Compare these measurements against the old path while both providers remain selectable.
A dashboard that shows only total successful requests can hide serious regressions. A provider may return HTTP 200 while producing invalid JSON, skipping a tool, or generating twice as many tokens.
Check GitHub Actions separately
Search workflow files for actions/ai-inference.
The official actions/ai-inference repository says the action calls the GitHub Models REST API by default. A workflow can therefore break even when the main application has already moved to another provider.
This official pre-retirement GitHub demo shows the Actions integration pattern that teams now need to audit and migrate.
The action also documents a copilot provider, which invokes GitHub Copilot CLI after it has been installed and authenticated on the runner. That can make sense for GitHub-native summarization, issue, pull-request, or repository tasks. The Copilot path has its own authentication, model naming, supported options, and tool permissions, so it still requires testing.
For application tests and production inference, a direct provider SDK or HTTP call is usually easier to reproduce outside GitHub Actions. It also avoids replacing one hidden platform dependency with another.
Review these workflow elements together: actions/ai-inference, gh models commands, models: read permissions, prompt-file references, GitHub PATs, provider secrets, cached evaluation output, expected response parsing, scheduled workflows, reusable workflows, and organization-level actions.
Removing the Models permission while leaving the action in place is not a migration. It produces a different failure message. Run the workflow with the old GitHub Models credential disabled and confirm the replacement path handles both success and failure cases.
Common GitHub Models migration failures
Error: 401 Unauthorized or 403 Forbidden
⚠ What it means: The application is probably sending the wrong credential type, using an invalid scope, calling the wrong endpoint, or reaching a deployment the identity cannot access.
✔ How to fix it: Confirm the hostname first. Then confirm that the secret belongs to that provider and resource. Test a minimal request using the same credential from the same runtime environment. For managed identity, verify the assigned role and token scope.
✔ How to prevent it: Use provider-specific environment-variable names, validate required configuration during startup, and include a deployment health check that does not expose secrets.
Error: 400 Unavailable model or 404 Not Found
⚠ What it means: The code may still be sending a GitHub catalog ID where the new service expects a deployment name. The deployment may also be missing from the selected region or resource.
✔ How to fix it: Copy the deployment name and endpoint from the provider console. Do not infer them from the public model name. Confirm capitalization and resource selection.
✔ How to prevent it: Resolve stable application aliases to provider-specific deployment names in one configuration layer, and validate every alias during deployment.
Error: the JSON parses but validation fails
⚠ What it means: The new model or API is not honoring the previous schema contract in the same way, or the schema includes keywords the replacement does not support as expected.
✔ How to fix it: Capture the sanitized response, validate it against the actual schema, and reduce the request to the smallest failing case. Check required fields, unsupported keywords, truncation, refusal output, and provider-specific wrappers.
✔ How to prevent it: Keep independent schema validation after every model response and run the same fixtures against every configured provider.
Error: the model describes a tool call but does not call the tool
⚠ What it means: The model, prompt, tool schema, SDK, or parser may not agree on the tool-use protocol.
✔ How to fix it: Inspect the raw response object before the SDK transforms it. Test one simple tool with a small schema and no optional arguments, then add complexity gradually.
✔ How to prevent it: Maintain provider-specific tool-call parsers behind a common internal interface, and reject textual claims that a tool ran when no validated call was executed.
Error: the application works locally but CI fails
⚠ What it means: The application code was migrated, but a GitHub Action still calls GitHub Models, expects models: read access, or lacks the replacement provider secret.
✔ How to fix it: Search .github/workflows for actions/ai-inference, gh models, prompt-file references, and the retired endpoint. Check reusable workflows and organization-level secrets too.
✔ How to prevent it: Include CI workflows, scheduled jobs, workers, and deployment automation in dependency inventories, rather than limiting the search to application source directories.
Error: requests succeed but costs rise sharply
⚠ What it means: The replacement may generate more output, perform more tool turns, retry more often, miss caching, or use a more expensive deployment.
✔ How to fix it: Compare token counts, retries, tool loops, latency, and fallback activity against the old baseline. Set output limits and per-request budgets.
✔ How to prevent it: Log usage by task and deployment, then alert on changes in tokens per successful business operation rather than looking only at the provider’s monthly total.
Confirm the GitHub Models migration
Before removing the old configuration, verify all of the following:
☐ No production request reaches models.github.ai.
☐ Authentication works from the deployed environment, not merely a developer laptop.
☐ Every configured model alias resolves to an available deployment.
☐ Structured outputs pass your own schema validator.
☐ Tool calls execute once, with validated arguments and correct result messages.
☐ Streaming and non-streaming paths both finish cleanly.
☐ A forced 429 honors retry guidance without creating a retry storm.
☐ Timeouts and selected provider errors activate the intended fallback.
☐ Authentication and malformed-request errors do not trigger pointless retries.
☐ GitHub Actions, scheduled jobs, workers, and background queues use the new path.
☐ Usage and costs appear in the replacement provider’s logs or billing dashboard.
☐ GitHub Models credentials can be revoked without breaking the application.
Run the final check with the old token disabled. A migration is not complete while an undocumented legacy path can still rescue it.
Repeat the check from every production region and deployment type that can serve traffic. Verify the result after a fresh deployment, rather than relying on a warm process that may still hold an old environment variable or cached credential.
If the replacement still fails
Reduce the application to one minimal inference request. Use one short message, no streaming, no tools, no schema, and a confirmed deployment name. Once that works, add structured output, streaming, tools, and production prompts one at a time.
Collect the provider request ID, UTC timestamp, sanitized request shape, endpoint hostname, region, deployment name, SDK and version, HTTP status, response headers, retry count, and a redacted error body.
Do not paste real credentials into GitHub issues, support tickets, screenshots, CI logs, or chat tools. Rotate a key immediately if it was exposed. Check traces and copied terminal history too, because credentials can survive after the original message is deleted.
When opening a support request, provide the smallest reproducible request rather than the whole application. Provider support can diagnose an endpoint, identity, deployment, or quota problem. It cannot easily diagnose several internal wrappers, two gateways, a job queue, and an exception handler that erased the original status code.
Keep a minimal health-check script outside the application framework. It should use the same endpoint and identity as production, but no customer data. That script helps separate provider access problems from application logic during an incident.
Privacy, security, and account risk
A migration changes more than infrastructure. It may change where prompts are processed, which region holds the deployment, how requests are logged, which employees can inspect usage, how long data is retained, what filtering applies, and which account can disable the application.
Review the replacement provider’s current terms and data documentation for your exact account type. Do not assume the same model name means the same data treatment through every host. Confirm retention, training use, abuse monitoring, regional processing, support access, encryption, and deletion controls for the actual service tier you will use.
For sensitive workloads, consider a hybrid design. Keep demanding tasks on the hosted model, but route basic extraction, classification, private drafts, or outage fallback through a local API. Popular AI’s guide to platform lock-in in AI-agent stacks explains why the endpoint, workflow format, runtime, policy layer, and billing path should remain replaceable after this emergency migration is finished.
Local inference reduces account dependency. It does not remove the need for authentication, network controls, input validation, sandboxing, patch review, and careful tool permissions. A local model can still expose private data through logs, modify the wrong files, or run dangerous commands if the surrounding application grants excessive access.
Document who owns the replacement account, subscription, resource, deployment, and emergency credentials. A technically sound migration can still fail if the only administrator leaves, billing is disabled, quota is assigned to the wrong region, or no one can rotate the key during an incident.
More on AI-agent lock-in:
Frequently asked questions
Will GitHub Models continue working for existing customers after July 30?
No. GitHub says the retirement applies to all customers, including existing organizations with active usage. The playground, catalog, inference API, BYOK endpoints, and related interface are being removed under the July 30 retirement plan.
Can GitHub Copilot replace the GitHub Models API?
Not as a general application inference endpoint. Copilot can replace some interactive or GitHub-native workflows. The
actions/ai-inferenceaction also supports a Copilot CLI provider for suitable CI jobs. Application backends should migrate to Microsoft Foundry, a direct model provider, or another tested inference service.
Can I migrate by changing the base URL?
Usually not. Authentication, model identifiers, deployments, parameters, structured-output behavior, tool-call messages, rate limits, logging, and error handling can all change. The Foundry SDK migration guidance shows that the endpoint, credential setup, API-version handling, client initialization, and deployment name all need attention.
Do .prompt.yml files disappear?
Files committed to a repository remain in that repository. The GitHub Models interface and service that run, compare, and evaluate them are being retired. Preserve the files, test data, evaluator rules, and expected outputs, then connect them to a replacement runner. GitHub’s prompt storage documentation explains what those files can contain.
Does bring your own key keep GitHub Models working?
No. GitHub’s retirement notice explicitly includes the BYOK endpoints. An OpenAI or Azure key stored inside GitHub Models does not preserve the GitHub Models integration after July 30. Move the application to the provider’s own endpoint and authentication path.
Finish the GitHub Models migration before July 30
Migrate the smallest complete path first: one production prompt, one replacement deployment, one schema validator, one tool-call loop, one evaluation fixture, and one forced failure. Once that path works, move the remaining tasks behind the same adapter.
Use Microsoft Foundry when you want the closest officially recommended replacement and Azure-aligned operational controls. Use a direct provider when model-specific feature fidelity matters more than a unified platform layer. Keep a local or secondary-provider fallback for bounded tasks where continuity matters more than maximum model quality.
The final test is simple and unforgiving. Disable the old GitHub Models credential, deploy the replacement configuration from scratch, and run the real production checks from the real production environment. Any hidden dependency that still reaches models.github.ai must be removed before July 30.
The two scheduled brownouts were warnings. The next failure is the shutdown.
Explore more from Popular AI:
Start here | Local AI | Fixes & guides | Builds & gear | Popular AI podcast
What worries you most about the GitHub Models shutdown: hidden dependencies, provider lock-in, or discovering a broken fallback after the cutoff?