Cursor 的 BYOK，算不上模型容灾

76 天。

这是从 OpenAI 公告 发布，到它建议停止向 Cursor 直接提供模型之间留下的时间。拟定日期是 2026 年 11 月 12 日，最终日期还要等双方确认，Cursor 也可能提前结束访问。

很多人看到这条消息，第一反应大概是，问题不大，往 Cursor 里塞一枚 OpenAI API key 就行。

好家伙，密钥能填进去，模型也能回话，看起来确实像修好了。

可 OpenAI 刚更新的迁移说明 把边界写得很直白。自带密钥只覆盖受支持的本地 Chat 和 Agent，不覆盖 Tab 自动补全，不覆盖 Auto 路由，不覆盖 Cloud 与 Background Agents，也不覆盖 Automations、Cursor CLI、Cursor API 和 SDK。

聊天框活着，不等于你的 AI 编程工作流活着。

这正是我觉得这次事件最值得程序员盯住的地方。两家公司为什么分手，当然有热闹可看。OpenAI 在公告里把原因归于服务条款和收购后的合规信任，Cursor 还没有在同一页面给出完整回应。但对真正拿 Cursor 干活的团队来说，更急的不是判断谁占理，而是看清自己租来的能力到底挂在哪条线上。

Cursor 的 BYOK 是一条备用请求通道，不是一套完整的模型容灾。

BYOK 只把一层接了回来

BYOK 是 Bring Your Own Key，也就是用自己的模型供应商密钥结算请求。这个设计很实用，主平台不再替你采购模型，你拿自己的 OpenAI 账户继续调用，账单直接落到 OpenAI API。

问题在于，一个代码 Agent 从来不只是一条模型请求。

你在 Cursor 里按下发送，前后还夹着上下文检索、提示词组装、工具定义、终端执行、文件补丁、模型路由、失败重试、后台任务和结果展示。模型只是中间那颗发动机，周围那层让它能在仓库里干活的脚手架，仍然属于 Cursor。

Cursor 的自有密钥文档 也没有藏着掖着。OpenAI BYOK 当前只支持标准的非推理聊天模型，Tab 补全继续使用 Cursor 内置模型。密钥不会被 Cursor 持久化，但会随请求经过 Cursor 后端，因为最终提示词仍要在那里组装。

这两句放在一起，味道就出来了。

你换了付费账户，却没有把整条执行链搬走。你仍然依赖 Cursor 如何选上下文、如何描述工具、如何拼 prompt、如何承接模型输出。某个模型在 OpenAI 原生 API 里支持一项新能力，不代表它当天就能在 Cursor 的 BYOK 路径里原样出现。

甚至连最容易被忽略的 Tab 都不在这条退路里。很多程序员一天里真正高频使用的不是打开 Agent 聊天框，而是补全下一行、根据当前文件续写函数、在光标位置生成一个小改动。BYOK 把 Chat 接回来，Tab 还是另一条供应链。

厉害了，一枚 API key 看起来像总闸，实际只管了配电箱里的一路。

密钥能接回本地 Chat 和部分 Agent，不会自动接回 Tab、Auto 与云端任务。

这不是说 BYOK 没用。它非常适合救本地聊天和部分 Agent 任务，也能让团队把模型费用从 Cursor 订阅里拆出来。可如果内部文档写着「OpenAI 不可用时切 BYOK」，这句话的信息量还不够。至少要继续写清楚，哪些入口切得过去，哪些功能会降级，哪些任务会换成另一个模型，谁来承担新增 API 费用。

三条退路其实是三套产品

OpenAI 给出的迁移页列了三条路，自带 API key、安装 Codex IDE 扩展，或者接入 Azure、Amazon Bedrock、OpenRouter、Vercel AI Gateway 一类兼容网关。

乍看都是继续在 Cursor 里用 OpenAI 模型，工程上却不是一回事。

BYOK 保留 Cursor 的本地 Chat 和 Agent 外壳，模型账单改走你自己的 OpenAI API 账户。对现有使用习惯改动最小，但覆盖面有限，模型可用性还受 Cursor 适配范围约束。

Codex IDE 扩展更像在 Cursor 这栋楼里另租一间办公室。编辑器还是 Cursor，Agent 面板、认证、会话和执行体验换成 Codex。它不依赖 Cursor 模型选择器里的 OpenAI 合作，也不会把 Cursor 的 Tab、Auto 或 Cloud Agent 自动变成 Codex。两个 Agent 可以住在同一个 IDE，状态却不是同一套。

网关路线把模型入口再抽象一层。团队可以统一密钥、限额、日志和供应商，也可能在一个端点后面切 Azure 或其他托管渠道。听着有点子牛逼，尤其适合已经有模型控制面的公司。但每加一层网关，就多一份模型命名、参数兼容、流式协议、错误码、地区与数据政策的差异。

三条路没有谁天然最好。关键是别把它们写成同一个 fallback。

