深夜盯着终端里的成本报表，我一度以为自己看错了：Codex CLI 跑了一整天，账单只有 15 美元；而同样的工作量，上个月用 Claude Code 花了 155 美元。相差 140 美元，按这个速度，一个月省下的钱足够买一台 M4 MacBook Pro。
但合上报表后，我做的第一件事不是卸载 Claude Code，而是给它的桌面端点了更新。原因很简单：三个坑让我没办法彻底切换。
为什么 Codex CLI 让人心动
OpenAI 在 8 月 19 日开源了 Codex 的执行层 Codex Harness，同时重写了 CLI 的生命周期代码，官方称启动速度提升约 25 倍。实测确实如此：从敲下命令到进入交互界面，几乎和 ls 一样快。编译后的单二进制文件只有 15MB 左右，不依赖 Node 和 Docker，拉到 CI runner 上就能直接跑。
更诱人的是价格。用 ChatGPT 账号登录时，费用包含在订阅里；用 API key 则按 token 计费。我测试的是 API key 模式，默认模型 gpt-5-codex 输入 1.25 美元/百万 token，输出 10 美元/百万 token。作为对比，Claude Code 跑 Opus 5 的输入价格是 15 美元/百万，输出 75 美元/百万。单价差距五到七倍，加上 Codex 的 token 消耗只有 Claude Code 的三到四分之一，单任务成本能差出近十倍。
一次中等规模的 Express.js 重构，Codex 用了 1.5M token，花费 15 美元；Claude Code 烧掉 6.2M token，花费 155 美元。Terminal-Bench 2.0 的分数也接近：Codex 配 GPT-5.6 Sol 是 89.5%，Claude Code 配 Opus 5 是 89.1%。在终端原生任务上，Codex 甚至略占上风。
但省钱不等于省心。账单上的数字只是显性成本，真正要命的是隐性时间成本。
坑一：上下文窗口被悄悄缩水
前两个小时一切顺利，到了第 4 小时，问题出现了。在一个约 12 个文件、8000 行代码的项目里做跨文件重构，Codex 开始反复修改已经完成的内容。重发三遍 prompt 依然如故。后来检查状态行才发现，默认的 GPT-5.6 上下文窗口从 372K token 被压到了 272K。
窗口变小，意味着长会话能记住的代码、对话和决策记录都少了一截。于是它频繁触发上下文压缩，每次都要重新搜索、加载、建立对项目的理解。原本一轮能完成的事，变成三轮；一些早期决策被压缩掉后，后续代码甚至和前面的架构冲突。
那段时间的实际产出只有 40%，剩下 60% 在等待压缩、重载、重试。省钱是真的，但省下来的钱被时间吃了回去。这其实暴露了工具评估中的一个盲区：我们常盯着单价，却忽略了单位时间内的有效产出。
坑二：没有跨会话记忆
Claude Code 的 CLAUDE.md 是我很依赖的功能：在项目根目录写清楚技术栈、命名规范、测试约定，它每次启动都会读取，并在多轮对话中形成“你之前纠正过我”的肌肉记忆。Codex CLI 虽然支持 AGENTS.md，但它没有跨会话记忆。
每次新开会话，Codex 都会重新读代码库、重新解析 AGENTS.md，但不会继承上一轮反复强调的细节。举个例子：某个项目要求所有错误返回都使用 { code, message, details } 结构，我在会话 A 里纠正了三次，它终于记住；会话 B 让它继续加接口，结果又返回裸字符串错误。规则写在 AGENTS.md 里，可它看到的只是一条抽象规则，不像 Claude 那样能感知“你之前纠正过我”。
Reddit 上已经有人给 Codex CLI 写了开源记忆插件，只有 14 个赞。这个数字本身就是信号：一个原生不存在的功能，社区被迫自己补。对单轮短任务，这种“失忆”反而让 diff 更干净；但对长期项目，你会变成复读机，每次都得把同样的话再说一遍。
坑三：沙箱安全到把自己锁死
Codex CLI 的安全设计很硬核：macOS 用 Seatbelt，Linux 用 Bubblewrap 加 Landlock/seccomp，Windows 上是实验性 AppContainer。文件读写、网络调用、命令执行都被限制在项目目录内。在 CI 里跑无人值守任务时，这个设计让我敢开 --full-auto。
但真实开发中，它经常把我锁死。调试本地 Postgres 容器时，Codex 能读代码、能写 SQL，却连不上 docker-compose 网络。默认阻断外部网络，想连本地 5432 端口，得手动配置 writable_paths 和网络白名单；配好后，又因为运行在 cloud sandbox 的默认 Provider 模式下，拿不到本地环境变量里的 DATABASE_URL。最后我花了 20 多分钟教它怎么连数据库，自己手动跑了三条验证命令。同样的任务，Claude Code 跑在本地 shell 上，直接 psql 一把梭。
安全性和灵活性之间的取舍，在本地开发场景下往往比 CI 更敏感。Codex 的文档自己也承认这是实验性项目，GitHub 上 92K 星和 7400 多个 open issues 并存，活跃度与粗糙边同时存在。
两种工具，两条工作流
Codex CLI 不是废物，但它不是 Claude Code 的平替。它们是两种工具，对应两种工作流。如果日常是写函数、改 bug、跑测试、生成 CRUD、重构单个模块，Codex 大概率更便宜更快；如果日常是跨文件架构调整、长期维护复杂代码库、需要 agent 记住项目约定、要连各种本地服务和数据库，Claude Code 目前更稳。
圈子里有句话很精准：Codex for keystrokes, Claude for architecture。高级用户不会只选一个，而是用 Codex 执行，用 Claude 思考。
我的建议是：短任务、高吞吐、能自动化验证的交给 Codex，比如生成测试、格式化代码、批量重命名、跑 lint fix、写 Dockerfile；复杂重构、架构决策、首次进入陌生代码库交给 Claude Code；高风险改动则两边都跑一遍，一个写一个审，因为两者会犯不同的错。
那天晚上更新完 Claude Code，我没有关掉 Codex CLI。它还在终端里，帮我写了一条新的 GitHub Actions 工作流，很快，很便宜，diff 也干净。但我的 CLAUDE.md 没删，因为它记住的那些东西，Codex 现在还记不住。工具不是宗教，哪个顺手、哪个便宜、哪个在特定任务上不出错，就用哪个。真正贵的不是订阅费，是你以为一个工具能替代另一个工具时，浪费掉的那 6 个小时。