ChatGPT与Codex额度调整：哪些任务开始共享

看到“ChatGPT 和 Codex 要共用额度”，很容易被理解成普通 ChatGPT 对话、Codex 任务和 API 调用最终都会进入同一个余额池。这个判断过头了。根据现有产品说明，更准确的理解是：ChatGPT Work、其中内嵌的 Codex 能力以及独立的 Codex 视图，将按同一套 Work/Codex 额度关系处理；普通 ChatGPT 基础对话与 API 调用则不能默认被算进这个额度池，最终仍应以账户页面显示为准。

额度重置的范围也需要单独确认。8月30日，Codex负责人Tibo宣布为所有Codex和ChatGPT Work付费用户重置使用额度。此次重置与八类额度消耗Bug的修复有关，OpenAI称修复后同样的额度实际可多支撑10%至50%；现有资料只能证明这次修复性重置及其覆盖对象，并不能证明免费账户同步重置，或未来会持续发放重置额度。

共享不等于全部合账

讨论“共用额度”时，需要把产品整合、额度计量和API计费分开看。产品整合说明功能来自哪里，额度计量决定任务从哪里消耗，API计费则是另一套需要单独核对的使用记录。

因此，“ChatGPT 与 Codex 共用额度”更准确的含义是Work与Codex这类生产工作流开始联动，而不是ChatGPT所有功能、Codex和API彻底合账。 不同订阅档位的数值额度也可能不同，“同一机制”不代表每个账号拥有相同的额度数值。

Codex 与 Work 的边界正在变薄

在资料所述的新版产品结构中，OpenAI已将编程场景中的Codex并入ChatGPT Work。Codex技术内置于Work，同时在新版ChatGPT应用中保留一个与Work并列的Codex独立视图；原本的ChatGPT桌面应用则被定位为基础对话入口。

这会改变开发者记录任务和排查消耗的方式。过去看到“Codex”这个名称，至少可以大致判断它属于编程任务；现在，同一个界面或智能体流程可能同时完成资料检索、代码修改、文件处理、网页操作和内容生成。任务名称不再足以解释额度消耗。

例如，一个功能开发任务可能先由Work读取需求和代码库，再调用Codex修改文件，随后通过浏览器验证文档，最后生成发布说明。如果只记录“使用ChatGPT完成开发”，就无法判断消耗发生在哪个阶段。更有用的记录字段应包括任务发起入口、调用模型、子智能体数量、工具调用次数、上下文压缩次数和最终是否产生可用交付物。

边界变薄本身不必然推高成本，但Work具备连续执行数小时、定时触发、调用外部资源和使用子智能体的能力，而Codex原本也属于高消耗的智能体编程场景。两者整合后，用户更容易在一个任务中调用多种能力，额度也更难按产品名称预估。

移动端与桌面端入口不同

新版桌面端将Work与Codex视图并列，普通对话则需要通过“快速对话”按钮进入；移动端虽然可以监控部分长期任务，但不提供Codex视图。

这意味着同一账号在不同设备上可能进入不同任务路径。桌面端发起Codex任务、移动端监控Work任务，看起来是在使用同一个账户，实际执行的模型、工具链和上下文可能并不相同。比较额度消耗时，应先确认入口是否一致，再比较模型、上下文长度、运行时长和任务结果。

现有资料能够确认的是移动端与桌面端的入口差异，并没有证据表明移动端另建了一套独立额度池。因此，不能仅凭界面差异判断计费不同，也不能因为账号相同就默认所有任务在同一个池里。额度池名称、剩余积分、重置日期和适用计划仍以账户页面为准。

长任务与普通对话的额度消耗差异

ChatGPT Work的主要卖点就是能够持续跟进项目数小时，把目标转化为完整成果。它支持定时任务、事件触发、插件连接、本地文件读写、浏览器操作以及外部资源调用，并会在关键操作前等待用户确认。

长任务与短对话的成本差异，不只来自运行时间。一次持续数小时的工作流可能反复调用模型、读取新增上下文、验证中间结果、调用工具，并在失败后自动重试。子智能体还会产生额外模型请求。运行时间只是一个近似指标，并不等于固定的“每分钟扣多少积分”，公开资料也没有给出可以线性外推的统一公式。

