订阅服务 on KnightLi的博客

用 Codex 会花多少钱？新版费率表、Token 消耗和省钱方法

Wed, 10 Jun 2026 13:06:41 +0800

OpenAI 帮助中心更新了 Codex 费率表。现在大多数 Plus、Pro、Business、Enterprise、Edu、Health、Gov 和 ChatGPT for Teachers 用户，都应参考新版基于 Token 的额度计费规则。

这次规则变化的重点很明确：Codex 不再主要按“发了几条消息”估算额度，而是把输入 Token、缓存输入 Token、输出 Token 分开计量。任务越长、输出越多、使用的模型越强，额度消耗通常越高。

新版费率适用于哪些套餐

新版基于 Token 的费率表适用于：

新老 ChatGPT Plus 和 Pro 用户；
新老 ChatGPT Business 用户；
新老 Enterprise、Edu、Gov、Health 和 ChatGPT for Teachers 用户。

OpenAI 在页面中说明，2026 年 4 月 2 日起，Codex 定价规则开始从按单条消息计费改为按 API Token 用量计费，并适用于 Plus、Pro、ChatGPT Business 和新的 ChatGPT Enterprise 套餐。2026 年 4 月 23 日，这一更新扩展到现有 ChatGPT Enterprise 套餐，包括 Edu、Health、Gov 和 ChatGPT for Teachers。

少数 Enterprise 客户仍可能暂时沿用旧版费率表。如果你所在组织还没有迁移，实际规则应以工作空间和 OpenAI 销售团队确认的信息为准。

新版 Codex Token 费率表

新版费率按照每 100 万 Token 扣除多少额度来计算，并区分输入、缓存输入和输出。输出通常更贵，缓存输入通常更便宜。

模型	输入 Token	缓存输入 Token	输出 Token
GPT-5.5	125 额度	12.50 额度	750 额度
GPT-5.4	62.50 额度	6.250 额度	375 额度
GPT-5.4-Mini	18.75 额度	1.875 额度	113 额度
GPT-5.3-Codex	43.75 额度	4.375 额度	350 额度
GPT-5.2	43.75 额度	4.375 额度	350 额度
GPT-5.3-Codex-Spark	研究预览	研究预览	研究预览
GPT-Image-2.0（图像）	200 额度	50 额度	750 额度
GPT-Image-2.0（文本）	125 额度	31.25 额度	250 额度

这里的“每 100 万 Token”很关键。一次 Codex 任务最终扣多少额度，不只看你发了几句话，还要看它读取了多少上下文、复用了多少缓存、生成了多长输出，以及是否启用了更高速度的模式。

OpenAI 还特别提到，代码审查功能默认使用 GPT-5.3-Codex。GPT-5.3-Codex-Spark 可能以研究预览形式进入 Codex，费率尚未最终确定。

为什么按 Token 计费更重要

旧版规则用“单条消息”或“单个 Pull Request”做平均估算，适合粗略预算，但不容易解释不同任务之间的差异。新版规则把额度扣除和实际模型活动对应起来，更容易看出哪些地方在消耗额度。

例如，同样是一次 Codex 请求：

只让它解释一个小函数，输入和输出都短，消耗会比较低；
让它读取多个文件、跑工具、生成长补丁，输入和输出都会变大；
在长任务里反复追加需求，会让上下文持续增长；
输出大量代码、报告或审查意见时，输出 Token 会成为主要成本。

所以，控制 Codex 成本的重点不是简单少发消息，而是减少无关上下文、拆小任务、控制输出规模，并尽量让每次请求目标清楚。

旧版费率表仍然保留

OpenAI 仍保留旧版费率表，主要是为了兼容少数尚未迁移的 Enterprise 客户。旧版表按消息或 Pull Request 给出平均额度估算。

计费单位	GPT-5.5	GPT-5.4	GPT-5.3-Codex	GPT-5.1-Codex-mini
本地任务 1 条消息	约 14 额度	约 7 额度	约 5 额度	约 2 额度
云任务 1 条消息	不可用	约 34 额度	约 25 额度	不可用
代码审查 1 个 Pull Request	不可用	约 34 额度	约 25 额度	不可用

