夜雨聆风【导读】OpenAI 员工 Tibo 在 X 上抛出一个问题——Codex 要不要引入 batch compute「慢速模式」？数千人点赞、七百多条回复涌入。开发者的态度出奇一致：愿意等，但要便宜，要有契约。与此同时，OpenAI API 已经把「用延迟换折扣」做成了标准产品——Batch API 半价、Flex processing 低优先级调度。AI 编程正在从「谁的模型更强」转向「谁的额度卖法更聪明」。
一个试探性的问题，开发者涌进评论区
5 月 24 日，OpenAI 员工 Tibo（@thsottiaux）在 X 上发了一条帖子：
"Should we bring batch compute to codex? Aka /slow mode"
「要不要把批量计算引入 Codex？也就是 /slow 慢速模式。」
▲ Tibo 的帖子，采集时已有数千赞和七百多条回复
没有产品截图，没有发布日期，甚至没有说"我们正在做"——只是一个问号。但这个问号踩中了 AI 编程用户最敏感的神经：额度不够用。
Codex 现在的消耗逻辑是实时计费。你开一个任务，agent 扫描代码库、读文件、编辑、跑测试，底层是几十轮 API 请求来回跑。每一轮都在吃额度。任务越复杂、代码库越大、执行时间越长，额度消耗越快。
所以当有人问"能不能慢一点、便宜一点"，底下立刻炸开了。
开发者想要什么？睡前扔任务，醒来看结果
回复里最高赞的方向可以总结成两个字：过夜。
Lukas Böhm 的回复最受欢迎：
"/overnight — Give the goblins a task before bed. Wake up to the finished work and a little 'what happened while you slept' report."
「/overnight——睡前给小精灵们派任务，醒来看到完成的工作和一份"你睡着的时候发生了什么"的报告。」
Matthew Berman 说得更直白：
"Yes there are often tasks I can kick off before bed that don't take 8 hours and I would be happy to pay less to go slow."
「很多任务我可以睡前启动，用不了 8 小时就能跑完，我愿意付更少的钱让它慢慢跑。」
Tony Simons 把场景拆得更细：
"I would be down for this at a reduced token cost. There are plenty of times I start Codex or Hermes on a goal before bed or during my day job where I don't need it to be quick. This would save more token usage for when I'm locked in and active."
「降低 token 成本的话我肯定支持。很多时候我睡前或者上班时开个 Codex 任务，根本不需要它跑得快。这样能把 token 额度省下来，留给我真正专注写代码的时候用。」
这些回复指向同一个需求：不是所有 coding agent 任务都需要实时响应。重构、文档更新、批量测试、代码审查、大型代码库探索——这些工作完全可以丢进后台排队，用户不需要盯着屏幕等。
关键在于，用户愿意用等待时间换更低的额度消耗。
但"慢"和"卡住"只差一条线
不是所有人都在喊"给我便宜"。最值得注意的回复来自 Zero Index：
"Yes for non-interactive work. Batch mode gives a clear cost/latency tradeoff, but it needs strict SLAs by task class so users know when 'slow' turns into 'stuck.' Without deadline guarantees, teams will default back to synchronous even at higher cost."
「非交互式任务可以。Batch 模式提供了清晰的成本/延迟折中，但它需要按任务类型设定严格的 SLA，让用户能分清'慢'和'卡住'的区别。如果没有明确的完成时限，团队最终还是会回到同步模式，哪怕更贵。」
这条回复点出了 slow mode 最大的产品设计难题：慢可以接受，不可预测不行。
你让一个 agent 跑 overnight 任务，第二天早上打开电脑，看到的是"完成了"还是"还在跑"？如果还在跑，是正常的慢，还是哪里卡死了？没有明确的完成窗口、没有进度反馈、没有超时机制，用户对"慢速"的信任会迅速崩塌。
回复里还有人提到 cost cap（费用上限）、kill switch（紧急终止）、signed diff（签名差异报告）、checkpoint（检查点）等机制——说明开发者对后台运行的 agent 有一套完整的信任清单。
这已经超出了"便宜一点"的范畴，进入了服务契约的设计领域。
OpenAI 其实已经做过这件事——在 API 层
如果你觉得"用延迟换折扣"是个新概念，看一眼 OpenAI 的 API 定价页面就知道了。
▲ OpenAI API Pricing 页面，旗舰模型区域可选择 Standard、Batch -50%、Data residency +10% 三种处理模式
页面上写得清楚：Choose your processing mode（选择你的处理模式）。标准模式、Batch 模式打五折、数据驻留模式加价 10%。同一个模型，同样的能力，价格可以差一倍——取决于你愿意等多久。
Batch API：半价、更高限额、24 小时内完成
▲ Batch API 文档页面，核心卖点：50% 折扣、更高速率限制、24 小时完成窗口
OpenAI 的 Batch API 把这套经济学写得非常明确：
- 成本减半
：相比同步 API，输入输出价格直降 50% - 更高速率限制
：使用独立的、上限更高的请求池 - 24 小时完成窗口
：每个 batch 在 24 小时内完成，通常更快
用户放弃即时返回，平台获得调度自由度——可以把任务塞进低峰时段、排队窗口或者空闲资源池。双方各取所需。
它已经是 OpenAI 正在运行的生产级服务。
Flex processing：更贴近 /slow mode 的原型
▲ Flex processing 文档，用更慢的响应时间和偶尔的资源不可用换取更低成本
如果说 Batch API 面向的是"一次提交一大批请求"的批处理场景，那 Flex processing 和 Tibo 说的 /slow mode 更像。
Flex processing 的定义是：用更慢的响应时间和偶尔的资源不可用，换取更低的成本。它适合非生产环境、低优先级任务——模型评估、数据增强、异步工作负载。token 价格按 Batch API 费率计算。
把这个逻辑搬到 Codex 上：重构、回归测试、代码审查报告——这些任务不需要你盯着看，排进低优先级队列，agent 在后台慢慢跑，额度消耗打折。
API 层已经证明这种经济模型跑得通。问题只是：要不要把它从开发者发 JSONL 请求的 API 界面，搬进 Codex 用户直接操作的 agent 工作流里。
AI 编程的订阅战已经打到了「额度怎么卖」
Tibo 的提问并非凭空出现。AI 编程产品的竞争焦点，正在从"模型能力"滑向"使用额度的分配方式"。
▲ VentureBeat 报道 OpenAI 推出 $100/月 Pro 套餐，Codex 使用限额为 Plus 的 5 倍
VentureBeat 报道，OpenAI 推出了 $100/月的 Pro 套餐，Codex 使用限额是 Plus 套餐的 5 倍。OpenAI 开发者社区公告还提到，限时期间 Pro 用户可以获得 Plus 的 10 倍 Codex 用量。
与此同时，CNBC 报道指出，Anthropic 的 Claude Code 已经有 Max 5x、Max 20x 等更高的使用层级。Sam Altman 曾透露 Codex 周活跃用户达到 300 万，使用限制会随着用户增长阶段性调整。
$20 的 Plus、$100 的 Pro、$200 的 heavy tier，再加上企业 credits、团队配额、额外购买——AI 编程的计费体系正在变得越来越像云计算。
而 /slow mode 如果落地，等于在这个体系里再加一个维度：不只按用量分层，还按优先级分层。Fast lane 给坐在屏幕前调试的人用，slow lane 给离开屏幕后还在跑的 agent 用。
为什么不能把所有东西都放慢？
OpenAI 工程博客有一篇文章专门讲 Codex 的 agent loop 延迟结构。当用户让 Codex 修一个 bug，它背后要扫描代码库、读文件、构建上下文、编辑代码、运行测试——底层是几十轮 Responses API 请求。这些请求的延迟会叠加成用户感知到的等待时间，动辄几分钟。
工程团队正在用 WebSocket、连接级缓存等方式压缩延迟，让 agent loop 端到端更快。
这说明fast path 仍然是 Codex 的核心体验。调试、交互式探索、用户正在看着终端等待结果——这些场景必须快。如果把所有 Codex 体验都降速来省额度，用户会直接流失。
真正合理的设计更像一条双车道公路：前台交互保持快速通道，后台任务走慢速队列。用户可以按任务性质自己选。
从"模型分层"到"体验分层"
过去 AI 产品的价格分层围绕模型能力展开：更强的模型更贵，更高的限额更贵。但 Batch API、Flex processing、Priority processing 暗示了另一个维度——同一个模型、同样的能力，可以按服务质量分层。
这和云计算的路径几乎一样。AWS 有按需实例、预留实例、Spot 实例，同样的 EC2 机器，价格可以差好几倍。差别在哪？在于你愿不愿意接受"可能被中断""需要排队""不保证即时可用"。
AI 编程正在走上同一条路。未来的竞争维度可能包括：
- 实时交互 vs 后台队列
：坐在屏幕前用 fast mode，离开屏幕用 slow mode - 完成窗口 vs 即时返回
：24 小时保证完成 vs 实时流式输出 - 固定订阅 vs 按优先级计费
：$100/月吃到饱 vs 高优任务按量付费 + 低优任务打折 - 单 agent vs 并行 agent
：一个 agent 独占资源 vs 多个 agent 排队共享
如果 OpenAI 真的在 Codex 里做出 /slow mode，它卖的不只是便宜，而是一种新的使用契约：你告诉我这个任务不急，我保证在某个窗口内完成，但不保证马上开始。
这件事最终考验的是信任
回到 Tibo 那条帖子。它表面上问的是"要不要做 /slow mode"，但底下七百多条回复展开的讨论远比这个问题大。
开发者想要的不只是便宜。他们想要在离开屏幕之后，仍然能信任一个 agent 在替自己干活——第二天打开电脑，看到完成的报告、通过的测试、可以直接 review 的 PR。谁都不想看到卡在半路的进度条。
这要求 slow mode 有完成窗口、费用上限、checkpoint、状态通知、失败重试、分支隔离——一整套围绕"人不在场时 agent 怎么工作"的产品基础设施。
AI 编程的下一步，模型更强、额度更多都只是基础——agent 能不能在没人看着的时候依然值得信赖地工作，才是真正要解的题。
— END —
