Codex Usage Tracker：把本地 Codex 用量从黑箱变成可查询账本

这段时间本地 AI 编码工具有一个越来越真实、但很少被认真处理的问题：

你知道自己在用 Codex，却不一定知道自己的配额究竟是怎么被吃掉的。

很多时候，真正让 token 和 credits 快速流走的，不是一次明显的大任务，而是这些细碎又持续的因素：

某条线程上下文已经膨胀到不再划算；
某个模型缓存复用很差；
某些 auto-review、subagent 或长聊天在后台持续烧额度；
你知道“最近用得很多”，但说不清到底是哪几个项目、哪几段会话最贵。

今天想记下的 douglasmonsky/codex-usage-tracker，就是一个专门解决这类可观察性问题的小项目。

按 GitHub 仓库页、release 页和 README 在 2026-06-30 能看到的公开信息，这个项目当前约有 133 stars、8 forks，创建于 2026-05-17，最近公开更新出现在 2026-06-30。仓库主语言是 Python，许可证为 MIT。最新 release 是 v0.12.0，发布时间为 2026-06-29。

项目概览

属性	详情
仓库	douglasmonsky/codex-usage-tracker
定位	面向本地 Codex 使用数据的 dashboard、CLI、MCP 工具与配套 skill
Stars	133
Forks	8
主语言	Python
创建时间	2026-05-17
最近公开更新	2026-06-30
最新版本	v0.12.0
版本发布时间	2026-06-29
许可证	MIT
运行形态	本地 SQLite + localhost dashboard + CLI + MCP

它不是“又一个 agent”，而是给 Codex 补一层账务可见性

README 开门见山写得很清楚：这是一个 local-first dashboard、Codex plugin 和 companion skill，用来理解你的 Codex token 和 usage credits 到底流向了哪里。

它的思路并不复杂，但非常务实：

读取你机器上 Codex 已经写出的 JSONL 日志；
把聚合后的用量计数索引进本地 SQLite；
提供 dashboard、CLI、MCP 工具和配套 skill；
让你回答“哪条线程最贵”“哪种模型最费”“哪些 subagent 在持续耗用量”这类本来很难追的问题。

这类工具的价值不在于“让 agent 更聪明”，而在于让使用者终于有办法对自己的 AI 开销做事后审计和过程排查。

它抓住的是一个很新的开发痛点：AI 编码开始需要运营视角

过去我们在调服务器、数据库、CI 或 API 网关时，很自然会要求可观察性。

但轮到本地 AI 编码工具，很多人仍然停留在“能跑起来就行”的阶段。于是会出现一个很奇怪的局面：

你每天都在和 agent 协作；
你能看到局部对话；
但你看不到一周下来真正的消耗结构。

README 对这个问题的描述很准确。它明确提到，Codex 的消耗可能会悄悄来自：

long-running chats；
low cache reuse；
reasoning spikes；
spawned subagents；
auto-review passes。

换句话说，这个项目面对的不是“某次请求多少钱”，而是 本地 AI 工作流整体的资源画像。

四个 dashboard 视角，比“只看总数”更有用

这个项目好的一点，是它没有停留在一个总额面板。

README 里列出的 dashboard 视图包括：

Insights
Calls
Threads
Diagnostics

这套拆分很合理。

Calls 适合你追某一笔具体开销，去看精确的 token accounting、cache 变化和运行时证据；Threads 适合把长对话、subagent 和自动 review 当成一个工作会话来理解；Insights 更像是一个快速分诊层，把高成本线程、低缓存复用、上下文膨胀这些风险先拎出来；Diagnostics 则进一步把命令、Git 交互、文件读取、文件修改、usage-drain 报告等信息汇总出来。

这意味着它不是在告诉你“你昨天花了多少”，而是在帮你追问：

贵的是哪条线程；
贵在哪个阶段；
是不是缓存失效造成的；
是不是某种工作习惯在持续拉高成本。

本地 CLI、MCP 和 companion skill 让它不仅能看，还能被脚本化

我觉得这个项目另一个值得注意的点，是它没有把 dashboard 当成唯一入口。