OpenAI 说明，旧版平均额度也适用于旧版 GPT-5.2、GPT-5.2-Codex、GPT-5.1、GPT-5.1-Codex-Max、GPT-5、GPT-5-Codex 和 GPT-5-Codex-Mini。

如果你的账户已经迁移到新版规则，就应优先看 Token 费率表，而不是用旧版消息均值估算。

这会怎样影响实际用量

影响取决于你的工作负载。输出多、上下文长、自动化步骤多、快速模式使用频繁的任务，额度消耗可能明显更高。轻量修改、短问答、小范围代码解释，则可能消耗较少。

OpenAI 给出的参考是：平均每位开发者每月 Codex 使用成本约为 100 到 200 美元，但实际差异会很大。模型选择、并行实例数量、自动化功能和快速模式都会改变最终用量。

去哪里看剩余额度

用户可以在 Codex 设置里的“使用说明”面板中查看使用限制和剩余额度。根据套餐和工作空间角色，有些用户也可以直接购买额度或管理自动充值。

如果你在团队或企业工作空间中无法自行添加额度，通常需要联系工作空间所有者或管理员处理。

实用建议

日常使用 Codex 时，可以按下面几条控制额度消耗：

一个任务只设定一个清晰目标；
大任务按文件、模块或功能点拆开；
不要把无关日志、旧输出和大段上下文反复带入；
需要长输出时，先说明范围和格式；
频繁审查或长时间自动化任务，要关注输出 Token 和快速模式；
团队环境中提前确认是否已经迁移到新版 Token 费率。

新版费率表的核心变化，是让 Codex 的额度消耗更接近真实 Token 成本。以后判断“为什么这次扣得多”，不能只看消息条数，而要看输入、缓存输入和输出三部分共同构成的总用量。

参考来源：Codex 费率表

Claude 额度机制怎么计算：5 小时窗口、周限额和 Token 消耗

Wed, 10 Jun 2026 10:52:06 +0800

Claude 的额度并不是简单按“今天还能发多少条消息”计算。它更接近一套动态消耗系统：短期有 5 小时滚动窗口，长期有每周总量限制，每次请求还会根据模型、上下文、附件和输出长度消耗不同额度。

这也是很多用户困惑的地方：明明只发了几条消息，却突然提示额度用完；或者同样是 Pro、Max 账号，有的人能聊很久，有的人很快触顶。核心原因通常不是“消息条数”本身，而是每条消息背后的计算成本不同。

先看 5 小时滚动窗口

Claude 常见的短期限制是 5 小时窗口。它不是按自然日从 0 点重新计算，而是按最近一段使用时间动态滚动。

简单理解：

你在一个 5 小时周期内持续发送请求；
当这段时间内累计消耗达到上限，就会看到限制提示；
等较早的请求逐步滑出窗口后，额度会慢慢恢复；
不同套餐、模型和负载时段，实际可用量会不同。

这类窗口限制最容易影响高频连续使用场景，比如一口气让 Claude Code 改代码、反复上传文件分析、长时间在同一个会话里调试问题。

常见估算口径是：免费版额度较少，Pro 每 5 小时能处理几十条普通消息，Max 则按套餐给到 Pro 的数倍使用量。实际数字不固定，Claude 页面显示的剩余额度和重置时间更可靠。

周限额决定连续重度使用的上限

除了 5 小时窗口，Claude 还会叠加每周用量限制。这个限制主要用来处理持续高强度使用，而不是偶尔某一个时间段用得多。

两者的区别可以这样看：

只触发 5 小时限制：通常等窗口刷新即可继续；
触发周限额：可能需要等更长时间，直到周额度恢复；
同时触发两类限制：短期窗口恢复后，也可能仍然受周总量约束。

因此，Claude 的限制提示并不总是代表同一种情况。短时间大量请求，可能只是 5 小时窗口满了；连续几天高强度跑 Claude Code、长文档分析或自动化任务，则更可能碰到周限额。

真正扣除的是计算成本，不只是消息数

“一条消息”并不是固定成本。Claude 在计算额度时，会综合输入、上下文、附件、工具调用和输出长度。越复杂的请求，越容易把额度吃掉。

