面向智能体工作流的 Codex 用量限制：技能、子智能体与长时间运行

关于 Codex 限额的大多数建议，都是写给在聊天窗口里敲提示词的人看的。如果你运行智能体技能、无人值守的长会话，或并行的子智能体，限额的表现会很不一样，因为按下回车的人已经不再决定能完成多少工作。技能决定跑多少步，子智能体决定额外产生多少次模型调用，长生命周期的会话决定向后携带多少上下文。当 “You're out of Codex and Work usage” 这条提示出现时，真正有用的问题是：这几项设计选择里，是哪一项把额度花掉了。

本文写给在 Codex 里构建并运行技能驱动型工作流、希望得到一份可以推理的预算的人。内容依据 OpenAI 的帮助中心文章与开发者文档，所有估算都标明为 OpenAI 自己的估算，并且会直白地指出公开资料在哪里就停了。最后核实于 2026 年 10 月 28 日。关于账号层面的重置机制（储备、自动、付费），AgentPedia 上的配套解读讲得很详细；本文只谈工作流一侧，并且只复述预算需要用到的部分。

你在花的是哪一个额度池

Work 与 Codex 共用一份额度。OpenAI 的用量说明是：这份额度不按消息数或任务数计算，你能完成多少，取决于席位或方案、模型，以及任务的形态。在部分方案上，额度按每 5 小时窗口、每周，或两个时钟同时执行；两者都适用时，任何一个计量表见底都会拦住你。

对技能作者来说，有两个细节决定了该怎么想这件事。

第一，短窗口由上一个窗口结束后发出的第一条 Work 或 Codex 消息开启。所以一个在奇怪时间点触发的无人值守定时任务，可能开启一个你没打算开的窗口，而它开启的这个窗口，会被你下一次交互式会话继承。

第二，5 小时与每周计量表由同一份用量喂养，却各走各的时钟。一个在一次爆发中完成大任务的工作流，可能把短窗口耗空而每周计量表依然健康；一个整周细水长流的工作流则可能相反。你先撞上哪块计量表，取决于工作负载的形态，而不仅仅是它的体量。

一个技能实际上怎样消耗用量

技能是一个文件夹，里面有一个 SKILL.md 以及可选的脚本与参考文件。OpenAI 的技能文档描述了渐进式披露：Codex 一开始只拿到每个技能的名称、描述与文件路径，只有在它决定使用某个技能时，才加载完整的 SKILL.md。这个设计既是上下文功能，也是用量功能，带来三个后果。

**闲置成本是描述，而不是正文。**初始技能列表的上限约为模型上下文窗口的 2%，在窗口大小未知时为 8,000 个字符。如果你安装了很多技能，Codex 会先缩短描述，并可能带着警告省略部分技能。大量安装并不会让每一轮的成本乘以所有技能的体积，但确实会给描述施加压力，而描述被缩短的技能，可能在该触发时没有触发。

**激活成本是整个正文，加上它引入的一切。**技能一旦被选中，它的完整指令就进入上下文，它要求读取的每个参考文件、脚本输出与工具结果也随之而来。一个写着“开始前先读完 references 里的所有文件”的技能，会把一次廉价的触发变成一轮昂贵的对话。这是技能作者手里最大的杠杆，而且在闲置列表里完全看不见。

**隐式匹配可能带来你没要求的激活。**当任务与某个技能的描述匹配时，Codex 可以自行选用它。含糊的描述会让匹配范围变宽，所以一个精简但触发条件含糊的技能，运行频率仍可能远超预期。像文档建议的那样，把关键用例和触发词放在前面，对匹配和成本都有帮助。

对技能作者来说，实际的读法是：把 description 当作每个会话都要付的预算项，把正文当作每次激活都要付的预算项，把每个链接的文件当作智能体只在某个分支需要时才应打开的可选项。

子智能体：墙钟时间更快，额度池更重

