Fast Mode 完整指南
Fast Mode（极速模式）是 Codex 的优先处理能力：把请求送入更快的处理队列，让支持的模型更早开始响应。模型本身不会改变，换来的是更短的等待时间；相应地，积分或 token 成本可能上升。
一句话搞懂 Fast Mode
Fast Mode 的价值是“更快出结果”，不是让模型少思考，也不是把普通模型变成另一个模型。实际速度取决于模型、网络、排队情况和任务长度；参考体验通常是首个响应更快，完整长文本的生成时间不一定按同样比例缩短。
怎么开启：一条命令
在 Codex CLI 的交互式会话里使用斜杠命令：
/fast on # 开启极速模式
/fast off # 关闭极速模式
/fast status # 查看当前状态
开启后设置会写入配置并在下次启动时继续生效。若你的 CLI 版本不支持这些命令，请使用配置文件方式，或升级到支持 Fast Mode 的版本。
配置文件方式
直接编辑 ~/.codex/config.toml，可以将 Fast Mode 设为默认：
service_tier = "fast"
[features]
fast_mode = true
其中 service_tier = "fast" 表示请求优先级，fast_mode 是功能开关。不同版本的 Codex CLI 字段名称可能略有差异，请以 codex --help 和本地版本文档为准。
在 MuskAI 中的推荐配置
如果通过 MuskAI API 接入，建议同时满足以下条件：
- 网络出口优先选择日本或韩国地区。
- OpenAI 协议优先使用
/v1/responses，并开启stream: true。 - 分组选择 Profast 或 企业级。
- 只对真正需要低延迟的请求开启 Fast Mode。
{
"model": "gpt-5.5",
"stream": true,
"input": "继续完成这个任务"
}
工作原理与成本
Fast Mode 的底层思路是把请求标记为优先处理（常见参数名为 service_tier: "priority" 或 "fast"）。不同模型、登录方式和供应商的计费规则并不相同，不能把所有 Fast 请求简单按同一个倍率估算。
| 使用方式 | 成本理解 |
|---|---|
| ChatGPT 登录的 Codex | 通常按订阅积分倍率扣减，极速模式会更快消耗额度 |
| API Key / OpenAI 兼容网关 | 通常按 token 计费，优先级可能对应更高的处理价格 |
| 不支持 Fast 的模型 | 通常忽略 Fast 设置，按标准模式处理 |
开启前请先确认自己属于哪种计费方式，并在用量页面观察真实消耗。Fast Mode 是“用更多预算换更少等待”，不是免费加速。
Fast 没生效？三步排查
- 确认模型支持：旧模型或第三方兼容模型可能会静默忽略 Fast 设置。
- 确认配置已保存：执行
/fast status，并检查config.toml是否写入了 Fast 相关字段。 - 确认请求真的走优先级：在 verbose 日志或请求追踪中查看
service_tier，确认不是default。
如果仍然没有改善，先用 /v1/responses + 流式输出测试首个事件时间，再比较完整响应耗时，不要只凭一次请求判断。
什么时候适合开启？
- 交互式多轮调试：每一步都要等模型返回，延迟会在几十个步骤中累积。
- 长 Agent 循环：任务需要模型连续调用工具、检查结果并继续执行。
- 赶时间的关键操作：上线前修复、演示前补功能、现场排查故障。
什么时候不建议开启？
- 批量或后台任务：不着急拿结果时，标准模式更节省额度。
- 长文本生成：Fast Mode 主要改善首 token 等待，长输出阶段未必同比加速。
- 积分或预算紧张：持续开启会明显加快额度消耗。
更聪明的做法：按任务路由
不要把所有请求都设为 Fast。可以按任务分层：
- 前台交互、阻塞当前工作的请求走 Fast。
- 后台批处理、文档整理、低优先级任务走 Standard。
- 不重要的任务分流到更便宜的模型。
在 MuskAI 中，可以通过 Profast、企业级等分组和流式 Responses API 组合，减少等待感；同时打开多个独立任务，让它们在后台执行，避免一直停留在页面前“监工”。
Fast Mode 和 Codex-Spark 不是一回事
/fast 是给现有模型增加优先处理的通道；Codex-Spark 是另一个独立的轻量模型。两者在模型能力、路由方式和计费上都不同，不要混为一谈。
第三方工具支持吗？
部分第三方客户端也提供类似的 Fast 开关，通常会把 service_tier 设置为 priority 或 fast。但是否生效取决于客户端、网关和上游模型，建议先在官方 Codex CLI 中验证，再迁移到其他工具。
积分管理：别让“快”吃掉整个额度
建议采用以下节奏：
- 默认关闭，需要密集交互时再执行
/fast on。 - 把“阻塞你思考”的请求标记为 Fast，后台任务保持标准模式。
- 在用量页面观察消耗曲线，为每日 Fast 请求设一个预算上限。
小结
Fast Mode 适合交互式开发和延迟敏感的 Agent 任务。正确的组合是：稳定的日本/韩国网络、支持优先级的分组、/v1/responses 流式输出，以及按任务选择 Fast 或 Standard。先用 /fast status 确认状态，再用真实首事件时间和用量数据判断是否值得长期开启。