GitHub Models已于2026年7月30日正式停止服务.
原有的模型Playground、模型目录、推理API和BYOK接口均不再可用。开发者接下来迁移到哪里，取决于原来的使用方式。
如果原来通过GitHub Models开发AI应用，可以优先迁移到Microsoft Foundry；
如果主要用于辅助写代码，可以改用GitHub Copilot；
如果希望直接控制模型、账单和API Key，也可以连接OpenAI、Anthropic、Gemini等模型提供商，或者部署本地模型。
一、GitHub Models具体停止了哪些服务？
截至2026年7月30日，GitHub Models已经停止提供：
模型Playground；
模型目录；
推理API；
Bring Your Own Key（BYOK）；
相关管理页面。
这次调整影响所有用户，包括此前仍有活跃调用的现有账号。GitHub Models与GitHub Copilot是两个独立产品，因此GitHub Models停止服务并不影响Copilot继续使用。
如果原来的程序仍在调用GitHub Models接口，应尽快更换API端点和认证信息，否则相关请求将无法继续执行。
二、应该迁移到哪里？先看结论
GitHub官方目前给出的两个主要方向也很明确：
需要继续访问 模型和 开发AI应用，转向Microsoft Foundry；
希望在GitHub中使用AI开发工作流，转向GitHub Copilot。
三、路线一：迁移到Microsoft Foundry
如果原来使用GitHub Models的推理API开发正式应用，Microsoft Foundry是最直接的迁移路线。
Foundry不仅提供模型目录，还支持：
模型部署；
按Token计费；
批处理和预配吞吐量；
自定义速率限制；
内容安全过滤；
Microsoft Entra ID无密钥认证；
Azure权限和账单管理。
微软的迁移文档说明，对于使用兼容调用方式的项目，部署好Foundry模型后，主要需要替换新的密钥和端点，原有业务代码通常不需要大规模重写。迁移后的用量会根据部署类型计入Azure订阅。
适合哪些开发者？
已经准备将AI应用投入生产；
需要多模型目录；
需要企业权限和审计；
需要稳定配额；
已经在使用Azure；
希望统一管理模型、数据库和云服务。
基本迁移流程
创建或确认Azure订阅↓进入Microsoft Foundry↓创建项目和模型资源↓部署需要使用的模型↓获取新端点和认证信息↓替换原GitHub Models配置↓测试响应、Token和速率限制
需要注意，GitHub Models以前已经预先配置好可用模型，而Foundry需要开发者先选择并部署模型，之后才能在代码中调用。不同区域能够部署的模型也可能不同。
四、路线二：迁移到GitHub Copilot
如果原来使用GitHub Models的主要目的，是比较模型、理解代码、修改仓库或辅助开发，那么不一定需要迁移到一个新的模型API平台。
这种情况更适合直接使用GitHub Copilot。
目前Copilot可以在GitHub、IDE、CLI和桌面应用中完成：
阅读项目代码；
修改多个文件；
处理Issue；
运行终端命令；
编写和检查代码；
进行Agent开发任务；
在不同模型之间切换。
Copilot App已经向所有Copilot套餐开放，包括Copilot Free。没有Copilot订阅的用户，也可以通过BYOK连接自己的模型提供商。
GitHub Models与Copilot的区别
GitHub Models→ 提供模型目录和推理API→ 更接近通用模型试验平台GitHub Copilot→ 直接理解代码仓库→ 在IDE和终端中完成开发任务→ 更接近日常编程Agent
如果项目并不需要自行开发AI接口，只是希望让AI帮助写代码，迁移到Copilot通常更简单。
五、路线三：通过BYOK连接自己的模型
GitHub Models停止后，BYOK功能并没有完全消失，而是被整合到了Copilot产品中。
Copilot App目前可以连接：
OpenAI；
Anthropic；
Azure OpenAI；
Microsoft Foundry；
Ollama；
LM Studio；
OpenAI兼容接口。
添加模型提供商后，可以在模型选择器中直接选择对应模型。API Key保存在本地操作系统的密钥链中。
Copilot CLI同样支持连接Azure OpenAI、Anthropic及其他OpenAI兼容端点，也支持Ollama、vLLM和Foundry Local等本地模型。使用自己的提供商时，可以继续使用Copilot的终端Agent体验，同时由模型提供商直接计算调用费用。
BYOK更适合哪些情况？
已经有OpenAI或Anthropic API账号；
希望自己选择模型；
需要按Token控制费用；
不想把模型调用全部绑定在Copilot套餐中；
需要使用公司自己的云账户；
需要连接内部模型网关。
使用BYOK后，GitHub只负责提供开发交互界面，模型账单、配额、地区和数据规则由实际模型服务商决定。
六、路线四：直接迁移到模型厂商API
如果原来的项目只是通过GitHub Models调用某个固定模型，也可以跳过中间平台，直接使用模型厂商API。
例如：
OpenAI API；
Anthropic API；
Gemini API；
Azure OpenAI；
其他OpenAI兼容服务。
Gemini API目前支持Python、JavaScript和REST调用，也提供文本、多模态、工具调用和Agent等能力。
直接连接模型厂商的优点是：
API文档更新更及时；
可以第一时间使用新模型；
价格和Token账单更直接；
不依赖GitHub的中间接口；
更容易排查模型侧报错。
缺点也很明显：
不同厂商的SDK和字段不完全一致；
需要分别管理API Key；
账单分散；
切换模型时可能需要修改代码。
如果未来可能频繁切换模型，建议在项目中增加一层统一接口，不要把某一家厂商的请求格式写死在业务代码里。
七、路线五：迁移到其他云模型平台
如果项目本来就运行在其他云平台，也没有必要为了接替GitHub Models专门迁移到Azure。
Amazon Bedrock
Bedrock可以通过控制台和API访问多家基础模型，并支持OpenAI兼容API、Anthropic Messages API以及AWS自己的Converse API。
更适合：
已经使用AWS；
需要IAM权限管理；
需要在AWS内部统一结算；
希望同时使用多家模型。
Gemini API或Google Cloud
如果应用大量使用Google Cloud、Firebase或Google生态，可以直接使用Gemini API，减少跨云管理成本。
选择云平台时，不要只比较单次Token价格，还要考虑：
项目部署在哪个云；
数据所在区域；
网络延迟；
权限体系；
日志和监控；
团队是否熟悉该平台；
账单是否容易统一。
八、本地模型适合替代GitHub Models吗？
部分场景可以，但不能简单理解成完全替代。
Copilot CLI现在支持Ollama、vLLM和Foundry Local等本地模型，还可以在离线模式下关闭GitHub遥测，只与本地配置的模型通信。
本地模型适合：
代码不能上传到外部平台；
网络环境受限；
需要离线运行；
调用量较大且硬件充足；
可以接受自行维护模型。
但开发者需要自己承担：
GPU或服务器成本；
模型更新；
推理速度；
并发管理；
安全维护；
上下文和工具调用兼容性。
个人开发者如果只是偶尔调用模型，云API通常比专门部署GPU服务器更省事。
九、迁移时不要只换API地址
一次完整迁移，至少要检查以下内容：
1. 模型是否仍然可用
同名模型在不同平台上的版本、上下文长度和区域可能不同。
2. 请求参数是否兼容
重点检查：
model；max_tokens或max_output_tokens；Tool Calling；
JSON结构化输出；
流式响应；
图片和文件输入。
3. 重新设置API Key
不要继续沿用已经失效的GitHub Models Token。
新的密钥应放在环境变量或密钥管理服务中，不要提交到Git仓库。
4. 重新测试费用
即使模型名称相同，不同平台的输入、输出、缓存、工具和批处理价格也可能不同。
5. 增加备用模型
不要再把应用绑定到单一模型接口。
可以预留：
主模型不可用↓切换同平台备用模型↓切换第二模型提供商↓返回降级结果
6. 重新设置预算预警
迁移后，费用可能从GitHub账单转移到Azure、OpenAI、Anthropic或其他云平台，需要重新设置：
月度预算；
费用提醒；
Token上限；
API Key权限；
自动停机规则。
十、迁移后的付款和账单怎么管理？
GitHub Models停止后，最大的变化之一，是账单可能不再集中在GitHub。
例如，一个开发者可能同时产生：
GitHub Copilot订阅费Microsoft Foundry模型费用OpenAI或Anthropic API费用其他SaaS工具订阅费
如果全部绑定在同一张付款卡上，后期不容易判断某笔扣款属于哪个项目。
个人开发者或小团队可以按用途拆分：
在目标平台支持虚拟卡的前提下，也可以按照平台或项目分配不同卡片。
例如：
GitHub及开发工具 → 一张卡模型API费用 → 一张卡测试项目 → 一张低额度卡正式业务 → 独立付款卡
这样做的好处是：
某个平台费用异常时更容易定位； 可以分别设置卡片额度； 项目停止后可以单独停用对应卡片； 避免一张卡失效影响全部开发工具； 月底进行费用归集时更加清楚。
如果同时使用多个海外AI工具和开发者服务，可以了解MXK8虚拟卡的项目分卡和海外软件订阅场景。开卡前建议先说明目标平台、账号地区、结算币种、预计消费金额以及是否需要自动续费，由服务人员确认具体适用范围。
需要注意，虚拟卡只是付款和账单管理工具，不能替代模型平台自身的Token限额、预算预警和API权限控制。最终是否能够付款成功，也会受到平台规则、卡片类型、发卡地区和支付验证方式影响。
十一、个人开发者怎么选？
可以直接按照这个判断：
只想让AI辅助写代码→ GitHub Copilot正在开发需要上线的AI应用→ Microsoft Foundry或现有云平台只使用一个固定模型→ 直接连接模型厂商API需要在多个模型之间切换→ Copilot BYOK或统一模型网关代码不能发送到外部平台→ 本地模型已经深度使用AWS或Google Cloud→ 优先使用对应云模型服务
不要为了追求“平台最多”同时开通所有服务。先根据业务选择一个主平台，再准备一个备用接口，通常已经足够。
十二、总结
GitHub Models停止服务后，没有一个适合所有开发者的统一替代方案。
更合理的选择是：
GitHub内的编程任务迁移到Copilot；
生产级AI应用迁移到Microsoft Foundry或现有云平台；
固定模型调用直接连接模型厂商API；
多模型开发使用BYOK或统一网关；
高隐私场景考虑本地模型。
迁移时不要只修改API端点，还要重新检查模型版本、请求参数、密钥管理、费用预算和备用模型。
从长期来看，最重要的不是找到一个与GitHub Models界面完全相同的平台，而是让自己的应用不再依赖某一个模型、某一个端点或某一种付款方式。这样下一次模型下线或平台调整时，迁移成本才不会再次失控。
关于我们