子智能体工作流让 Codex 并行派生专门的智能体，并把它们的结果合并成一个回复。OpenAI 的文档直接说明了成本一面：由于每个子智能体都要做自己的模型与工具工作，子智能体工作流比同等的单智能体运行消耗更多 token。它也说明了好处：把探索笔记、测试日志与堆栈跟踪这类嘈杂的输出挪出主线程，可以减少上下文污染与 context rot，主智能体拿到的是摘要，而不是原始输出。

这两条陈述对预算来说方向相反。调和的办法是问：这个子智能体在保护什么。

• 以读为主的扇出（代码库探索、日志分诊、汇总大量文档）是 OpenAI 建议开始的地方。子智能体会烧 token，但主线程保持精简，这可以让之后的轮次更便宜、更可靠。
• 以写为主的扇出（多个智能体同时改代码）是文档建议更谨慎的地方，因为冲突与协调开销会增加成本，却换不来多少产出。
• **靠指令触发的委派。**当前的本地 Codex 版本在你直接要求时委派，或者在适用的 AGENTS.md 或技能指令要求时委派。一个写着“每个文件派生一个智能体”的技能，就是一条成倍放大花费的常设指令，所以这句话要写得有意为之。

如果你在自己的注册表里管理子智能体模式，create-subagents 技能是了解子智能体定义如何组织的有用参考，尽管它是为 Claude Code 的 Task 工具写的，而不是为 Codex。它提出的设计问题（智能体拥有什么、返回什么、何时停止）可以直接迁移。要隔离每个工作者能看到什么，agent-context-isolation 从上下文一侧讲了同一个边界问题。

长会话与缓存问题

长会话花得更多，因为每一轮都带着累积的上下文。有两条公开信息与此相关，其中一条需要仔细解读。

OpenAI 帮助中心说，更长的对话与任务仍然计入你的用量限制，并指出 GPT-6.1 Sol 在 Work 与 Codex 中的默认上下文窗口为 500,000 token，对由订阅包含额度覆盖的用量，没有额外的长上下文附加费。通俗地说：更大的窗口不会按更高的费率计费，但把它填满依然会花掉额度。

另外，OpenAI 的 Tibo（@thsottiaux）在 10 月 21 日与 10 月 23 日发了两条关于缓存的帖子。第一条说，对在 Codex 与 Work 中登录的用户，缓存会被无限期保留，回到旧对话或几个小时后继续都没有惩罚。第二条说，在对话中途更改推理级别，不再使缓存失效。

请把这些读作产品行为公告，而不是额度保证。两条帖子都没有说缓存命中在订阅上会换算成多少额度消耗，帮助中心也没有公布换算关系。这些帖子确实支持的，是一种设计习惯：在会话开头保持稳定的前缀（系统提示、AGENTS.md、技能指令），把新材料追加在末尾，避免改写早期的轮次。这样做是否会降低你的计量表读数，应该在你自己的账号上测量，而不是想当然。姊妹篇 面向智能体工作负载的 GPT-6.1 Sol 讲了 API 一侧的缓存输入算术；订阅一侧没有对应的公开价目表。

如果长时间运行无法避免，压缩工具是另一个杠杆。context-compression 技能围绕结构化摘要来降低每个任务的 token 数，context-window-management 汇集了裁剪与路由的策略。两者都是社区技能，都不承诺节省额度；它们减少的是每一轮携带的内容。

模型与推理选择是一项预算项

OpenAI 说，同一个任务在不同模型上的花费可能不同，更大的输入与输出、更高的推理、多步骤任务与 Fast 模式都会推高用量；其中 Fast 模式尤其会占用更多包含额度。它为 Plus 与 Standard Business 公布的估算（每个 5 小时窗口内的本地消息数，标明是估算而非保证）是：GPT-6 Astra 为 5 到 45，GPT-6 Luna 为 350 到 3,000，两个 Sol 的行居中。每个区间的宽度才是重点：同一个模型，随任务和设置的不同，跨度大约是一个数量级。

