本地跑还是云端跑：Codex 选型先看模型可用性

2026-08-09

Codex（OpenAI Codex）铺了六个使用面：ChatGPT 桌面应用、Codex CLI、Codex IDE 扩展、Codex cloud、ChatGPT Web、Codex Remote。第一次配环境的人常常在这里卡住，然后去搜”哪个更好用”。这个问法本身就跑偏了——真正会把你堵死的不是好不好用，而是几条硬约束：你想用的模型在云端根本不存在、你所在的机器批不下管理员权限、你的会话需不需要换台电脑接着看。

这些约束里，模型可用性是最容易被忽略、代价又最大的一条。我把它排在决策路径的第一位。

第一个岔口：你锚定的模型，云端有没有

官方《Models》文档页（核对日 2026-08-09）给的 GPT-5.6 三档里，有两条限制是直接决定选型的：

模型名	官方定位原文	可用面
`gpt-5.6-sol`	”Flagship GPT-5.6 model with the strongest capability for complex coding, computer use, research, and cybersecurity.”	全平台，含 API
`gpt-5.6-terra`	”Balanced GPT-5.6 model for everyday work, with performance competitive with GPT-5.5 at a lower cost.”	Codex cloud 不可用
`gpt-5.6-luna`	”Fast and affordable GPT-5.6 model that delivers strong capability at the lowest cost in the family.”	云端任务不可用

只引这一张表的这两行，是因为它们对本篇的结论有一票否决的分量：如果你的日常工作流是靠 terra 或 luna 的成本优势撑起来的，云端这条路对你就是关着的。

还得再叠一条更反直觉的：Codex cloud 自动选择模型，不是你在本地 config 里写了什么、云端就跟着用什么。也就是说，“我本地设的是 luna，那云端也会省着跑”这个想法从头到尾都不成立。想让任务在云端跑，选型能落的地方只有 sol；gpt-5.6-sol 同时也是符合条件客户的 Codex cloud 代码评审与 QA 的驱动模型。

还有一款 gpt-5.3-codex-spark，官方描述是 “Text-only research preview model optimized for near-instant, real-time coding iteration. Available to ChatGPT Pro users.”，它只出现在桌面应用与 CLI 两个面，且限 ChatGPT Pro。它是研究预览，别把它当稳定选项排进方案。

所以第一个岔口的判断很简单：先看你打算长期用哪个模型，再决定跑在哪。反过来先定跑在哪、再挑模型，多半要返工。

顺带说一件跟”跑在哪”绑在一起的时效事：官方原文写着 “GPT-5.4 and GPT-5.4 mini retire from Codex on August 31, 2026.”，迁移映射是 gpt-5.4 → gpt-5.6-terra、gpt-5.4-mini → gpt-5.6-luna。而官方点名要一起改的地方有五处：workspace 默认模型、保存的模型设置、managed config、自定义 agent、计划任务。只在交互界面里改当前会话是不够的——这五处任何一处还写着旧名字，8 月 31 日之后都会出问题（以官方最新说明为准）。注意迁移映射的目标恰恰是 terra 和 luna 这两个云端不可用的模型，所以”迁移完了顺手把活丢云端”这条路要单独再想一遍。

第二个岔口：谁改文件、改在哪台机器上

官方对本地与云端的界线说得很直白：本地工作流在你自己的设备上运行，云端任务在 OpenAI 托管的环境里运行。

本地这边，改文件的边界由沙箱模式决定。官方对默认模式 workspace-write 的原话是 “The agent can read files, edit within the workspace, and run routine local commands inside that boundary.”。本机在 codex-cli 0.147.0（Windows 11）上执行 codex -s bogus-mode，报错会把三个合法取值原样列出来：

error: invalid value 'bogus-mode' for '--sandbox <SANDBOX_MODE>'
  [possible values: read-only, workspace-write, danger-full-access]

这三个值就是本地侧”允许它动到什么程度”的全部选项。

云端那边的做法（官方文档口径，我们没有实测）是：任务在隔离的云端环境里跑，可以并行，不占用你本地机器；任务结束后你去看摘要与 diff，可以追加后续要求，也可以直接开 PR。发起入口是 web、GitHub、Linear、Slack。上手要走三步：用 ChatGPT 账号登录 Codex、连接 GitHub 账号并选择可访问的仓库、打开环境设置为仓库创建一个环境——环境（environments）是按仓库配依赖、工具、变量和初始化步骤的，这一步没配好，云端跑起来是空的。