最常见的消耗来源有四类。

第一是输入长度。你发的文字越长，需要处理的 Token 越多。几千字需求说明、长日志、完整代码文件，消耗都会明显高于普通短问答。

第二是上下文累积。同一个对话越聊越长，Claude 每次回复都要参考更多历史内容。到后期，即使你只发一句“继续”，模型也可能需要重新读取大量上下文。

第三是附件和图片。PDF、截图、表格、代码压缩包都会显著增加处理成本。一个几十页 PDF 的单次分析，可能相当于很多条普通文本消息。

第四是输出长度和模型能力。让 Claude 写长报告、生成完整代码、反复自检，都会增加消耗。更强模型和更复杂的推理任务，通常也会更快消耗额度。

Claude Code 为什么更容易触顶

Claude Code 的使用感受通常比普通聊天更“费额度”，原因很直接：它处理的不是一句问答，而是整个开发任务。

一次 Claude Code 请求可能包含：

当前任务描述；
相关文件内容；
仓库结构；
命令输出；
测试日志；
多轮修改历史；
模型生成的补丁和解释。

如果任务持续很久，Claude Code 还会不断积累上下文。看起来只是你发了 10 个提示，背后可能已经处理了大量代码、日志和工具结果。

所以用 Claude Code 时，额度管理的重点不是少打几个字，而是控制任务边界：一次只做一个明确目标，完成后新开任务，避免在同一个上下文里无限追加需求。

如何减少触发额度限制

最有效的办法，是减少无效上下文和大块附件的重复处理。

第一，任务完成后新建 Chat。一个对话处理完一个问题，就不要继续在里面开新任务。新会话能清掉旧上下文，后续每次请求的成本会低很多。

第二，把大任务拆小。不要一次要求“重构整个项目并补齐所有测试”。更好的方式是按模块、文件或功能点拆开，每次让 Claude 处理一个可验证的目标。

第三，少上传不必要的附件。只给和问题直接相关的页面、日志、截图或代码片段。上传 50 页 PDF 之前，先想清楚 Claude 是否真的需要阅读全文。

第四，及时总结再继续。如果一个会话已经很长，可以让 Claude 先压缩当前结论、待办和关键上下文，然后复制到新会话继续。这样比拖着完整历史便宜。

第五，避开高峰时段。Anthropic 曾根据负载调整过部分时段的消耗速度。高强度任务尽量放在非高峰时段，通常更不容易很快撞到窗口限制。

第六，看清套餐差异。Pro 适合日常高频使用，Max 更适合长时间研究、开发和自动化工作流。如果经常在 Claude Code 中跑长任务，Max 的体验会明显稳定一些。

不要把额度理解成固定消息条数

Claude 的额度更像“可用计算量”，不是固定的消息计数器。下面几种情况都会让你更快触顶：

在一个很长的旧对话里继续工作；
上传大型 PDF、代码文件或多张图片；
让 Claude 生成很长的报告或完整项目；
用 Claude Code 连续跑多轮修改和测试；
在短时间内发起多个高强度任务；
使用更强模型处理复杂推理。

反过来，如果你只是短问答、轻量改写、简单摘要，即使消息条数更多，也可能消耗得慢很多。

最实用的使用策略

日常使用可以按这套方式控制额度：

普通问答和轻量写作用普通聊天；
代码任务尽量一次一个目标；
每个任务结束后新建会话；
大文件先裁剪，再上传相关部分；
长对话先总结，再迁移到新 Chat；
频繁触顶时查看页面提示，区分是 5 小时窗口还是周限额；
需要连续跑 Claude Code 时，优先考虑更高套餐或额外用量。

真正影响 Claude 额度的，不是你按了多少次发送，而是每次发送背后让模型处理了多少内容。理解这一点后，最该优化的不是“少问问题”，而是让每次请求更短、更清楚、更少带历史包袱。

参考来源：Claude pricing、The Verge：Anthropic launches a $200 per month tier for power users、TechRadar：Claude is limiting usage more aggressively during peak hours、ITPro：Anthropic Claude Code usage limits increase