对技能密集型工作流来说，模型的决定通常是按步骤做的，而不是按会话做的。只是提取字段、重命名文件或运行格式化工具的步骤，不需要你为设计评审选的那个模型。OpenAI 10 月 26 日的 Terra 发布帖声称，Terra 比它的前代 5.6 更耐用，也远比 Sol 6.1 或 Astra 耐用，并把深度研究与高难度编码引向这两个更重的模型。这是厂商关于相对额度的说法，没有任何帮助中心文章给出确切倍数；Tibo 的社交帖子把它说成大约是 Sol 的两倍，这只能作方向性参考。

推理级别有它自己的建议。OpenAI 建议在希望额度撑得更久时从低档开始，提醒高强度花得更多，却不保证答案更好，并指出 Astra 在 Low 档位可以胜过 Sol 在 High 档位。它还补充说，再多的推理也变不出智能体从未获得的文件、应用或权限。对技能而言，这可以转化成一条规则：如果智能体失败是因为技能没告诉它文件在哪，那么提高强度只会花掉额度，修不好故障。

面向技能密集型工作流的预算工作表

目前没有公开的单任务额度数字，所以任何预算都必须建立在你自己的观察之上。下面的结构是模板，不是数据。请用你在自己方案上的几次实测运行来填空。

有了一份实测基线，规划算术就很简单。如果一次运行消耗你 5 小时窗口的一个比例 f，那么在该窗口见底之前，大约能跑 1/f 次，而每周计量表则告诉你，一周能支撑多少个这样大小的窗口。这些数字是你自己的，并且会在 OpenAI 调整方案额度时变化，所以任何方案变动之后都要重新测一次基线。例如，Pro 200 的额度，文档写明在 2026 年 10 月 29 日之后，对在 2026 年 9 月 22 日至 9 月 29 日之间任一时刻持有过 Pro 200 的订阅者，将转为较低的包含额度，所以在该日期之前取得的基线，之后可能不再成立。

要在多个服务商之间把任务路由到够用且最便宜的模型，ai-cost-optimizer 技能介绍了一种多模型路由思路。它针对的是 API 成本而不是订阅额度，所以请把它当作划分任务难度的模式，而不是 Codex 专用工具。

哪些技能要保持精简

不是每个技能都值得同样的约束。可以按每个技能运行的频率与范围做一个粗略的分类：

**常驻技能（描述每个会话都要付费）。**把描述压缩成一句紧凑的话，触发词放最前面。把一个月没用过的技能删掉；它们占用描述空间，还增加误匹配的风险。

**高频激活的技能。**正文大小对它们影响最大。把很少用到的细节移到参考文件里，并让技能只在满足某个明确条件时才去打开它们。避免写“一开始就把所有内容读一遍”这样的指令。

**会委派的技能。**任何指示 Codex 派生子智能体的技能，都应写明上限（例如“最多三个智能体”）与返回格式（例如“十行摘要，不要原始输出”）。两者都缺，这个技能的成本就由模型来决定。

**评审与验证类技能。**它们往往在长会话末尾运行，此时上下文最大。如果它们重新读取完整 diff 与每一份测试日志，就会成为最贵的一步。请改为给它们一份精简的摘要。

**跨工具技能。**如果你把 Codex 与另一个智能体桥接起来，循环结构决定成本。codex-claude-loop 技能在两个智能体之间编排“规划、实现、验证”的循环，每一次往返都会同时消耗两边的额度池。coding-agent 把 Codex CLI、Claude Code 等作为后台进程来运行。两者都很有用，也都会成倍增加每个任务的模型调用次数，所以要给评审轮数设上限。

限额在运行途中触发时

按照方案用量文章的说法，在一个 turn 进行到一半时触及限额，不一定会中止这个 turn：Codex 可以在公平使用限制内继续，之后你会被指向用量页或横幅。对无人值守的工作流来说，这意味着进行中的那个 turn 可能完成，而下一个定时 turn 才是失败的那个。要据此设计：让运行可恢复，把进度写进文件而不是依赖对话，并在可能的地方，让工作流在开始大步骤之前先检查用量界面。