这里就出现了一条对选型很关键的分界：云端改的不是你硬盘上的文件。 如果你要的是”改完我立刻能在本地跑起来看效果”，那中间必然多一步搬运。CLI 侧确实给了这一步：本机在 codex-cli 0.147.0（Windows 11）上看 codex cloud --help，它带着 [EXPERIMENTAL] 标签，子命令有 exec（不启动 TUI 直接提交云端任务）、status、list、apply（把某个云端任务的 diff 应用到本地）、diff（显示统一 diff）；另有顶层 codex apply <TASK_ID>，官方说明是把 agent 产生的最新 diff 以 git apply 的方式打到本地工作树。

但 codex cloud 在这个版本上是 EXPERIMENTAL，不是稳定功能。要不要把它放进每天都要跑的流程里，这本身就是一个需要你自己拍板的风险决定。

第三个岔口：你有没有管理员权限

这一条在公司电脑上经常是真正的决定因素，中文用户尤其容易撞上。

Windows 侧的沙箱是原生实现，在 PowerShell 中运行，强制 “bounded filesystem and network permissions”，不需要 WSL、不需要虚拟机。它有两种模式：

模式	特征
`elevated`（官方标注为首选）	用专用的低权限沙箱用户；文件系统权限边界 + 防火墙规则；需要管理员批准的初始化设置
`unelevated`（回退）	用从当前用户派生的受限 Windows token 运行命令；基于 ACL 的文件系统边界；用环境级离线控制替代防火墙规则；官方明说保护更弱

对应配置键是 windows.sandbox，取值 "unelevated" 或 "elevated"。另一条硬性要求是 winget 必须可用。版本支持上，Windows 11 是推荐，较新的 Windows 10（v1809+）是尽力而为（best effort），更老的 Windows 10 不推荐。

于是判断路径就出来了：

能拿到管理员批准 → 本地走 elevated，是官方首选。
拿不到管理员批准 → 你有两条路：一是回退 unelevated（官方自己写了保护更弱，别指望它等价），二是把需要真正执行命令的活儿挪到云端隔离环境里去。“没有管理员权限”是少数几个能直接把天平推向云端的处境。
初始化直接失败 → 官方给的排查顺序是：重启 Codex、重试 elevated 初始化、需要时回退到 unelevated、发送诊断，日志在 CODEX_HOME/.sandbox/sandbox.log。其中错误 1385 的官方原话是 “Windows is denying the logon type the sandbox user needs.”，意思是沙箱用户已经建好了，但策略不允许它执行命令。这一条的解法官方只给了上面四步，超出这四步的招我不写，也劝你别随便照搬网上的注册表改法。

本机在 codex-cli 0.147.0（Windows 11）上，config.toml 里是 [windows] sandbox = "elevated"，codex doctor 的 sandbox 那行显示 restricted fs + restricted network · approval OnRequest。想确认自己这台机器现在到底是什么状态，跑一次 codex doctor --summary 看这一行就够了，比翻配置文件靠谱。

顺便提醒一句：macOS 用的是系统内置的 Seatbelt，Linux / WSL2 需要用包管理器装 bubblewrap（bwrap）。这是三套完全不同的机制，Linux 上”先查 bwrap 装没装”的排查步骤，搬到 Windows 上一点用都没有。

第四个岔口：预算，以及云端只能用 sol 的成本含义

个人档位（ChatGPT 官方定价页，2026-08-09 核对，以官方为准）：

档位	价格（官方原文）	与本篇相关的点
Plus	$20/month	Codex 覆盖 web、CLI、IDE、iOS；含云端集成（代码评审、Slack）；GPT-5.6 模型家族访问
Pro	Starting at $100/month	$100/mo 档为 5 倍上限，$200/mo 档为 20 倍上限；含 `gpt-5.3-codex-spark` 研究预览

另外官方公告口径里有一个限时活动：限时内 Codex 包含在 ChatGPT Free 与 Go 中，并且 Plus、Pro、Business、Enterprise、Edu 的速率上限翻倍，更高上限在 app、CLI、IDE、cloud 四个面上都适用。这是限时活动，不是常规权益，做长期方案时别按它算。

用量口径也要看清楚：计量单位是 messages（消息数），窗口是 5 小时滚动窗口。Plus 是 10–2,000 messages / 5h，Pro 是 50–40,000 messages / 5h，区间跨度这么大是因为它随模型（Pro 还随档位）变化。官方给的是一个区间，不是承诺给你的数量，别拿上限去做容量规划。

