结论先行
Fast Mode（极速模式）到底值不值得开？先把评测结论放在最前面：
| 问题 | 结论 |
|---|---|
| 快在哪 | 快在"排队 + 首 token 延迟"，不是模型推理变快 |
| 真的省 token 吗 | 不省，反而更贵：积分消耗 2-2.5 倍，API Key 模式约 2 倍 |
| 什么任务适合 | 交互式多轮调试、长 Agent 循环、赶时间的关键操作 |
| 什么任务必须用标准模式 | 批量/后台任务、长文本生成、积分紧张的场景 |
| 会不会开了没反应 | 会。非 GPT-5.6/5.5/5.4 会被静默忽略，不报错 |
一句话：Fast Mode 不是"免费提速"，也不是"更省 token 的优化"，它是用 2-2.5 倍的消耗换约 1.5 倍的速度。它不改变模型、不提升回答质量，只是把请求送进优先队列。
这篇是评测，不是教程
想看 /fast on、config.toml 怎么配、计费倍率完整表格的教程，直接读本站的《Codex 极速模式（Fast Mode）开发者完全指南》。这篇聚焦另外三个更实际的问题：
- Fast Mode 到底"快"在哪一步？
- 它是不是真的省 token（很多人误以为"快 = 省"）？
- 什么任务开、什么任务必须关？
快在哪：优先队列，不是推理加速
先说结论：Fast Mode 加速的是"请求在队列里的等待"和"首 token 到达的延迟"，不是模型生成 token 的吞吐。模型还是那个模型，输出长度也不会变短。
实际体验上的差异：
- 首 token 延迟（TTFT）明显更短：这是最直观的感受，尤其是模型"思考"很久才开始输出的时候；
- 多轮串行交互整体省时：一次会话几十个来回，每一步都少等一点，累积起来非常可观；
- 长输出阶段提升有限：如果任务要生成几千 token，后面大段输出的时间并不会因为开了 fast 而大幅缩短。
所以"快"是一种主观感受，而且更集中在"等开头"的场景。如果你觉得"开了 fast 但出字速度没变快"，大概率是任务属于长输出型——它本来就不该指望 fast 提速。
Fast Mode 的运作机制（通俗版）
Fast Mode 底层只做了一件事：把请求的 service_tier 参数设为 "priority"（优先处理）。OpenAI 在服务端维护着不同优先级的队列，priority 队列的请求会被更早调度，于是首 token 更快返回。你可以把它理解成机场的快速通道——安检流程完全一样，只是排队位置靠前了。
这解释了两件事：
- 为什么输出阶段提速有限：一旦请求开始流式输出，它已经在"跑"了，通道优势就结束了；
- 为什么不支持 fast 的模型会静默忽略：那些模型没有对应的优先队列，设置直接被丢弃，也不报错。
关键点：fast 和 standard 共享同一套模型、同一套速率限制，只是调度优先级不同。所以它既不改变生成内容，也不豁免限流。
是不是真的省 token？——最大的误区
这是评测里最需要纠正的一点：Fast Mode 不省 token，反而每单位输出更贵。
- ChatGPT 登录（积分模式）：消耗是标准模式的 2-2.5 倍（GPT-5.6 / 5.5 为 2.5 倍、GPT-5.4 为 2 倍）；
- API Key 模式：积分倍率不适用，对应 OpenAI API 的 Priority 处理计费，通常也是标准 token 价的 2 倍左右。
"省 token"这个错觉，可能来自"同样的任务更快完成 = 感觉上更省"。但计费按实际消耗算，极速模式没有任何 token 折扣。它是一个"多付钱、少等待"的开关，不是成本优化工具。
如果你把 fast 当省 token 手段用，结果会正好相反：额度以更快的速度见底。
什么任务适合 Fast Mode
| 场景 | 为什么适合 |
|---|---|
| 交互式多轮调试 | 几十个串行步骤，每一步首 token 都更快 |
| 长 Agent 循环 | Codex 自主执行时请求一个接一个，延迟累积明显 |
| 上线前修 bug / 演示前补功能 | 时间比积分更贵，花 2 倍积分买稳定节奏值得 |
| 赶 deadline 的代码审查 | 等人不如等结果，等待成本高 |
什么任务必须用标准模式
| 场景 | 原因 |
|---|---|
| 批量 / 后台任务 | 不着急出结果，开 fast 纯浪费积分 |
| 长文本 / 文档生成 | 提速集中在前段，长输出阶段提升有限 |
| 积分紧张的订阅档 | 2-2.5 倍消耗会让额度几天内见底 |
| 稳定复现的跑批 | 结果一样，多付的积分没有回报 |
成本模型：什么时候"多付"划算（定性）
"2-2.5 倍消耗换 1.5 倍速度"值不值，取决于你等的那段时间值多少钱。用两个定性例子说明：
值得开的场景：你在交互式调试一个棘手的 bug，一个来回 30 秒到 1 分钟，一个晚上几十个来回。每一步快一点，你的"思考流"就不容易被打断——被打断一次重拾上下文的时间，可能比省下的全部等待时间还多。这时候多花点积分买连贯性，是划算的。
不值得开的场景：你在跑批量的代码扫描或文档生成，总共 10 个任务，不急着要结果。开 fast 让每个任务提前几十秒完成，但整体成本翻倍——除非有强 deadline，否则纯属浪费。
判断标准就一条：请求是不是在"阻塞你思考"。阻塞你的请求，值得开；"后台跑着就行"的任务，留在标准档。这条标准和"积分紧张时默认关"并不冲突——紧急时刻开 fast 反而更该被允许，因为它买的是你当下最稀缺的时间。
常见误区
- 误区：开了 fast 就无限加速 —— 错。极速模式和标准模式共享同一套速率限制，流量激增同样触发阶梯限速；
- 误区：fast = 更好的模型 —— 错。模型完全一样，只是处理优先级不同；
- 误区：fast = 省 token —— 错，见上文，是 2-2.5 倍消耗；
- 误区：开了没反应 = 坏了 —— 大概率是模型不支持。目前 fast 只支持 GPT-5.6 / GPT-5.5 / GPT-5.4，其它模型（含第三方兼容模型）会被静默忽略，不报错；
- 误区：fast 和 Codex-Spark 是一回事 —— 不是。
/fast是给现有模型加速的处理通道；Codex-Spark 是另一个独立的轻量模型，机制和计费都不同。
什么时候 Fast 会"不生效"
- 模型不在支持名单（GPT-5.6 / 5.5 / 5.4 之外）；
- 配置没持久化：
/fast on后确认config.toml里确实写了service_tier = "fast"与[features].fast_mode = true； - 请求头里
service_tier仍是default（codex --verbose可查）。
给团队的默认策略
如果你们不是所有人都清楚自己在干什么，给一套"默认关、按需开"的默认策略最稳：
- 默认标准模式：让日常批量、长文本、非紧急请求都走标准档；
- 交互密集环节手动
/fast on：谁卡住了谁开，用完了随手/fast off； - 设心理上限：在用量面板盯积分消耗曲线，比如"单日 fast 请求不超过总请求的 30%"；
- 把"必须快"和"可以慢"的任务分层，而不是对所有人一视同仁。
这套逻辑和 API 网关的多模型路由是相通的：把稀缺资源（积分/预算）留给真正受益的请求。
比"全程开 fast"更聪明的做法
Fast Mode 的本质是"用更多钱买更少等待"。而真实工作流里，你的请求并不全都那么急。更聪明的做法是按请求路由：交互环节走 fast，批处理走 standard，不重要的任务分流到更便宜的模型。
这正是 API 网关的用武之地。如果你用 TeamoRouter 作为 Codex 接入层：
- 免代理直连：国内开发者不用再折腾代理，直连稳定不超时；
- 统一入口：Codex 只认一个
base_url，底层模型通道由网关管理； - 多模型路由：在 GPT-5.6（快）、DeepSeek V4 Flash（便宜）之间按规则切换，把"速度"和"成本"都调优。
# Codex 配置里指向 TeamoRouter 网关
export OPENAI_BASE_URL="https://api.teamorouter.cn/v1"
export OPENAI_API_KEY="sk-teamo-你的Key"
常见疑问（FAQ）
Q：开了 Fast Mode 会更容易被限流吗？ 不会更容易，但也不会免限流。极速模式和标准模式共享同一套速率限制，流量激增同样会触发阶梯式限速。
Q：API Key 用户开 fast 的代价是？
按 OpenAI API 的 Priority 处理计费，通常为标准 token 价的 2 倍左右。先 codex login status 确认自己是积分模式还是 API Key 模式，再决定是否值得。
Q：Fast Mode 能不能省时间到"值得多付一倍"的程度？ 看任务。交互式多轮调试通常值得；批量后台任务通常不值得。建议"默认关、按需开"。
Q：第三方工具里接的 Codex 也支持 fast 吗？
不少第三方实现提供类似开关，原理都是把 service_tier 设为 priority/fast。但支持范围和计费以具体工具文档为准，建议先在官方 CLI 里验证。
Q：开 fast 会不会影响回答质量？ 不会。fast 只改处理优先级，不改模型与采样，输出内容理论上一致。
Q：fast 的提速对所有模型都一致吗？ 不是。目前只有 GPT-5.6 / GPT-5.5 / GPT-5.4 支持，且倍率因模型而异（速度约 1.5x，积分消耗 2 到 2.5x 不等）。不支持的模型会被静默忽略。
Q：/fast 的设置在换机器后会保留吗？
设置持久化在 config.toml 里，换机器/重装后如果配置还在就保留；用 service_tier = "fast" 写进配置的方式比每次 /fast on 更稳。
小结
Codex Fast Mode 的真相是：它快在"排队 + 首 token 延迟"，不省 token，反而 2-2.5 倍消耗。适合交互调试与 Agent 循环，不适合批量与长文本。高手会把它放进更大的路由体系里，让网关决定每个请求走 fast、standard 还是更便宜的模型。注册 TeamoRouter，把免代理直连、多模型路由和统一计费一次接入你的 Codex 工作流。