Frugal Tokens 上线:跨 Coding Agent 成本用量可观测,企业级 Harness 计费基线 2026 年 8 月,开发者 dpc94 在 Hacker News 上发布了一个名为 Frugal Tokens 的开源工具,目标直指当下 AI 开发团队最头疼的问题之一——Coding Agent 的真实成本,究竟花在哪儿。在不到一个月的时间里,该项目获得了 37 分、10 条评论
Frugal Tokens 上线:跨 Coding Agent 成本用量可观测,企业级 Harness 计费基线
2026 年 8 月,开发者 dpc94 在 Hacker News 上发布了一个名为 Frugal Tokens 的开源工具,目标直指当下 AI 开发团队最头疼的问题之一——Coding Agent 的真实成本,究竟花在哪儿。在不到一个月的时间里,该项目获得了 37 分、10 条评论的热度,演示站 `demo.frugaltokens.com` 与 GitHub 仓库 `dpclark4/frugal-tokens` 同时上线。它的核心价值,不是给出一个新的 Coding Agent,而是让团队第一次真正看见自己每天在 Claude Code、Codex、Cursor 等 Agent Harness 上烧掉了多少钱、为什么烧、怎么烧。
这是企业级 AI 落地过程中一个绕不开的命题:没有可观测的计费基线,就没有可治理的成本结构。
一、从一个开发者的好奇心说起
dpc94 在帖子中写道,自己最初只是想弄明白一件事:同一个 Coding Agent,不同人的月度账单差好几倍,差在哪里?他注意到社区里有人晒每月 200 美元的账单,有人只花 20 美元——同样的工具、同样的模型,开销却差了十倍。
这种好奇心驱动的追问,正是任何可观测工具诞生的起点。传统的 IDE 成本仪表盘只告诉你"这个月花了多少",但不会告诉你"这 1000 美元里,有多少是 cache miss 导致的重复计费,有多少是长 session 累积的上下文,有百分之多少本来可以用更便宜的模型跑完"。
于是 dpc94 写了 Frugal Tokens。这个工具基于 Deno 运行,一条命令启动,本地解析 Coding Agent 的会话日志,输出四个层面的可视化:
- 整体用量视图:跨所有 session 累计的 token 消耗、估算的工作时间、重叠 session 的分布。
- 成本归因视图:钱花在哪类模型上、花在哪个调用环节,以及 cache miss 在总成本中的占比。
- session 级别指标:每个 session 的 token 使用百分位,让你看到"我的 session 是偏贵还是偏省"。
- 单次调用探查器:点进任意一个 session,可以看到每一次模型调用的输入输出、tool 调用记录,以及"如果换成另一家的定价,这笔钱会是多少"的对比。
- 上下文累积策略:长 session 是怎么管理历史消息的,有没有自动压缩,有没有去重,有没有主动丢弃过期 tool 输出。
- 缓存命中率:Anthropic 官方在 Prompt Caching 公告中给出的基线是,缓存命中(读)只需基础输入价的 10%,写入则需 125%(基础价的 25% 溢价)。如果 Harness 没有合理设计缓存 key、没有对齐 Anthropic 的 5 分钟窗口或 1 小时窗口,那么 cache miss 就会把成本直接推上去。
- 子 Agent 派生方式:很多 Coding Agent 在需要时启动子 Agent 续写,但每次子 Agent 启动都是一次全新会话,缓存全丢,dpc94 在 Frugal Tokens 的评论区里特别指出这一点,认为这是企业级用户最容易忽视的成本放大器。
- 当前 Harness 的 cache hit ratio 是多少?
- 哪些任务类型最容易触发 cache miss?
- 是否在 prompt 前后顺序上做了对齐,以最大化 Anthropic 5 分钟 / 1 小时窗口的复用?
- 子 Agent 派生是否会破坏父 session 的缓存?
最后一项尤其关键——它内置了跨厂商定价比较器,以及在 Anthropic 模型上对 5 分钟与 1 小时两种缓存窗口的成本对比。这意味着,用户不仅能看到"现在花了多少",还能看到"如果改一下策略,理论上能省多少"。
二、为什么这件事必须做
如果说 Frugal Tokens 解决的是"个人开发者看清账单"的问题,那么 The New Stack 在 2026 年 9 月初发表的《Hermes、Claude Code 与 Codex 跑了同一模型,token 用量差了 70 倍》一文,把这个问题的严重性推到了企业级。
文章披露了一项对照实验:在同一个任务、同一个底层模型、同一组输入条件下,三个主流 Agent Harness(由 Hermes、Claude Code、Codex 提供)产出的最终 token 消耗,最高与最低相差 70 倍。这意味着什么?意味着企业 IT 负责人在做 Coding Agent 选型时,如果只盯着"哪个模型最聪明",完全不看 Harness 的成本曲线,就会在不知不觉中把本该是 1 万美元的月度账单,烧成 70 万美元。
差距从哪里来?答案藏在 Harness 的工程细节里:
Frugal Tokens 之所以选择把 cache miss 单独拎出来作为核心指标,正是因为这个维度直接对应到 Anthropic 官方公布的 90% / 85% 折扣空间。换句话说,把 cache miss 占比打下来,几乎就等于把账单砍掉一大块。
三、企业 Harness 计费基线:三个绕不开的支柱
基于上面这两份一手素材,可以提炼出企业级 Coding Agent 计费基线的三个支柱。它们是任何想要把 AI 编程纳入正式采购流程的团队,都必须先回答的问题。
3.1 缓存命中率是首要成本变量
Anthropic 官方在 Prompt Caching 产品页明确写道:写入缓存需要比基础输入价多付 25%,而读取缓存内容只需基础输入价的 10%。换算下来,一次缓存命中等于 1/10 价,一次缓存未命中等于 1.25 倍价,两端价差 12.5 倍。
这不是一个可以忽略的数字。当一个企业 Coding Agent Harness 每天跑 100 万次模型调用,如果其中 30% 应该是 cache hit 但实际 miss,这部分成本立刻就被放大了 8 倍以上。Frugal Tokens 之所以把 cache miss 放在成本归因视图的第一位,正是因为这是可干预空间最大的杠杆。
企业部署时,需要明确回答:
3.2 session 长度与上下文累积是隐性放大器
dpc94 在帖子里提到,他未来的一个研究方向就是"什么样的工作流最容易把 session 推得更贵":长 session、高上下文使用、多轮反复。这与 Anthropic 在公告里给出的建议一致——他们早期客户里,有人把整本知识库塞进 prompt 实现了高命中,有人则因为每轮对话都把历史全部重发而账单失控。
在企业实践中,context window 不是越大越好。一个 200K context window 的模型,如果 Harness 没有主动做摘要压缩、没有按需丢弃过期 tool 结果,那么"我有钱用得起大窗口"反而会变成"我有钱可以多烧几倍"。Frugal Tokens 的 session 级别百分位指标正是为此而设——它告诉你,你的 session 在所有用户里属于贵的那 10%,还是省的那 10%。
3.3 模型分层路由是结构性成本控制
Frugal Tokens 的另一个能力是"换模型重算"——它能告诉你同一段 session 如果用别的模型定价会变成多少。这并不是让企业去挑最便宜的模型,而是揭示一个更深的命题:不同任务类型,本来就不应该用同一个模型。
简单 FAQ 类的问题,跑在最贵的推理模型上,这是浪费;复杂的、需要长链推理的代码重构任务,跑在最便宜的小模型上,这是冒险。Frugal Tokens 的对比视图给企业 IT 的启示是,在 Harness 层面就应该内置一个"按任务分级路由"的策略层,把成本结构从"一刀切"改成"按需分配"。
这与 Anthropic 自己在文档中提到的"为不同 prompt 选择不同缓存窗口"思路一致——计费基线不是单点优化,而是路由策略。
四、从可观测到可治理:Frugal Tokens 的真正意义
工具本身只是一个 Deno 命令行工具,但它解决的是企业 AI 落地中的结构性命题:当 Coding Agent 从个人玩具变成团队基础设施,你就必须把它当作生产系统来治理。
生产系统有三件事是绕不开的:日志、监控、成本归因。前两件事在传统软件工程里早就有了成熟的工具链(Prometheus、Grafana、ELK),但第三件事——AI 时代的成本归因——直到 2026 年才有了第一个真正意义上的开源基线。
Frugal Tokens 填补的不是产品空白,而是治理空白。它让"我这个月 Coding Agent 花了多少钱"从一个需要手工跑账单、翻邮件、问财务的问题,变成了一个 30 秒内能拉出来的数据面板。它让"为什么花了这么多"从一次会议讨论,变成了一个按 cache miss、按模型、按 session 类型分类的归因视图。
更重要的是,它把计费基线这件事放到了桌面。Anthropic 官方给出了 10% / 125% 的缓存定价,The New Stack 给了 70 倍的 Harness 差异,这些数字现在都有了一个工具可以实时验证。企业的 IT 负责人从此有了一个客观依据:不是厂商说什么就是什么,而是"我的 Harness 在我的任务类型下,实际跑出来的成本结构是什么样子"。
五、可观测之后的下一步
当然, Frugal Tokens 本身并不是终点。它解决的是"看清"的问题,但企业真正需要的不只是看清,还有"控制"。从可观测到可治理,中间至少还有三件事要做:
第一,把可观测埋进采购流程。今后任何 Coding Agent 选型,都不能只看演示效果,必须要求厂商提供 30 天 PoC 期间的 token 消耗明细、cache hit ratio、session 长度 P95。这些数字进 RFP,比任何 demo 视频都有说服力。
第二,建立内部 Harness 成本治理规范。哪些任务走哪个模型、哪些场景必须强制开启缓存、子 Agent 派生如何避免破坏父缓存——这些应该写进团队工程规范,而不是留给每个开发者自己摸索。
第三,跨 Harness 的统一账单视图。企业一旦同时引入 Claude Code、Codex、Cursor 等多个 Agent,就会面临"钱分散在多家"的问题。Frugal Tokens 这类工具如果发展出"多 Harness 数据合并"的能力,就会进一步降低治理成本。
六、对国内企业 AI 落地的启示
虽然 Frugal Tokens 是一款面向 Anthropic / OpenAI 等海外 API 的英文工具,但它揭示的命题对国内企业同样适用。国内的 Coding Agent 市场——无论是自研框架还是接入国产大模型——都会面临同样的成本放大问题:上下文累积、缓存设计、子 Agent 派生策略。
如果一家企业正在评估"自研 Agent Harness"还是"采购现成方案",Frugal Tokens 给出的判据非常清晰:没有可观测的成本数据,任何关于"性价比"的讨论都是空中楼阁。先把基线工具跑起来,把 PoC 期间的真实数字拿到手,再谈选型。
这也是为什么这类工具在 2026 年集中爆发——它不是技术爱好者的玩具,而是 AI 编程从"尝鲜"走向"常态化"之后的必然产物。当 Coding Agent 每天都在消耗真金白银的时候,每一笔花销都该是可追溯、可归因、可干预的。
结语
Frugal Tokens 上线的意义,在于它把 Coding Agent 的成本治理,从"厂商说了算"拉回到"用户看得见"。结合 Anthropic 官方公布的缓存定价基线,以及 The New Stack 给出的 70 倍 Harness 差异,企业级 AI 落地的下一道必答题已经清晰:不是模型够不够聪明,而是 Harness 够不够透明。
这也是任何严肃的 AI 工程化项目都必须迈过的一关——成本可观测,是规模化采购的前置条件。而 Frugal Tokens 这样的开源工具,正是把这道门槛,第一次放到了每一个开发者的桌面。