再把第一个岔口的结论叠回来。官方积分单价表（每 100 万 token）里，Sol 的 Input 是 125、Output 是 750；Luna 的 Input 是 5、Output 是 30。三档之间输入是 25 倍差距，输出同样是 25 倍。这意味着：因为云端只能落到 sol，“把活丢云端”在单价维度上不是省一点，而是跨了一个量级。 同一张表还能读出另外两条：缓存命中的输入单价是未缓存的十分之一（125→12.5、50→5、5→0.5），三档都是这个比例；输出比输入贵 6 倍（750/125、300/50、30/5），三档也都是 6 倍。所以”让上下文可复用""让它少输出废话”这两件事在账单上是直接可见的。至于 credits 换算成钱是多少、一个月要花多少，官方文档没给这层关系，我不推算。

第五个岔口：这个会话你要不要换台设备接着看

这一条容易被当成小事，实际上很多人是被它逼着换面的。

官方口径：桌面应用把 Chat 与 Work 会话放在同一个 ChatGPT 视图里；云端 Work 会话跨 web、移动端、桌面端同步，本地 Work 会话只留在你的电脑上。

翻译成决策：如果你需要下班路上在手机上看进度、或者换台机器接着推，云端是唯一符合这个描述的选项；如果你的诉求是”这些东西别离开我这台机器”，那就锁死本地。本机在 codex-cli 0.147.0（Windows 11）上，~/.codex/ 目录里能看到 sessions/（按年份分子目录）与 archived_sessions/，这就是本地会话落盘的地方。顺带一个运维现实：本机 codex doctor 的 Notes 里提示 rollouts 占 3.07 GB，本地长期跑是要占硬盘的。

把五个岔口串成一条路

按这个顺序问自己，基本不会绕：

我要用的模型云端有吗？ 锚定 terra / luna → 云端出局，走本地。锚定 sol → 两边都行，继续往下问。用 spark → 只有桌面应用和 CLI，且限 ChatGPT Pro。
改完的文件要不要立刻落到我的硬盘上？ 要 → 本地。可以接受先看 diff 再搬 → 云端，搬运靠 codex cloud apply 或 codex apply <TASK_ID>（前者在 0.147.0 上标 EXPERIMENTAL）。
我有没有管理员权限？ 有 → 本地 elevated。没有 → 要么 unelevated（保护更弱），要么把执行类任务推到云端。
预算能不能扛住”云端只能用 sol”？ 扛不住 → 本地用便宜档。扛得住 → 云端并行的价值才谈得上。
会话要不要跨设备？ 要 → 云端。不要 → 本地。

官方在快速上手里的原始建议是：桌面应用（推荐）用于项目、本地文件和长时间任务；Web 用于不受打扰的云端复杂任务、免安装；终端与编辑器场景建议 Codex CLI 或 Codex IDE 扩展。这条建议和上面五问不冲突——它讲的是”你习惯在哪工作”，五问讲的是”哪些路根本走不通”。走不通的先排掉，剩下的再按习惯挑。

三个容易判错的地方

第一，别把本地的模型设置当成云端的模型设置。 云端自动选模型这一条，比任何配置技巧都优先。

第二，CLI 和桌面应用可能不是同一个版本。 官方排查页明确点了这个现象：功能在 CLI 有、桌面应用没有，原因就是两个面的版本不同，查法是 CLI 用 codex --version，macOS 上的桌面应用用 /Applications/Codex.app/Contents/Resources/codex --version。而且版本号是会变的——本机采集当天开头执行 codex --version 得到 codex-cli 0.131.0，十几分钟后同一条命令得到 codex-cli 0.147.0，which -a codex 全程只有一个可执行文件。所以排查任何跨面差异，都以当次实时输出为准，别用记忆里的版本号。

第三，桌面应用、Codex cloud、IDE 扩展、GitHub / Linear / Slack 集成，本文全部是官方文档口径，我们没有实测。 本篇里带”本机实测”字样的部分，只覆盖 codex-cli 0.147.0（Windows 11）上的只读命令输出——--help、doctor、login status（输出一行 Logged in using ChatGPT）、以及故意构造的错误参数。我们没有发起过任何模型对话请求，所以本文不会告诉你某个任务跑起来要多久、吃多少 token，那些数字我手上没有。