HN 上这两天出现了一个小项目 Budi，标题很直白：local-first AI coding cost tracker。它的 GitHub README 说得更具体：Budi 用来追踪 Claude Code、Cursor、Codex CLI、Copilot CLI 和 Copilot Chat 的 token 与成本，并按 repo、branch、ticket、file 做归因，默认数据都留在本机；可选的云同步只上传聚合后的日报指标，不上传 prompt、代码和回复。项目还很年轻，GitHub stars 只有十几个，但最近提交就在 2026 年 5 月，README、Homebrew tap、Cursor/VS Code 扩展和文档都已经成体系。所以我不会把它包装成“成熟企业级平台”，但它抓住了一个真实问题：AI 编程正在从个人效率工具，变成需要治理的工程基础设施。

这件事比“又一个成本看板”重要。

过去我们管云成本，有 FinOps；管服务质量，有 APM；管模型调用，有 LLM gateway 和 tracing。可 AI coding agent 的调用链很奇怪：它发生在开发者本地，混在编辑器、CLI、终端和 IDE 插件里，很多时候并不经过公司统一网关。你当然可以强推所有请求走代理，但这会碰到权限、延迟、离线开发、个人账号和隐私边界等一堆问题。Budi 的路线反过来：不拦在网络路径上，而是读本地已经存在的 transcript / JSONL / SQLite / session-state，再从这些记录里还原 token、模型、时间、项目上下文和成本。

用人话说，它不是收费站，更像电表。

Budi 官网把这个卖点写得很清楚：安装后本机跑一个小 daemon，tail AI 工具已经写到磁盘的 transcript；编辑器里显示状态栏；CLI 用来做 repo、branch、ticket 级别的归因；“Nothing in your network path”。这句话其实是架构取舍的核心。走网络代理的好处是数据完整、控制力强，可以做限流、审计、脱敏和统一 key 管理；坏处是部署重、侵入强，还可能成为单点故障。走本地日志解析的好处是轻、隐私边界清晰、不中断开发者原有工作流；坏处也明显：不同工具日志格式会变，成本估算依赖 pricing manifest，某些 provider 的真实账单可能需要后续 API reconciliation。

所以 Budi 的价值不是“绝对准确地替代云账单”，而是给开发过程补上一个过去缺失的观测层。

我比较看重它的三个细节。

第一个是归因粒度。很多 AI 工具只能告诉你“今天花了多少钱”，这对工程管理几乎没用。真正有用的问题是：哪个 repo 花得最多？哪个 feature branch 正在异常烧钱？某个 ticket 是因为反复改测试、上下文膨胀，还是因为模型选得太贵？Budi README 里的命令包括 budi stats projects、budi stats branches、budi stats tickets、budi stats models、budi stats files，这说明它不是单纯记账，而是试图把 AI 使用成本映射回研发对象。这个方向对团队很关键，因为成本只有绑定到工程单元，才有优化空间。

举个例子，如果一个团队发现“修 checkout retry 的分支过去 7 天烧了 40 美元”，这不一定说明开发者乱用 AI。它可能说明这个模块上下文太大、测试反馈太慢、需求描述反复变化，或者 agent 每次都在重新扫描整套代码。成本异常往往是工程摩擦的信号。说白了，AI 账单有时不是财务问题，而是架构问题。

第二个是 session health。Budi README 提到它会检测 context bloat、cache degradation 和 cost acceleration。这里我会稍微谨慎一点：这些指标是否足够准确，要看它对各家 transcript 的解析深度和启发式规则，不能只看 README 就下结论。但思路是对的。AI coding 的浪费不只是“用了贵模型”，更常见的是会话越拖越长，agent 带着过期上下文反复推理，缓存命中下降，最后每一步都变成高价全量请求。很多开发者体感上会说“今天 Claude 变笨了”，但背后可能只是上下文污染和任务边界失控。

这也解释了为什么我之前写 Claude Code routines 时一直强调流程约束。AI 编程不是把一个超大 prompt 扔给模型就完事，越复杂的任务越需要分段、验收、回滚和上下文清理。Budi 这类工具如果能把“上下文膨胀导致成本加速”可视化，就能把很多玄学抱怨变成工程讨论：不是“模型不行”，而是“这个会话已经不健康”。

