近 30 天 AI 编程助手 token 使用量记录

统计区间：2026-07-13 至 2026-08-11Claude Code 和 Codex 合计约 222.1 亿 token。这里的 token 是客户端记录的处理量，包含缓存读取和推理 token，并不等同于新输入或最终生成的文字量。

最近想知道自己过去一个月到底用了多少 AI 编程资源，于是把 Claude Code 和 Codex 的本地用量记录汇总了一下。这篇文章只做一个简单记录：用了多少、主要用在哪些模型、集中在哪几天，以及按公开 API 单价折算时大致是什么量级。

30 天总量

按 30 个自然日平均，每天约 7.4 亿 token。不过实际用量并不均匀：这个区间内有 17 天出现了明显用量，按活跃日算，平均约 13.1 亿 token。

图｜每日 token 用量，按模型堆叠

用量集中在少数几天

30 天里，用量最高的两天分别是：

两天合计约 111.8 亿 token，刚好占总量的一半。其余约 110.3 亿 token 分布在另外 15 个活跃日里。

所以这个月的使用状态不是“每天稳定地用一点”，而是很明显的任务型分布：少数几天有较大的集中处理量，其余时间相对平缓。

图｜按模型细分的用量与名义成本

模型层面，gpt-5.6-sol 的用量约 146.6 亿 token，占总量的 66%，也是 Codex 侧的主要模型。

Claude Code 侧主要由两个 Opus 模型构成：opus-4-8 约 35.2 亿，opus-5 约 32.6 亿，两者合计约占总量的 30.5%。fable-5 和 sonnet-5 的用量相对较少，合计不到 4%。

从这个分布看，过去 30 天的主要用量基本集中在三个模型上：gpt-5.6-sol、opus-4-8 和 opus-5。

这部分不是实际账单，只是把本地记录的 token 按公开 API 单价换算，作为工作量的另一个参考维度。

Codex 的用量约为 Claude Code 的 1.94 倍，主口径下的名义成本约为 1.71 倍。两边每百万 token 的折算成本处在接近的区间。

图｜平台单位成本对比

按天看，名义成本的峰值与 token 峰值基本重合。7 月 15 日和 8 月 6 日既是用量最高的两天，也是折算成本最集中的两天。

图｜每日名义 API 成本，按模型堆叠

成本构成里，缓存读取占了很大比例。Claude Code 侧的缓存读写合计约占 86%；Codex 可见记录中的缓存读取约占 56%，但客户端没有记录缓存写字段，因此这一侧的折算值只按可见数据计算。

图｜名义 API 成本构成

这个数字看起来很大，但不能把它理解成“输入或生成了 222.1 亿字”。编程助手在多轮任务中会反复读取已有上下文，缓存读取也会计入 token；推理模型还有一部分不会直接展示给用户的推理 token。

以 Codex 为例，这段时间的缓存命中率约为 95.1%。也就是说，大部分 token 来自既有上下文的重复读取，而不是每次都加入了同等规模的新内容。这也是长会话、多步骤任务和并行任务很容易产生大规模 token 用量的原因。

因此，这个统计更适合表示：模型在这 30 天里一共处理了多大规模的上下文与推理工作，而不是我实际写了多少字或收到了多少字的回复。

这是一份基于本地客户端记录做出的估算，不是 API 账单。Codex 数据来自本地会话记录，Claude Code 数据来自本地统计缓存；两边的记录方式并不完全一致，因此总量更适合作为量级参考，而不是精确到每一个 token 的审计结果。

统计终点统一到 2026-08-11，以保证两个平台使用相同的日期区间。名义 API 价按照统计时点的公开价格折算；Codex 缺少缓存写记录，Claude Code 的统计口径则可能包含重复计数，因此成本数字也只作为参考。