同样跑编码代理，caveman 的 token 消耗真的只有主流框架的 1/3？

同样跑编码代理，caveman 的 token 消耗真的只有主流框架的 1/3？

【免费下载链接】caveman🪨 why use many token when few token do trick. Viral skill + proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman

"装上 Caveman，AI 回答立省 65% Token""极简架构把 token 压到主流框架的 1/3"——过去几个月，这类标题在技术社区反复刷屏。caveman 顶着"why many token when few do trick"的口号和 100k+ 星标冲上 GitHub Trending 榜首，ThePrimeagen 的第一反应是"这不可能真有用"（No way this actually works）。一个靠让 AI"说人话"来省 token 的插件，凭什么被追捧又被质疑？更值得追问的是：那句"1/3"，到底是怎么测出来的，又适用于什么样的任务？

带着这个问题去翻仓库，会发现一个有意思的事实：caveman 自己比营销号诚实得多。它维护了一整套证据标签体系，明确区分"本地估算（inferred）"与"厂商计费（provider-reported）"，甚至专门写了一份 HONEST-NUMBERS.md 来告诉你在什么场景下要关掉它。本文就基于仓库源码与实测基准，拆解"1/3"这句话的三个组成部分：它省的是输出 token 还是输入 token、在什么口径下成立、以及省下来的 token 换回了什么。

一、先拆口径：这 1/3 省在哪一层

社区里的"token 优化"论述经常把三个完全不同的东西混在一起：

1. 输出 token——模型回答的字符数，由语气/指令控制；
2. 输入 token——每次请求携带的 system prompt、工具定义、历史上下文和文件内容；
3. 计费口径——按 token 计费（Claude/OpenAI 等 API）还是按请求/额度计费（Copilot premium requests）。

caveman 恰好对应前两层，架构上分成两个独立组件（见 product-model.md）：

• 响应技能（skill）：管"模型说什么"。/caveman、/ultracave、/megacave三档语气，只压缩叙述性文字，代码块、路径、错误信息、数字原样保留；
• 本地代理（proxy）+ 压缩引擎（engine）：管"模型读什么"。拦截 agent 到模型的请求，对日志、CSV、JSON、YAML、测试输出等大块工具输出做有损压缩，原始字节存入本地恢复库（CCR），模型需要时可随时取回。

README 开篇那个流传最广的对比就落在第一层：同一个 React 性能问题的回答，正常模式 63 token，/caveman20 token，/ultracave14 token，/megacave（文言文模式）13 token（见 README.md）。这组数字来自 tiktoken o200k 的本地计数，比例关系可信，但它只代表"输出风格"这一层。

二、技能层的真实增益：3%，不是 65%

社区广为流传的"平均削减 65% 输出 token"需要打一个问号。HONEST-NUMBERS.md 白纸黑字写明：早期版本的确用过固定的 65% 输出比例做估算，但那是没有提交评审依据的历史估计，现行报告已不再使用这类est_saved_*字段。现在的官方口径要克制得多。

仓库的评测骨架 evals/README.md 设计了三臂对照，这正是拆穿"1/3 神话"的关键：

为什么要有"简洁指令"这个控制臂？因为新一代模型本来就听得懂"说简洁点"。如果拿 skill 对比无提示基线，等于把"be terse"的功劳也算给了 caveman——早期评测就是这么被高估的。在 claude-opus-5-5 上、10 道开发问题的实测（快照在 evals/snapshots/results.json）：

结论很清楚：模型自带的简洁能力已经砍掉 38%；在此基础上，/caveman只再省 3%（中位数），/ultracave再省 35%。也就是说，"输出层省 65%"是旧口径的虚高，当前真实的中位增益是 3%~35%，取决于你选哪一档语气。

技能本身还倒贴输入成本：规则文本每次请求注入约 1,000 token（README.md）。对一次性的简短问答，固定开销可能反超输出节省——这正是社区 issue #145 实测到的净亏损场景。

三、代理层才是"1/3"真正成立的地方

如果你说的"1/3"指的是整个 agent 会话的输入 token，那么 caveman 的 proxy 层确实拿出了目前最扎实的证据，写在 WRAP-BENCHMARK.md 里：

• 六个不可变的 MCP 工具输出夹具（日志、部署 JSON、欺诈 CSV、测试输出、配置 YAML、仪表盘 HTML），每个 60–95KB；
• 直接 Claude Code 与 caveman 包裹各跑 3 轮，共 54 次 agent 运行、18 对直接对照；
• 全部使用 Claude Code 的modelUsage厂商计费计数器（input + cache_read + cache_creation），不用本地 tokenizer 估计；
• 18/18 次精确答案全对，整场输入 token 从 885,793 降到 591,673，减少 33.2%，按用例聚类的 95% 置信区间为 14.6%~48.5%。

单看每个用例的降幅更直观：