第三个是 local-first 的隐私边界。Budi 文档说本地数据存放在用户目录，daemon 读取 agent 已经写到磁盘的 transcript，只保存派生分析：时间戳、token count、模型名、成本和归因标签；prompt、代码和回复不会存储或上传。可选 cloud sync 只发数字聚合、模型名、hashed repo ID、branch 和 ticket ID 等。这个设计很讨巧，因为 AI coding 的原始数据太敏感了：prompt 里可能有客户信息，回复里可能有内部代码，diff 里可能有未发布功能。对企业来说，“成本可见”和“源代码不出本机”必须同时成立，否则工具很难推广。

当然，local-first 不是免死金牌。

只要工具读取 transcript，它就处在敏感数据旁边。哪怕它声称不保存 prompt，团队也要看清楚实现：日志扫描范围是什么？本地数据库里到底落了哪些字段？崩溃日志会不会带原文？云同步 schema 是否稳定？开源项目的好处是可以审计，但这不等于默认安全。尤其 Budi 目前还处在早期阶段，生产落地性待验证。我会把它当作一个值得试点的工程工具，而不是立刻纳入全公司强制标准。

如果你已经在做统一 LLM 网关，可能会问：这类工具和 gateway 是不是重复？我觉得不重复。网关擅长管理线上服务和 API 入口，比如统一鉴权、计费、重试、缓存、审计、模型路由。我们之前分析 GoModel 这类 AI gateway 时，重点就在服务端模型调用的治理。但 AI coding 的入口太分散：IDE 插件、CLI agent、个人订阅、企业账号、离线日志，未必都能进网关。Budi 这种本地观测层可以作为补位：它不负责拦截和治理所有请求，而是先回答“到底发生了什么”。

我会这样判断适用场景：

如果你是个人开发者，每月 AI coding 费用已经超过几十美元，Budi 这类工具可以帮你发现最烧钱的项目和模型，但收益未必大到必须安装。你可能更需要的是良好的使用习惯：任务拆小、及时新开会话、别让 agent 在大仓库里无目标搜索。

如果你是 5 到 50 人的工程团队，而且已经让 Claude Code、Cursor、Codex 混合进入日常开发，那成本观测就很有价值了。这个阶段最怕的是管理层只看到总账单，看不到具体工程上下文，最后用粗暴限额把效率也一起砍掉。按 repo/branch/ticket 看成本，至少能让讨论变得具体：哪些任务适合 agent，哪些任务需要人工先整理上下文，哪些仓库需要补文档和测试入口。

如果你是强合规企业，我会更保守。Budi 的 local-first 思路适合做 PoC，但在推广前要审计源码、固定版本、确认本地数据字段、禁用或托管 cloud sync，并把它纳入终端安全策略。别因为“它不在网络路径上”就忽略本地数据治理。很多安全事故不是发生在网关，而是发生在开发者机器上的缓存、日志和插件目录里。

还有一个容易被忽略的问题：成本数据会改变团队行为。指标一旦出现，大家就会优化指标。有的优化是好事，比如减少无效长会话、选择更便宜的模型、把重复任务脚本化；有的优化可能是坏事，比如开发者为了账单好看而不用 AI，或者把复杂任务拆得过碎导致协作成本上升。所以我不建议把 AI coding cost 做成个人排名。更合理的看法是把它当作系统健康信号：哪类任务消耗异常？哪些仓库对 AI 不友好？哪些流程让 agent 反复试错？

这也是我喜欢 Budi 这个选题的原因。它没有发明新模型，也没有讲宏大的 AGI 故事，但它指出了 AI 工程落地的一条现实路径：当 agent 从玩具变成生产力工具，围绕它的可观测性、成本归因和隐私边界会变得和模型能力一样重要。

我对 Budi 的短期建议很简单：可以试，但别神化。它是早期项目，stars 不高，生态覆盖仍在变化；不过它有真实代码、活跃提交、清晰 README 和具体安装路径，已经足够作为团队内部试点。试点时最好先选 2-3 个 AI 使用频繁的 repo，运行一到两周，看三个指标：每个 repo 的 AI 成本分布、异常长 session 的比例、不同模型/工具的成本差异。只要它能让团队少开几次无意义的超长会话，或者发现一个特别烧钱的工作流，就已经值回票价。

AI 编程的上半场是“能不能帮我写代码”。下半场会越来越像传统工程管理：能不能被观测，能不能被归因，能不能被治理。

Budi 不一定是最终答案，但它把问题问对了。

参考链接

• Budi 官网：local-first AI coding cost tracker
• Budi GitHub 仓库
• Budi README
• Budi Cursor / VS Code 扩展仓库