一个典型的周报任务，可能经历读取客户数据、分析趋势、生成图表、撰写结论、调整版式和分发等环节。如果其中某个数据源持续返回异常结果，自动重试和后台检查可能比正式生成报告本身消耗更多额度。OpenAI也明确提示，Work这类复杂任务可能比普通对话消耗更多套餐额度；其计费方式与Codex相同，并通过积分制设置使用上限，资料中提到的订阅方案最高为每月100美元。

这意味着额度管理不能只关注“开了多少任务”，还要关注任务是否应该持续运行、是否具备明确终点，以及失败后会不会无限重试。

长窗口不等于高成本

Codex和ChatGPT Work的默认上下文窗口已从272k扩展到500k，窗口容量提高约80%；同时，资料称使用订阅额度运行GPT-6.1 Sol时不再收取长上下文附加费。

上下文窗口只是容量上限，窗口扩大并不意味着每个任务都应填满。评估成本时，至少要同时观察实际输入量、实际输出量、模型档位、上下文附加费和任务重试次数。长上下文能够减少频繁压缩带来的信息损失，却也可能让后续每轮请求携带更多历史内容。

如果一个任务只需要修改一个函数，输入几十万Token并不会提高结果质量；如果一个任务需要分析整套代码库，过早压缩又可能丢失依赖关系。合理做法是根据任务保留必要上下文，把无关历史、旧图片和过期文件移出工作线程，并在上下文接近压缩节点时检查任务是否已经偏离目标。500k代表“最多可以容纳多少”，不是“每次都应该用多少”。

额度 Bug 会增加任务的隐性消耗

此次调整背后，OpenAI集中处理了数千份用户反馈，并确认了八类已修复问题。公开资料详细列出了其中几类，这些类别也说明了智能体任务常见的隐性消耗来源。

第一类问题与上下文压缩有关。旧图片没有被及时清除，可能反复触发上下文压缩，导致同一段历史内容被重复处理。第二类问题来自任务目标机制，异常情况下可能额外消耗15%至70%的周额度。第三类问题出现在Memory Worker后台任务中，由于停止条件始终无法满足，任务最多可能运行15000次。第四种问题与子智能体有关，子智能体可能自行选择成本更高的模型。

这些问题并不等于ChatGPT Work或Codex天然会无限运行，但它们说明，在智能体系统中，错误的工作流可能比用户真正要求的工作持续得更久。修复后，同样额度实际可多支撑10%至50%，这一数字针对的是已经确认并修复的问题，并不意味着所有任务都会获得相同比例的提升。OpenAI已公开完整修复清单，开发者可以据此检查自己的任务模式。

对使用记录也应做一次基线校准。修复前后的Token消耗不能直接横向比较，尤其是后台循环、上下文压缩和子智能体调用频率较高的任务。否则，很容易把Bug修复带来的效率提升误认为业务本身突然变轻，或者继续按照旧日志高估任务成本。

这次重置有明确边界

8月30日，Codex负责人Tibo宣布为所有Codex和ChatGPT Work付费用户重置使用额度。此次动作与额度Bug修复同时出现，更接近一次修复后的补偿与重新校准。

现有材料没有说明免费账户是否同步重置，也没有公布以后按月、按季度或按活动周期持续重置的规则。此次重置不能被直接解读为一项长期账户权益，更不能证明“免费重置时代已经彻底结束”。真正可以确认的只有两点：这次重置面向Codex和ChatGPT Work付费用户；修复后的额度效率可能高于修复前。

用户仍应检查账户页面中的重置时间、适用产品、剩余积分和任务限制，避免把某个账号的临时状态推广成所有账号的统一规则。

免费重置不应成为默认预期

36氪将这次变化概括为“ChatGPT要和Codex共用额度，免费重置时代结束了”。这个标题抓住了用户对额度机制变化的敏感，但它更接近一种舆论判断，而不是一项覆盖所有套餐的永久政策。

补贴并没有消失。另一份资料梳理了OpenAI发放额度“重置卡”、Anthropic提供阶段性免费额度等做法，说明额度赠送仍会是模型厂商获客和留存用户的工具。 真正发生变化的是，开发者不能再把临时重置当作可重复获得的收入或固定资源。

在预算中，更合理的做法是把正常套餐费用作为基础成本，把重置视为可能出现的临时上行空间。如果每月都按“肯定会重置”来做成本规划，一旦活动停止、覆盖范围变化或账户不适用，实际预算就会失效。与其依赖一次免费重置，不如先降低正常周期内的额度消耗，把重置当作效率改善后的额外余量。