README 给出的常用命令包括：

codex-usage-tracker summary --preset last-7-days
codex-usage-tracker query --since 2026-06-01 --min-credits 1
codex-usage-tracker session <session-id>
codex-usage-tracker export --output usage.csv
codex-usage-tracker open-dashboard

另外，安装流程里还专门包含：

本地 dashboard；
Codex plugin；
MCP tools；
companion skill。

这件事很关键，因为真正会长期使用这类工具的人，通常不会只满足于“偶尔点开网页看一下”。他们更可能会想：

把 usage 统计塞进自己的复盘流程；
让 Codex 自己协助解释本周为什么消耗异常；
把本地 aggregate 数据导出给别的脚本继续分析。

这时，CLI 和 MCP 层就不再是附属品，而是让它进入日常工作流的关键。

它对隐私边界的处理，比很多“分析工具”更克制

这也是我最愿意记下来的部分。

README 反复强调，这个项目默认只存 aggregate metrics，而不会把这些内容写进 SQLite、CSV 或生成的 dashboard HTML：

prompts；
assistant messages；
tool output；
pasted secrets；
raw transcript snippets；
raw context。

即便要看运行时上下文，也是在明确点击之后，按需读取单个原始 JSONL，并且会做常见 secret pattern 的脱敏和文本大小限制。

这代表作者的取向很明确：

不是把日志再复制去另一个黑箱；
不是把“观察能力”建立在更大规模的数据留存上；
而是尽量用聚合统计先解决大部分分析问题。

对一个处理本地 AI 对话日志的工具来说，这种克制比花哨更重要。

它其实也在补一块“本地 AI FinOps”空白

如果把视角再拉高一点，这个项目有意思的地方还在于，它已经有点像 面向个人开发者和小团队的本地 AI FinOps 工具。

当然，它现在还没有企业账单系统那种组织级治理能力，也不是跨平台的统一成本平台。但它已经开始认真回答几个以前没人管的问题：

哪些线程最不划算；
哪些项目上下文最容易失控；
哪些使用方式会拉低缓存收益；
哪些会话值得归档、拆分或重新开新线程。

很多人谈 agent 协作时，会讨论提示词、模型、IDE 集成或自动化深度。Codex Usage Tracker 处理的却是另一个更接地气的问题：

当 AI 编码真的成为日常成本项之后，个人开发者该怎么给自己做账。

它适合谁

我觉得这个项目尤其适合这些人：

已经高频使用 Codex，本地会积累很多线程和日志的人；
开始在意 credits、token、缓存命中和上下文膨胀的人；
想保留本地优先和隐私边界，不想把日志上传到第三方的人；
希望把 usage 分析纳入 CLI、脚本或 MCP 工作流的人。

如果你只是偶尔开一两次 Codex，会觉得它略重，因为它的价值建立在“持续使用之后的可观察性”上。

但如果你已经进入每天都和 coding agent 协作的阶段，它解决的问题会越来越真实。

当然，它也有明确边界

README 也写得很坦白：这是一个 unofficial project，并不是 OpenAI 官方产品。

这意味着你应该把它理解为：

一个围绕本地 Codex 日志做观察和分析的独立开源工具；
不是官方计费后台；
不是跨所有 AI coding 产品的通用账单标准。

不过恰恰因为它没有试图变成“大而全”的平台，反而显得很聚焦：先把本地 Codex 使用分析这件事做到真正可用。

小结

douglasmonsky/codex-usage-tracker 最值得看的，不是“又一个和 agent 沾边的仓库”，而是它选中的问题非常现实：

你已经在用 Codex；
你的消耗已经开始变复杂；
但你还缺少一块像样的本地观察面。

它用相对克制的方式，把 JSONL 日志、SQLite 聚合、dashboard、CLI、MCP 和 companion skill 串了起来，补上了这块空白。

如果说很多 AI 工具在解决“如何让 agent 更能做事”，那么 Codex Usage Tracker 在解决的是另一个迟早会到来的问题：

当 agent 已经足够常用之后，开发者该如何真正看懂自己的使用成本。