注意最后一行：HTML 目前没有压缩器，技能开销照付、收益为零，于是净结果反而多花了 9.9%。这份基准没有把失败用例藏起来，而是明确标注"未受支持与无操作输入仍计入总体"。文件级单独压缩更夸张：五个压缩器覆盖的格式普遍压掉 98.5%~99.1%（如 28,041 token 的 CSV 变 314），六文件合计 130,611 → 22,994，82.4%（docs/WRAP-BENCHMARK.md）。但文件变小不等于会话变小——每次请求还背着 system prompt、工具定义、对话历史和技能本身。

类似逻辑还出现在其他输入源上：记忆文件（CLAUDE.md之类）经/caveman-compress平均省 46%，五个夹具的标题、代码块、路径全部原样保留（skills/caveman-compress/README.md）；网页快照经caveman browse从 Playwright 的 15,704 token 压到 121 token（129.8×），但小页面反而亏 2.3×（browse/BENCHMARK.md）。"越大块越省"是代理层的规律：压缩器挑形状明确、冗余高的工具输出下手，小页面、短文件、无压缩器格式都是它的输面。

四、省下来的 token 换来了什么

如果只是把回答变短，caveman 不会成为 100k 星的项目。真正让它立住的是三个"不降级"：

能力不降级。代理层 18/18 精确答案通过；技能层虽然只省 3%~35%，但那是"同一答案、更少废话"。仓库引用的外部独立验证同样指向无损：Elastic 在 8 个真实 MCP 场景重制 caveman 模式，响应 token 减少 63.6%，报告"零信息丢失"；JetBrains 对 86 个真实编码任务做配对 A/B，质量无可测损失（p = 0.82），输出 token 减少 8.5%；Adobe Research 的论文在 8 个模型上测得成本下降 1.4~2.4 倍（README.md）。这些数字来自第三方、且结论方向一致——这不是玄学，是"话痨本身就是可压缩冗余"这一事实的多次验证。

可控性增强。代理层的价值不止省钱：本地 SQLite 记录每一次请求的真实用量，caveman learn分析 token 都花在哪、caveman trial -- claude在真实任务上做 A/B、caveman stats读会话历史（README.md）。这份"仪表盘"就是下面这张报告图：

更难得的是它的证据标签纪律（product-model.md）：本地 tokenizer 算出来的只标inferred，厂商计数器返回的标provider-reported，基准结果标benchmark_counterfactual，而verified只有连接云端的证据状态才会产生——本地工具永远不铸造这个词。用词不升级，数字就不会被"措辞镀金"，这正是社区大量 token 神话所缺的东西。

正确性与安全性有兜底。引擎对每个有损变换的执行顺序是：先存原始字节 → 返回压缩表示 → 附上可恢复的句柄 → 存储、解析或大小检查任一失败就原样透传（engine.md）。响应技能侧的规则同样围绕"payload 原样"设计：代码块逐字符不动，not/never/no/only这类否定词永远不删，数字和单位保持精确，发消息前有逐条自查（skills/caveman/SKILL.md）。被压掉的是客套、复述、开场白和"hope this helps"——不是技术事实。

五、什么场景该信"1/3"，什么场景该关掉

基于仓库内全部证据，可以给"1/3"画一条适用边界：

大概率成立：任务边界清晰（查日志、对比配置漂移、从大 CSV 找异常）、agent 反复读大块工具输出、按 token 计费、模型回答习惯性话痨。这类场景下"会话输入省 1/3、文件级省 80%+"有对偶基准支撑，且质量不降。

大概率不成立：按请求/额度计费（Copilot premium requests，答案变短也不省钱，见 issue #506）、一次性短问答（技能注入的约 1,000 token 固定开销反超收益，issue #145）、HTML 等无压缩器格式（基准实测倒退 9.9%）、以及规则反复注入 + 重试 + 缓存计费方式叠加的极端情况（issue #550 记录过一次 Cursor 上 4.3M vs 1M 的反向 A/B，因不可复现而未采信，但足以说明本地估算不可作为结论）。

caveman 给出的方法论其实朴素得像它的口号一样：别信任何人的固定比例，在同一个任务上用厂商账单页做开/关 A/B。/caveman-stats只报会话真实计数、明确声称"未知节省"，benchmarks/run.py 与 evals/measure.py 都提供了可复现路径——只要你有 Anthropic key 或直接读已提交的快照。

所以，回到标题的问题：caveman 的 token 消耗是主流框架的 1/3 吗？严格说，是——但只在"大输入、清任务、按 token 计费"的交集里，且这个 1/3 主要来自代理层压缩，而非它出圈的"说话方式"（输出层的中位增益只有 3%~35%）。更准确的说法是：caveman 把"token 账本"摆到了台面上，让省不省、省多少变成可测的工程问题，而不是营销口号。对想认真管理 agent 成本的人，这套证据方法比任何"1/3"都值钱。

【免费下载链接】caveman🪨 why use many token when few token do trick. Viral skill + proxy for coding agents that cuts 65% of tokens by talking like a caveman.项目地址: https://gitcode.com/GitHub_Trending/caveman1/caveman