Claude Code 和 Codex 不是共用一个每日 token 池。到 2026 年 6 月 30 日，真正有用的问题不是“每天还能用多少 token”，而是：现在是哪一个仪表在动，哪一种合同在付费。
Claude Code 这边，仪表可能是本地 /usage、订阅计划里的 usage bar、Claude Console 的 API 花费、workspace spend limit，或者团队自己导出的 OpenTelemetry。Codex 这边，仪表可能是 ChatGPT 计划内的五小时窗口、额外 credits、workspace credits、Fast mode 的 credit 倍率、图片生成消耗，或者 OpenAI Platform 的 API key 账单。
所以不要直接问“该不该升级”。先确认工具入口、计划入口、模型、上下文大小和计费路线，再决定是清上下文、compact、换模型、降 effort、关掉多余 MCP、设置 spend limit、购买 credits，还是把额外工作改走 API key。
**证据说明：**OpenAI Codex 的 pricing、speed、auth、slash command、analytics、image generation 文档已在 2026 年 6 月 30 日复核；Anthropic Claude Code 的 cost、usage、analytics、settings、OpenTelemetry 文档也在同一天复核。
先看仪表，不要先按升级按钮
很多用量判断会错，是因为把三个问题揉在一起：
- agent 实际读进了多少上下文
- 产品界面怎么显示剩余额度
- 哪个账单或 credit 池正在被扣
先把这三件事拆开。
| 工作入口 | 第一个要看的仪表 | 更深的归属 | 第一控制动作 |
|---|---|---|---|
| Claude Code 本地订阅会话 | /usage、status line、扩展里的 Account & usage | Claude plan limit 与本机 session history | 清掉无关历史、compact、降 effort、换模型、关掉不用的 MCP |
| Claude Code API / Console 路线 | Claude Console usage 与 workspace spend limit | API billing 与 workspace rate limit | 设置 workspace 上限，查看 per-user spend，打开 OTel |
| Claude Code 团队使用 | Claude analytics、OTel、gateway、SIEM | Team / Enterprise 管理策略 | 按用户、模型、工具、skill、plugin、MCP、agent 归因 |
| ChatGPT 登录的 Codex | Codex usage dashboard 与 CLI /status 或 /usage | 计划内窗口加可选 credits | routine 工作用小模型，减少上下文，Fast mode 只在值得时打开 |
| Codex API key | OpenAI Platform billing、limits、API pricing | 按量 API 合同 | 给项目设置预算，把 CI/automation 和互动工作分开 |
只要仪表认错，后续动作就会错。升级计划解决不了臃肿的 CLAUDE.md、噪音 MCP、失控 subagent、Codex Fast mode 习惯，或者打到错误预算上的 API key。
Claude Code：先读 /usage
Claude Code 的 cost 文档把 /usage 放在本地诊断入口。Session block 会显示当前会话的 token 统计。API 用户可以用它估算 token 花费；Pro、Max、Team、Enterprise 订阅用户则要把本地金额估算和实际账单分开，因为订阅用户还会看到 plan usage bars、activity stats，以及哪些内容算进计划额度。
这点很关键。订阅用户不应该把本地 dollar estimate 当成订阅账单；API 用户也不能因为 /usage 看起来不大就忽略 Console billing。更稳的规则是：
- 用
/usage看当前本地 session - 用 plan bars 看订阅压力
- 用 Claude Console 看 API 账单
- 用 analytics 或 OpenTelemetry 看团队归因
同一个 /usage 画面还可以把最近用量分给 skills、subagents、plugins 和 MCP servers。官方文档还说明有 day/week 切换；VS Code 扩展也有类似的 Account & usage dialog。也就是说，/usage 不是装饰信息，而是第一层排查工具。
| 现象 | 常见原因 | 控制动作 |
|---|---|---|
| 很短的 prompt 消耗异常 | 隐藏上下文、旧历史、工具或 MCP 定义太多 | 跑 /context，清掉无关历史，用窄指令 compact |
| 计划阶段额度掉得快 | extended thinking、高 effort、仓库探索太宽 | 降 /effort，指定文件，提前写 stop condition |
| 团队不知道谁在烧 | 本地 /usage 不能承担团队归因 | 打开 OTel 或 analytics，按用户、模型、工具、skill、agent 分组 |
| API 账单突然变大 | workspace spend limit 缺失或太宽 | 设置 workspace spend limit，必要时降低 per-user rate limit |
Codex：分清计划窗口、credits 和 API key
Codex 的账本形状不一样。OpenAI 的 Codex pricing 页面没有把产品写成一个每日 token cap，而是拆成 included plan usage、credits、workspace credits 和 API key billing。
截至 2026 年 6 月 30 日，OpenAI Codex pricing 表里可见的 local messages / 5h 范围是：
| Codex 路线 | Local messages / 5h | 当前表格注意点 | 控制含义 |
|---|---|---|---|
| Plus | GPT-5.5: 15-80；GPT-5.4: 20-100；GPT-5.4 mini: 60-350 | 范围会受模型、任务大小、复杂度和本地上下文影响 | routine edit 用 mini，大仓库上下文不要带进每一轮 |
| Pro 5x | GPT-5.5: 75-400；GPT-5.4: 100-500；GPT-5.4 mini: 300-1750 | 窗口更大，但不是无限 | 把重模型留给高风险代码路径 |
| Pro 20x | GPT-5.5: 300-1600；GPT-5.4: 400-2000；GPT-5.4 mini: 1200-7000 | 最高计划内层级，仍受上下文影响 | 长任务和后台工作要单独监控 |
| Business included usage | GPT-5.5: 15-80；GPT-5.4: 20-100；GPT-5.4 mini: 60-350 | workspace 合同和 flexible pricing 会改变团队账本 | 管理员要看 workspace credits，不只看公开计划行 |
| API key | 按量计费 | 走 OpenAI Platform 标准 API pricing | 当 API 花费和 rate limit 管理，不要当成 ChatGPT 计划额度 |
OpenAI 还按模型和功能公布 credit rate。GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-Image-2 image path、GPT-Image-2 text path 的 input、cached input、output credit rate 都不同。一个长输出的 coding run 和一个短诊断 prompt，不会消耗同样 credits。
Fast mode 也是倍率。OpenAI speed 文档说明，支持的 ChatGPT 登录会话使用 Fast mode 会更快，但也会以更高倍率消耗 credits。GPT-5.5 Fast mode 是标准 credit rate 的 2.5x，GPT-5.4 是 2x。API key 会话走标准 API pricing，不使用 ChatGPT Fast mode credits。
图片生成也不能按纯文本回合理解。OpenAI Codex 文档说内置 image generation 会计入一般 Codex usage limits，而且平均比纯文本更快消耗 included limits。如果你的 Codex 会话在生成图解、UI mock 或文章图，不要拿它和普通代码编辑对比。
两个工具共用一套控制循环
Claude Code 和 Codex 的仪表不同，但控制循环相近。
- 说清任务。 这是探索、编辑、review、CI、图片生成，还是团队自动化？
- 说清付款方。 订阅计划、usage credits、workspace credits，还是 API key？
- 说清上下文。 哪些文件、说明、MCP、日志、工具、截图、历史被带进来了？
- 说清模型和 effort。 重模型和高 effort 用在高不确定性位置，不是每轮默认。
- 前后测量。 改合同前先看
/usage、/status、dashboard、OTel、Console spend、Platform billing。 - 一次只改一个杠杆。 清理、compact、换模型、关 server、拆任务，然后再测。
这套流程故意朴素。一次改五个变量，团队学不到任何东西；每次只动一个变量，才知道哪一个环节真正省钱。
不要混用的账单边界
最贵的误解，是把所有“credits”都当成同一个东西。
Claude Code 和 Codex 都会出现 usage、limits、spend 这些词，但它们不是同一套账本。Claude Code API usage 由 Anthropic Console 跟踪，可通过 workspace spend limit 管控。Pro 和 Max 计划会出现订阅 usage bars 和 usage credits。团队还可能加入 analytics、OpenTelemetry、gateway attribution 和 SIEM。
Codex credits 是 OpenAI 侧的续用单位，用于计划内额度后的支持场景或 flexible workspace contract。OpenAI Platform API key billing 是另一条按量路线。Codex API key workflow 不会消耗 ChatGPT 计划内 credits。
可以用这些 stop rules：
- 不要把 Claude Code subscription usage 说成 API bill，除非 Console billing 确认。
- 不要把 Codex API key usage 说成 ChatGPT 计划额度。
- 不要把 Fast mode 当免费加速。
- 不要把图片生成等同纯文本 coding turn。
- 不要从一天的 dashboard 异常或 quota-drain 事件推导长期 baseline。
团队控制：dashboard、遥测和 spend limit
团队用量控制不能只靠个人本地命令。
Claude Code 给 Team 和 Enterprise 组织提供 analytics dashboard，API 客户可用 Console dashboard 看 usage 和 spend。要看 per-user token counts 和 cost estimates，Anthropic 指向 OpenTelemetry export。OTel 可以按配置暴露 token usage、cost usage、session count、tool activity、model、skill、plugin、MCP、agent 等属性。
这能把“某个人用太多了”变成“这个 workflow 每次都会加载同一个 MCP、plugin 和 subagent，所以上下文太大”。第二种说法才有修复路径。
Codex 也有自己的 admin 与 analytics surface。OpenAI enterprise governance 文档说 workspace admins 和 analytics viewers 可以跟踪 adoption、usage、不同 product surface/model 的 credit 和 token usage，但数据可能有延迟。追查团队 spike 时，这个延迟要写进判断。
实际团队策略可以这样定：
- 把互动开发、CI、review、实验分成不同预算
- unrelated work 必须开新 session
- 共享说明文件保持短，把专业流程放进按需 skill
- 高成本模型只给高价值任务
- 大规模推广前先导出 usage metrics
- 任何人买 credits 前，先触发 stop-and-inspect 阈值
当额度掉得太快，先这样做
额度掉得比预期快时，不要先升级。按这个顺序走。
| 步骤 | Claude Code 动作 | Codex 动作 | 为什么先做 |
|---|---|---|---|
| 1 | 跑 /usage，看 plan bars 或 Console | 看 Codex dashboard 与 /status 或 /usage | 先确认哪一个仪表在动 |
| 2 | 跑 /context，clear 或 compact | compact，开新任务，减少上下文 | 上下文通常是最便宜的修复点 |
| 3 | 降模型或 effort | 从 GPT-5.5 切到 GPT-5.4 或 mini | 模型组合会立刻改变消耗 |
| 4 | 关不用的 MCP / plugin / agent | 关不用的 MCP、tools、后台 review loop | 工具开销会放大小任务 |
| 5 | 看团队 telemetry | 看 admin analytics 与 Platform billing | 区分个人 session 与团队 spend |
| 6 | 最后才改合同 | 买 credits、提高 workspace limit、改 API billing | 合同变化应该跟在诊断后面 |
遇到异常日再加一条：如果很多用户同时报告 quota drain，先当成 accounting、dashboard、后台任务或 retry 问题排查。截图，记录模型、上下文和任务类型，等官方 surface 稳定后再决定是否改预算。
实用预算清单
- 运行前： 写清目标、文件、stop condition 和验证命令。
- 开始时： 检查
/usage或/status，确认模型、effort、Fast mode、API key 路线。 - 探索时： 优先定向读文件，不做全仓库扫描。
- 长日志前： 过滤测试输出，或把噪音任务交给隔离 subagent。
- 用 Opus、GPT-5.5 或 Fast mode 前： 问清不确定性是否值得这个 burn rate。
- 图片生成前： 默认它比纯文本 coding turn 更贵。
- 结束后： 记录前后用量和实际产出，而不是只记录模型名。
目标不是让 agent 变保守，而是把高成本上下文花在真正能改变结果的位置。
常见问题
Claude Code 一定比 Codex 便宜吗？
不一定。两者的计划合同、上下文行为、模型选择和计费路线不同。要按具体任务、模型、上下文大小和付款方比较。
Claude Code token 用量在哪里看？
先看 Claude Code 里的 /usage。API 账单看 Claude Console。团队归因要看 analytics 或 OpenTelemetry。
Codex credits 在哪里看？
用 Codex usage dashboard 和 CLI /status 或 /usage。API key workflow 则看 OpenAI Platform billing 和 limits。
Codex 有一个每日 token 上限吗？
没有一个通用每日 token 上限。当前 Codex 用量要按 plan window、模型范围、credits、workspace contract、Fast mode、图片生成和 API key billing 拆开理解。
两个工具最快的省用量动作是什么？
无关任务开新 session、compact 有用历史、routine task 降模型或 effort、关不用的 MCP，并给 agent 精确文件和 stop condition。
额度突然掉得快时应该立刻买 credits 吗？
不应该。先判断是不是巨大上下文、Fast mode、图片生成、工具循环，或临时 provider-side 事件。买 credits 可能只是把真正问题盖住。
**结论：**Claude Code 与 Codex 的用量控制，本质是仪表路由问题。先认清仪表，再缩上下文、选模型，最后才改计费合同。