当提示出现时，OpenAI 有文档说明的选项是：等待显示的重置时间、使用可用的重置、用符合条件的 credits 继续，或升级。换一个模型从同一个额度池里扣，所以换模型不会续上额度。储备重置只有在至少一项覆盖的额度剩余不足 80% 时才能兑换，由助手触发的兑换则要求主 5 小时或每周额度剩余 10% 或更少。付费即时重置只对符合条件的 Plus 与 Pro 个人账号开放，并会把你的每周周期提前。由于免费重置没有承诺的时间表，千万不要构建一个假定它会到来的工作流。另一篇关于 Ultrafast 与 Pro 档位成本规划 的指南讲了高级速度档的倍率，这是工作流消耗额度池比预期更快的另一种方式。

论断与证据表

这些内容没有告诉你什么

对预算而言有四个缺口。没有公开的单技能或单子智能体额度成本，所以上面的工作表要靠你自己的测量。缓存与订阅额度之间的关系没有文档。在所读来源中，方案额度只用相对的方式描述，没有绝对的 token 数字，而且原有的 Pro 200 额度将于 2026 年 10 月 29 日结束。最后，关于“显示 100% 却被拦”的社区报告属于个案传闻，而 OpenAI 唯一一次公开说明计数问题发生在 10 月 20 日，涉及约 40,000 个账号，针对的是另一个问题，所以两者不应混为一谈。

常见问题

为什么我的技能密集型工作流比普通聊天更快用完 Codex 额度？ 技能在激活时会加载完整指令以及任何被引用的文件，子智能体各自做自己的模型与工具工作，长会话还要携带累积的上下文。OpenAI 说明，子智能体工作流比同等的单智能体运行消耗更多 token。

已安装的技能在闲置时会消耗用量吗？ 只有它们的名称、描述与文件路径位于初始列表中，该列表的上限约为上下文窗口的 2%，窗口大小未知时为 8,000 个字符。完整指令在技能被选中时才加载。

降低推理强度能节省额度吗？ OpenAI 说，较低的强度是让额度用得更久的好办法，较高的强度可能消耗更多，却不一定产出更好的结果。它没有公布每个档位固定节省多少。

限额触发时，Codex 会在任务中途停下吗？ OpenAI 说，如果在进行中的 turn 里触及限额，Codex 可以在公平使用限制内继续该 turn。被拦住的是下一个 turn。

换模型能避开限额吗？ 不能。新模型从同一个共享额度池里扣，所以什么都续不上。你可以对简单步骤选用更轻的模型，从而降低消耗速度。

工作流应当依赖免费重置吗？ 不应当。按 OpenAI 的话说，免费的储备重置与自动重置是酌情给予、没有时间表的。请按屏幕上显示的刷新时间来设计，并让运行可恢复。

缓存命中会降低我的用量计量表读数吗？ 不确定。OpenAI 的 Tibo 发帖谈到 Codex 与 Work 中更长寿命的缓存，但这些帖子与帮助中心都没有说明缓存命中会怎样改变订阅额度。请在你自己的账号上测量。

来源

核对于 2026 年 10 月 28 日。

OpenAI 文档

• GPT-6 Astra usage in Work and Codex（帮助中心）：窗口、估算、模型与推理建议
• Using Codex with your ChatGPT plan：共享额度池、进行中 turn 的限额行为、Support 能做什么
• ChatGPT Work and Codex：上下文窗口、用量结构
• How resets work in Codex 与 paid weekly rate limit resets：重置规则
• About ChatGPT Pro tiers：Pro 200 的过渡安排
• Codex skills 与 Codex subagents：渐进式披露、技能列表预算、子智能体的 token 成本

一手帖子与 issue

• OpenAI 在 X 上，GPT-6.1 Terra、Tibo 在 X 上，Terra 用量 与 缓存
• openai/codex issue 38892、38354 与 32680：用户报告，不是 OpenAI 的声明

文中引用的注册表技能

• create-subagents、agent-context-isolation、context-compression、context-window-management、ai-cost-optimizer、codex-claude-loop、coding-agent