🌈个人主页:一条泥憨鱼(欢迎各位大佬莅临)

🎬精选专栏:数据结构与算法，Java ,AI与Agent

前言：

Token 消耗量的统计是怎么做的？

方法不值钱——让你正在用的 AI Agent 直接读本机日志，按天把用量汇总，吐一个离线 HTML 出来就行。你不用自己翻文件，也不需要看懂日志格式。

把下面这段提示词丢给 Codex、Claude Code、Cursor、Trae、WorkBuddy 之类能操作本地文件的 Agent，它自己会搞定。

出来的页面就是一张日账本。

页面上有累计 Token、今天消耗、日均、活跃天数、近 14 天走势、按工具的分布，以及每天的明细。数字超过一万自动转成"万"，过亿转成"亿"——不用盯着数零。每天的数据还能拆开看 Codex、WorkBuddy 分别花了多少。

整个过程中没有数据离开过你的电脑。扫描脚本读本地日志，结果写到一个 JSON 文件里，HTML 页面再读这个 JSON。原始对话不会出现在页面中。

它到底在统计什么。

不同 AI 工具在电脑上留下的痕迹不一样。Codex 存的是 JSONL 会话文件，WorkBuddy 是 trace，其他工具可能是 JSON、本地数据库，或者干脆写进应用日志里。

Agent 要找的就四样：时间、输入 Token、输出 Token、缓存和总量。

有一个坑。

有些工具记的不是单次请求的 Token，而是这条会话从开始到现在的累计值。如果你直接把每条记录相加，数字差不多能翻十倍。正确的做法是按时间排序，每条用后一条的累计减去前一条，得到这段时间里真正新增的量。

另外别拿页面上看到的数字去对账单。不同模型、套餐、厂商的计价方式不一样，缓存 Token 的计算逻辑也各有各的。这张表帮你看的是自己的用量习惯和工具分布，金额对不上是正常的。

Token 里藏着的作息。

后半部分也不是 AI 读完聊天记录猜我工作多久——它看的还是同一批日志里的时间。

Codex 的每条 Token 事件都带着时间，WorkBuddy 的 trace 有 startedAt 和 endedAt。拿到这些时间，换算成本地时区，铺到一天的刻度上，大致就能看到 AI 在什么时段最忙。

算法不复杂：

- 先把 Token 活动按日期归类
- Codex 当天有 Token 记录的那份会话 JSONL 算 1 个"记录单元"，WorkBuddy 一条完成的 trace 也算 1 个
- 单个 Token 事件默认占 5 分钟，中间隔不超过半小时的活动就往一块合并。合并完取个最早和最晚，就是当天大概的 AI 活跃时段
- 按小时汇总 Token、事件和记录单元，高峰小时和并发数就出来了

所以页面上写的"AI 活跃 3 小时"，意思是这 3 小时里电脑上持续有 AI 活动——不是说我在屏幕前坐了 3 小时。同理，看到"今天 18 条记录"也不用往业务上套。一条 Codex 会话里可能藏着几十轮对话加代码修改、搜索和子代理，一条 WorkBuddy 工作流也可能调很多次模型。

目前这套统计能从元数据里直接读到一些标签，不用碰正文：

- 来源是 Codex 还是 WorkBuddy
- Codex 这边：Desktop 还是 CLI、主会话还是子代理或自动化、工作区目录名、用了什么模型、有没有代码修改/搜索/MCP
- WorkBuddy 这边：Agent 类型、模型、完成还是报错
- 每天的工作时段、高峰小时、记录单元数、并发数

但它没法判断"这段是在写文章还是在修 bug"。这些信息通常藏在用户消息、会话标题或 trace 正文里。默认版不读也不存这些内容——页面上显示的是真实能拿到的元数据标签，不会硬塞一个"任务类型"上去。

跑通的工具，和还没适配的。

我自己的电脑上 Codex 和 WorkBuddy 已经正常读到了：

┌───────────┬────────────┬────────────────────────────┐
│   工具    │   读什么   │            注意            │
├───────────┼────────────┼────────────────────────────┤
│ Codex     │ 会话 JSONL │ 可能是累计用量，要算增量   │
├───────────┼────────────┼────────────────────────────┤
│ WorkBuddy │ trace 记录 │ 按任务结束时间汇总总 Token │
└───────────┴────────────┴────────────────────────────┘

Claude Code、Cursor、Trae、CodeBuddy 理论上同一套方法都能处理。但不同版本、不同系统下目录结构、字段名、格式都可能不一样。

所以提示词里我会让 Agent 先出一份"数据源探测报告"：找到了哪些文件、有哪些字段、能不能确认是 Token 数据。我确认之后它才继续写统计逻辑。找不到就标"未适配"，不编数字。macOS 和 Windows 都是用户目录起步探测，不写死路径。