如果团队主要靠本地 Chat 改小段代码，BYOK 也许就够了。如果大家依赖 Cursor Cloud Agents 跑长任务，BYOK 根本接不住原来的入口。如果公司需要集中审计，个人把密钥贴进设置页反而可能违反内部制度。Cursor 的企业模型管理文档 明确允许管理员禁用个人 BYOK，并要求最严格的模型基线放在团队级设置里。

很多朋友可能不知道，模型切换还会改数据合同。

Cursor 文档写得很明确，使用自有密钥时，Cursor 的零数据保留承诺不再适用，数据处理改为遵循所选供应商的政策。企业隐私与数据驻留说明 还补了一刀，BYOK 不支持仅限美国的数据驻留，通过自定义地址或第三方网关访问时，数据区域跟着网关和模型走。

于是同一段代码，在内置模型、个人 OpenAI key 和第三方网关之间切换，看到的界面可能差不多，背后的账单归属、日志位置、保留策略和合规责任已经换了几遍。

这块需要注意一下，模型容灾不是把 200 响应救回来。真正要救的是任务能力、数据承诺和可追账性。

三条退路都能到达模型，却会经过不同的工具、成本、隐私与证据检查点。

迁移验收别只测聊天框

最省事的测试，是在 Cursor 里问一句「给我写个快速排序」，看到代码出来就宣布迁移完成。

这测试基本没用。

快速排序不需要读你的仓库，不需要调用终端，不需要跨文件修改，也不需要在后台跑半小时。它只能证明一条最短请求链还能返回文本，证明不了团队每天真正依赖的东西。

我自己的建议可能不成熟，但可以把团队最近两周真实出现过的任务抽十来个，按入口分开跑。不要编一套看起来很专业的 benchmark，直接拿能自动验收的工作。修一个带单测的 bug，跨三个文件改接口，生成迁移脚本，执行格式化与类型检查，跑一次需要 MCP 的内部查询，再放一个长任务到后台。

每个任务至少记六件事，入口、模型、工具、完成条件、数据路径和费用账户。可以在仓库里放一份很小的迁移清单。

workflow: repair-api-regression
entry: cursor-local-agent
primary: cursor-managed-openai
fallback: openai-byok
required-tools: [terminal, patch, tests]
pass: unit-tests-and-typecheck
data-policy: provider-reviewed
billing-owner: ai-platform-team

别嫌它朴素。真到切换那天，团队最缺的不是一篇长分析，而是有人能回答「这个工作流走哪条路」「失败后退到哪里」「费用算谁的」。

然后专门测差异，不要只测成功。Auto 模式是否还能选到同一类模型，工具调用参数有没有变化，长输出会不会被截断，终端审批是否还在，缓存命中与单次费用差多少，原来在 Cloud Agent 里跑的任务有没有本地替代。

如果改用 Codex IDE 扩展，还要检查规则文件、MCP 配置、审批习惯和会话状态能不能迁。两个 Agent 都能修改代码，不代表它们会读取同一份项目约束，也不代表工具权限的默认值一样。把这些差异留到 11 月才发现，画面大概会很美。

如果走网关，别只跑 happy path。故意填错模型名，压一次速率限制，让上游返回超时，再看网关有没有把原始请求 ID、供应商错误和重试次数留下来。没有这些证据，所谓多供应商切换很容易变成多一层猜谜。

说真的，这套验收不只是为了 OpenAI 和 Cursor。今天变的是一份模型合同，明天也可能是价格、地区、额度、数据政策或模型下线。只要团队把编码工作流建在外部模型上，这类变化还会再来。

收购新闻终于落到了配置文件里

Cursor 在 8 月 14 日的公开公告 里说，加入 SpaceX 后会获得巨量 GPU 算力，训练更强、成本更低的模型。两周后，OpenAI 启动合同退出。前一条新闻讲的是算力和自研模型，后一条新闻讲的是外部供应商离场。

把它们连起来看，最直观的变化不是谁赢谁输，而是 AI 编程产品正在长成一整套垂直技术栈。编辑器、模型、算力、Agent 运行环境、账单与数据政策越来越难拆开。

对厂商，这样做有速度。对开发者，这样做有迁移成本。

我始终觉得，程序员不需要因为每次商业变化就换工具。Cursor 好用就继续用，Codex、Claude Code 或其他工具能解决问题也照常用。真正要守住的是那一点工程上的清醒，别把「能选择多个模型」误认成「已经具备模型容灾」。

前者是下拉框里有很多名字。

后者是某个名字消失后，你的任务还能完成，数据边界没有偷偷变化，账单有人认领，失败也能查到证据。

OpenAI 留给 Cursor 的拟定窗口还有 76 天。对个人用户，换一枚 key 可能十分钟。对把 Tab、Auto、Cloud Agent、团队权限和审计都压在同一套产品上的公司，76 天一点都不长。

模型是租来的，接口也是租来的。

真正该留在自己手里的，是工作流和验收。