Codex 用量
Codex Token 用量怎么看？先分清输入、缓存输入和输出
只看“剩余百分比”很容易误判。先把一次任务的输入、可缓存上下文、输出和工具日志分开，才知道优化应该落在哪里。
- 个人观察
- 同样一句提示，在上下文很长的会话里，体感用量可能明显高于新会话。
- 已核实
- OpenAI 定价与使用说明区分输入、缓存输入和输出；Codex 计划内额度会受任务复杂度等因素影响。
- 适用边界
- Codex 界面和额度展示可能更新，本文不把任何按钮位置或套餐数字写成永久规则。
先看结论
- 产品显示的额度变化不是精确的单次 Token 账单。
- 长上下文和工具输出通常比一句短提示更值得检查。
- 比较任务时要固定模型、推理强度、仓库起点和验收标准。
一次任务的用量账本
- 01输入
- 02缓存输入
- 03模型输出
- 04工具日志
先确定你看到的是什么
Codex 可能展示会话状态、计划用量或周期剩余量。这些信号适合判断趋势，但不一定等于某个任务的精确 Token 明细。API 账单、ChatGPT 计划额度和本地 CLI 会话也不是同一计量场景。
因此记录时先写明入口、模型、日期和任务。不要把计划剩余百分比直接换算成 API 成本，也不要用一次异常波动推断模型永久变贵。
三类用量怎样理解
输入包括提示、仓库指令、读取的文件以及会话中仍在上下文里的内容。缓存输入是服务能够复用的相同前缀；稳定的指令放在前面、变化的任务放在后面，更有利于复用。输出是模型生成的解释、补丁和计划。
工具命令的日志虽然不是模型输出本身，却会作为新的上下文被模型阅读。完整构建日志、重复测试成功行和一次性大文件，常常是最容易控制的噪音。
- 记录输入材料：文件、日志和粘贴内容。
- 记录工具输出规模，而不只记录提示长度。
- 记录是否发生 compaction、新会话或大范围重新读取。
建立一个可比较的用量账本
每次只记录少量稳定字段：任务、提交起点、模型与推理强度、开始和结束用量、工具次数、测试次数、耗时、失败与返工。连续记录同类任务，比追逐某一次漂亮数字更有价值。
当用量上升时，按顺序检查范围是否扩大、读取是否失控、日志是否重复、会话是否混入多个主题，再考虑换模型或压缩上下文。这样优化的是工作流，而不是猜测。
rootchen 的记账原则
我更愿意记录“这一类任务通常怎样消耗”，而不是每天盯一个剩余百分比。趋势能指导决策，单点数字很容易制造焦虑。