提示词直接复制。

嗯，放在最后了。先用这个让 Agent 出一份探测报告，你看看它找到了什么，确认没问题再让它往下走。

复制这段发给你常用的 Agent：

▎ 请在我的电脑上帮我做一个"本地 AI Token 账本"。目标是统计我每天使用 AI 工具的 Token 量，生成一个可离线打开的 HTML 页面；数据只保存在本机，不上传任何服务器。
▎
▎ 请优先适配 Codex、WorkBuddy，同时检查 Claude Code、Cursor、Trae、CodeBuddy 是否存在可用的本地使用记录。不要假设工具目录、字段或数据格式固定，必须先探测再实现。
▎
▎ 先做"数据源探测报告"，暂时不要改文件。报告请列出：
▎ 1. 发现的候选目录和文件；
▎ 2. 每种文件中的时间字段；
▎ 3. Token 字段，包括输入、输出、缓存、总量；
▎ 4. 这些 Token 是单次记录，还是会话累计值；
▎ 5. 哪些工具能确认支持，哪些工具需要我补充文件样本。
▎
▎ 探测报告经我确认后，再开始实现。实现时必须遵守：
▎ 1. 只读取本机数据；不要调用外部 API、创建账号、上传 Webhook、下载未知二进制、安装常驻后台服务。
▎ 2. 不要把原始对话、提示词、项目路径、密钥、账号信息写入任何输出文件。最终只保留按日聚合后的数字。
▎ 3. 如果日志保存的是会话累计 Token，必须按时间排序，计算相邻记录的增量；不能把累计值逐条相加。
▎ 4. 按本地日期和工具汇总输入、输出、缓存复用、总 Token；某个工具没有对应字段时，如实留空或只统计总量。
▎ 5. 同时根据 Token 事件时间和任务开始/结束时间，生成每天的 AI 工作节奏：首个/最后活动时间、估算 AI 活跃时长、活动片段、每小时 Token 高峰、记录单元数和峰值并发记录单元数。间隔不超过 30 分钟的活动可合并为同一段；单个 Token 事件按 5 分钟处理。明确标注：这是 AI 活动推算，不等于真人实际工时。
▎ 6. 不要笼统把所有记录都叫"任务"。在页面说明统计口径：Codex 的记录单元是一份当天有 Token 活动的会话日志，WorkBuddy 的记录单元是一条完成的 trace 工作流；并发只表示这些记录的活动时段重叠。
▎ 7. 在不读取或保存对话正文、提示词、会话标题、项目完整路径的前提下，尽量显示安全标签：工具来源、入口、工作区目录名、模型、主会话/子代理/自动化、Agent 类型、完成状态、代码修改/搜索/MCP 等行为信号。没有可靠语义时显示"未提供语义标签"，不要猜它在做什么。
▎ 8. 把聚合结果写入项目内可审查的 JSON 文件，例如 data/usage.json。字段至少包括日期、工具名、输入、输出、缓存、总量、活动时段、记录单元、数据来源和最后同步时间。
▎ 9. 生成一个无需服务器的 dashboard.html，双击即可打开。页面显示：累计 Token、今日 Token、日均 Token、活跃天数、近 14 天趋势、按工具分布、AI 工作节奏、每日明细；每日明细可展开查看来源、标签、活动片段和小时高峰。
▎ 10. 数字使用中文直观单位：小于 1 万显示原数，1 万以上显示"万"，1 亿以上显示"亿"；每日明细保留完整数字。
▎ 11. 兼容 macOS 和 Windows：使用用户目录和相对路径。分别提供 macOS 启动脚本，以及 Windows 的 .cmd 和 PowerShell 启动脚本；启动后先同步数据，再打开 dashboard.html。
▎ 12. 某个工具无法确认 Token 字段时，显示"未适配/需要确认"，不要编造数字。
▎
▎ 完成后告诉我：实际支持了哪些工具、每个工具使用的字段和统计口径、哪些工具还需要文件样本、macOS 和 Windows 的运行方式，并展示一次真实同步后的汇总结果。

跑起来。

把提示词发给你最常用的 Agent。第一轮只让它出探测报告，你确认路径和统计方式没问题了，再让它生成脚本和页面。

生成完之后，每次打开启动脚本，它先同步最新数据，再打开 dashboard.html。日账本就出来了。

如果你只用网页版的服务——网页版 ChatGPT、网页版 Claude——没有本地日志可读，这个方法就没有数据源。Agent 会提示没有可用来源，正常，不是你配置错了。

找一台你常用的电脑先跑一遍。看完过去七天的消耗，怎么用的 AI、哪些工具花得最多，会清楚很多。