个人开发先管单位任务成本

个人开发者最容易忽略的问题，是只统计“用了多少额度”，却不统计“换回了多少有效产出”。更有意义的指标应是单位任务成本：记录一次任务消耗的积分和Token、运行时长和工具调用次数，并衡量这些消耗对应了多少可合并代码、通过测试的功能或可交付文档。

优化可以从几个具体动作开始：

• 先做模型路由。文档整理、格式转换、简单函数生成和重复性分析优先使用成本较低的模型；架构设计、复杂调试、安全审查和跨模块重构再交给高成本模型。不要让高成本模型承担可以提前摘要、过滤或结构化的准备工作。
• 缩小任务边界。把“分析整个项目并持续优化”改成明确文件、明确验收条件和有限步骤。一次提交过多目标，会让智能体反复确认、搜索和自我修正。
• 给后台任务设置停止条件。至少定义最长运行时间、最大重试次数、最大子智能体数量和明确完成条件。定时任务还应记录连续失败后的处理方式，避免事件不断触发而任务始终无法结束。
• 限制子智能体及其模型选择。并非每个子任务都需要独立代理，更不应默认允许子智能体自行升级到高成本模型。可以在任务说明中限定模型档位、并发数量和返回格式。
• 保持上下文干净。及时移除旧图片、过期日志和无关文件，把不同项目拆到不同线程，并检查上下文压缩是否在没有实际进展时反复发生。
• 记录可比较的消耗。至少保存任务入口、模型、运行时长、输入输出量、工具调用、压缩次数、重试次数和最终交付结果。排查额度异常时，这些记录比一句“今天用得特别快”更有价值。

这些做法的重点是减少没有产出的计算。模型越贵、上下文越长、子智能体越多，越需要明确边界。

团队的额度分配与成本管理

ChatGPT企业版和教育版支持设置整体支出上限，也可以为不同团队或个人设置独立限额。 当Work、Codex和智能体后台任务形成共享额度关系后，团队面对的问题就不再只是“买多少个账号”，而是“有限额度应该分配给哪些工作”。

共享模式可以在规模扩大时摊薄成本，但也可能带来资源竞争。一个运行数小时的批处理任务、一个需要反复调用外部工具的自动化流程，可能在同一时间占用其他成员原本可以使用的额度。团队如果只按人数和订阅档位核算，就很难提前发现这种集中消耗。

完整成本至少应拆成以下几层：

资料对Token Plan的分析也强调，所谓性价比不能只看百万Token标价，还要把额度周期、计量方式、超额规则、席位与共享方式，以及接口适配和调用稳定性放进全成本模型。

团队可以先把交互式开发、批量处理和实验性长任务分开预算，并为批量任务设置更严格的运行上限。API调用应单独建立账单视图，不能因为Work或Codex可以使用外部工具，就默认相关API费用已经包含在订阅额度内。出现额度不足时，也应先切换到较低成本模型、缩短上下文或缩小任务范围，再决定是否增加预算。

对于中小团队，固定订阅、明确硬上限和低成本模型回退机制，通常比同时购买多套重叠服务更容易管理。账号数量少并不自动等于成本低，任务失控、重复购买和失败重跑同样可能形成隐性支出。

算力控制正在进入产品竞争

Claude Opus 4.8近期加入努力程度控制：低努力模式响应更快，对速率限制的消耗也更慢；其快速模式则尝试以更高运行速度换取更低使用成本。 这与OpenAI提供的模型档位、上下文窗口、积分上限和团队支出控制，虽然不是同一种计费设计，却指向同一个产品方向：用户开始需要决定“为这项任务投入多少算力”。

竞争的重点因此不再只是模型能完成多复杂的任务，也包括能否让用户控制速度、成本和停止边界。额度只是这种算力控制的一种表现。对个人开发者而言，最优模型不一定是能力最强的模型，而是完成特定任务时成本与稳定性最合适的模型；对团队而言，最优套餐也不只是额度最多的套餐，而是能够解释消耗、限制风险并支持工作流分派的套餐。

我的判断是，这次变化不只是额度规则的一次调整，而是AI工具从“按账号提供福利”走向“按任务管理算力”；开发者真正需要优化的不是抢到一次免费重置，而是提高每个任务产出所消耗的额度效率。