caveman 把 AI 的输出砍到三分之一，pxpipe 把文本变成图片，OmniRoute 让你用 237 家供应商的免费额度。2026 年 7 月，GitHub Trending 月榜上至少 4 个仓库在做同一件事，把 token 账单打下来。

故事是这样的。

上周我在做一个项目，用 Claude Code 连着跑了两天，代码改了大概 40 多个文件。第三天早上打开账单，一个 session 烧掉了 47 美金。说实话那一刻有点揪心，不是因为钱多，而是我意识到一个事实，大部分 token 花在了「废话」上。

AI 给我解释一段我已经看懂的代码，用了 300 字。实际有用的信息就一句：「你的 useEffect 缺了 cleanup 函数」。剩下 290 字是上下文铺垫、语气缓冲和过度解释。

我当时就想，有没有办法让 AI 少说点废话。

没想到 GitHub Trending 月榜给了我答案。而且不是一个答案，是三个完全不同的答案。

三条路走进同一个战场

2026 年 7 月的 GitHub Trending 上，有几个仓库同时在解决「token 太贵」这个问题，但路径完全不同：

路径一：让 AI 闭嘴。 caveman（月增 +9,840 star）把 AI 的输出风格从「贴心管家」改成「穴居人」，同样的答案用三分之一的字数说完。

路径二：让 AI 看图。 pxpipe（月增 +5,524 star）不走文本通道，把系统提示词和工具文档渲染成 PNG 图片塞给模型，利用图片 token 的固定成本特性，把 4.6 倍的信息塞进同样的 token 预算。

路径三：换一家给。 OmniRoute（15,367 star）聚合了 237 家 AI 供应商的免费额度，加上压缩策略，号称每月白嫖 16 亿 token。

这三个项目放一起看挺有意思的，没有一个在造新模型，全在「省」字上做文章。

caveman，让 AI 说穴居人语言

先说最直觉的那条路。

JuliusBrussee/caveman 的 README 第一句话就把我逗笑了，「why use many token when few token do trick」。

翻译过来就是，能用一个字说清的，为什么要用一句话。

这个项目的核心思路极其简单。你装一个 Skill 文件，AI 的回答风格就变了。来看一组 README 里的 Before/After 对比。

普通 Agent（69 token）：

The reason your React component is re-rendering is likely because you’re creating a new object reference on each render cycle. When you pass an inline object as a prop, React’s shallow comparison sees it as a different object every time, which triggers a re-render. I’d recommend using useMemo to memoize the object.

Caveman Agent（19 token）：

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.

同一个答案。三分之一的字数。技术信息一个字没丢。

坦率地讲，我第一次看到这个项目以为是个搞笑 meme，87K star 的 joke repo。但仔细看下去发现它比我想的认真得多。

不只是少说，是分层少说

caveman 提供了 6 个压缩等级，用 /caveman <level> 随时切换：

最狠的是 wenyan 模式，让 AI 用文言文回答。理由很实诚，古典中文是信息密度最高的自然语言形式。你想想看，「天下武功出少林」7 个字说清的事，英文可能要写两行。

基准测试的诚实

README 里有个基准测试表格，测了 10 个任务，平均压缩 65%。从 22% 到 87% 不等：

• React 重渲染解释，1180 token 压到 159，省 87%
• PostgreSQL 连接池配置，2347 压到 380，省 84%
• 但回调转 async/await 只从 387 压到 301，省 22%（本来就没什么废话可砍）

我觉得这个项目最值得尊敬的地方不是技术多复杂，而是它的诚实。README 里专门放了一个 Honest Number Warning：

caveman 只压缩输出 token，输入和推理 token 原封不动。Skill 本身每轮会多加 1 到 1.5k 输入 token。所以全 session 省下来的比 headline 数字小，在已经很精简的工作流上甚至可能净亏。

它还引用了一篇 2026 年 3 月的论文（arXiv:2604.00025），测了 31 个模型发现，限制大模型给简短回答，在某些 benchmark 上准确率反而提高了 26 分。短不只更便宜，有时候还更准。

这是我对这个项目改观的关键时刻。它不是一个省钱的 trick，而是一个关于「AI 是否需要那么多废话」的严肃实验。

生态比你想的大

caveman 已经不止是一个 Skill 了，它长出了一个生态：

• caveman，压缩 Agent 说什么（本文的主角）
• caveman-code，一个完整的终端编码 Agent，端到端 caveman 化，号称比 Codex 少用一半 token
• cavemem，压缩 Agent 跨 session 记住什么
• cavekit，压缩构建循环，规范驱动不再猜
• cavegemma，把压缩能力微调进模型权重里

还有一个 /caveman-compress 命令，可以把你的 CLAUDE.md 等记忆文件压缩成穴居人语言，平均砍掉 46% 输入 token。这意味着每个未来的 session 都从更小的上下文开始，不是省一次，是永远省。

pxpipe，把文本变成图片

如果说 caveman 是在「说什么」上做文章，pxpipe 就激进得多了。它改的是「用什么通道」。

teamchong/pxpipe 的核心洞察来自一个物理事实，图片的 token 成本由像素尺寸决定，跟图片里塞了多少文字无关。

这意味着，如果你把一段 48K 字符的系统提示词渲染成一张 PNG 图片，模型看到这张图只需要约 2.7K image token。而同样这段文字作为文本输入，需要约 25K token。

这是将近 10 倍的差距。

视觉通道不是新发明

你可能会问，AI 模型真的能「看图读代码」吗？

其实这个能力一直在那里。Anthropic 的 Computer Use 功能就是靠模型看截图来操作电脑的。pxpipe 做的事情是，主动利用这个视觉通道来传输文本上下文。

README 里有一张图让我盯着看了很久。它画了 2018 到 2026 年，各模型上下文窗口能容纳的字符数变化。纯文本天花板一直在 400 万字符左右（100 万 token 窗口，约 4 字符/token）。但同一条 Fable 5 的 100 万 token 窗口，通过 pxpipe 图片渲染，可以容纳约 1800 万字符。

4.6 倍。

有损，而且会撒谎

pxpipe 的 README 里有一段「The honest part」，写得极其坦诚：

12 字符的精确十六进制串，Fable 5 在图片里能读对 13/15，Opus 4.8 是 0/15。而且读错的时候不是报错，是「安静的编造」（silent confabulation），模型会自信地给你一个错误的值。

这是最危险的地方。模型视觉不是 OCR，图片变成的是 patch embedding，不是离散字符。当像素不足以确定一个字形时，语言先验会填一个看起来合理的答案。

pxpipe 的应对策略是：

• 精确值（ID、hash、密钥）始终保留为文本
• 最近的对话轮次保持文本，只压缩旧历史和静态系统提示
• 利润率门控，只有当压缩确实省 token 时才触发
• 非 allowlist 的模型完全跳过

实测数据也很扎实。SWE-bench Lite 试点 10/10 两臂通过，请求大小降 65%。一个 Demo 里，同一个任务 plain 模式花了 42.21 美金做到 96% 上下文满，pxpipe 模式 6.06 美金还剩大量上下文。

工程上的精妙

pxpipe 的架构是一个本地代理：

npx pxpipe-proxy                                  # 启动代理
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # 指向代理

它拦截 /v1/messages 请求，把符合条件的文本块重写成图片，拼回去，再转发给 Anthropic。关键的工程细节在于，静态前缀被保留，prompt caching 继续工作。你省了 token 但没有牺牲缓存命中。

不同模型用不同的渲染配置。Claude 用 312 列 5×8 Spleen 字体，GPT 5.6 Sol 用 126 列 6×11 JetBrains Mono。每个配置都是针对该模型视觉能力专门调优的。

这不是一个 hack，这是一个认真的工程。

OmniRoute，换一家供应商给

第三条路最暴力直接，也是最不技术的一条路。

diegosouzapw/OmniRoute 的逻辑是，如果一家供应商太贵，那就找 237 家。

它聚合了 237 家 AI 供应商，其中 90 多家有免费层。把 Claude Code、Codex、Cursor、Cline 等编程工具全部接到一个端点上，后台自动在供应商之间切换。

免费层到底能白嫖多少

README 给了一个计算，约 16 亿 token/月，首月加上注册赠送额度可以到 21 亿。

这个数字怎么来的？OmniRoute 做了一个「池去重」统计，每个共享免费池只算一次，不会把 rate limit 上限重复计数。它还特意提到，如果把所有 rate limit 24 小时跑满，数字能到 100 亿，但它不发布这个数字，因为不诚实。

这态度挺让我有好感的。

压缩叠在上面

OmniRoute 不只是路由，它还叠了压缩。README 里提到 RTK + Caveman stacked compression，平均省 15 到 95% 的 token，在工具密集的 session 上平均 89%。

这里的 Caveman 就是前面那个项目。OmniRoute 把 caveman 的压缩能力集成进了自己的网关层。你在用 OmniRoute 的时候，压缩是自动发生的。

17 种路由策略

这是 OmniRoute 最花哨的部分。它提供了 17 种路由策略来决定下一个请求发给谁：

最实用的几个：priority（按顺序用尽再换下一个）、cost-optimized（按实时价格选最便宜的）、headroom（选剩余额度最多的）、lkgp（粘住上次成功的供应商）。

还有一个 fusion 策略，把请求发给一组模型，再用一个 judge 模型综合出最终答案。这个适合需要高质量回答的场景。

三层容错设计也算用心：熔断器（整个供应商挂了就停）、连接冷却（单个 key 限速就跳过）、模型隔离（只是某个模型限速，不锁整个连接）。

三条路放一起看

这三个项目解决的是同一个问题的不同切面。让我用一个表把它们放在一起：

caveman 是最安全的赌注。 它无损，零依赖，30 秒装完，支持 30 多种 Agent。缺点是只省输出，对输入密集型工作流帮助有限。

pxpipe 是最激进的方案。 它直接改了信息传输通道，收益最大但风险也最大。适合上下文巨大、频繁调用 API 的重度用户。你得接受精确字符串可能读错这个事实。

OmniRoute 是最不技术但最有效的方案。 如果你的核心痛点是「太贵」，那就别压缩了，换一家给的。缺点是免费层不稳定，供应商可能随时改条款，而且 237 家供应商的管理本身就是一个复杂度。

真正值得想的问题

写到这里，我其实在想一个更深的问题。

这三个项目的走红，背后反映的不是技术趋势，是经济现实。2026 年的 AI 编程，能力已经不是瓶颈了。随便一个模型都能写出不错的代码。真正的瓶颈是成本。

caveman 的 README 引用了那篇论文的结论，「限制大模型给简短回答，准确率反而提高了 26 分」。如果这是真的，那我们过去两年里看到的 AI「啰嗦」，可能根本不是模型的能力问题，而是 prompt 设计和默认配置的路径依赖。

AI 被训练成「贴心、详细、有礼貌」，因为这样在 user study 里评分高。但在实际工程使用中，这种「礼貌」每个 session 烧掉的可能是几十美金。

pxpipe 更进一步，它证明了视觉通道可以承载远超文本通道的信息密度。这不只是省钱的问题，这是关于「AI 到底怎么读信息最有效」的认知重构。

OmniRoute 则暴露了另一个现实。大部分开发者用 AI 编程时，对成本是没有议价能力的。你能选的只有「用还是不用」，而不是「花多少钱用」。OmniRoute 把选择权还给了开发者，你可以告诉它「在质量差不多的前提下，选最便宜的」。

什么时候该用什么

如果你问我推荐，我的建议是根据你的瓶颈来选：

如果你每天在 Claude Code 上花超过 10 美金，先装 caveman。 它无损、零风险、30 秒装完。即便它只省输出 token，在对话密集的编码场景，输出占了很大比例。/caveman full 是我推荐大多数人的默认等级，平衡了可读性和压缩率。

如果你的核心场景是大代码库分析，系统提示词动辄几万 token，试试 pxpipe。 但要做好心理准备，它有损，精确值可能读错。最佳实践是把它用在「读取理解」阶段，真正需要精确操作的步骤切回文本模式。

如果你是预算敏感型用户，或者需要 7×24 不间断可用，用 OmniRoute。 它的免费层聚合 + 多供应商 fallback 能让你的 AI 编程工具「永远在线」。但别把生产环境的关键路径完全依赖免费层，供应商条款说变就变。

还有一招没在这三个项目里单独体现，但值得一提。caveman 和 OmniRoute 可以叠加使用。OmniRoute 做供应商路由和 RTK 压缩，caveman 做输出风格压缩，两层叠加的效果是乘法关系。

写在最后

token 压缩这件事，说到底不是技术问题，是经济学问题。

当一个资源稀缺又昂贵时，市场会自发演化出三种角色：减少消耗的人（caveman）、提高密度的人（pxpipe）、寻找替代供应的人（OmniRoute）。这三个项目恰好对应了这三种角色。

我自己的体感是，caveman 装上之后，日常编码的账单降了大概 30 到 40%。不是 65%，因为我的工作流里输入 token 占比很高，caveman 只省输出。但 30% 已经是很实在的数字了。

pxpipe 我还在观望。它太新了，有损的特性让我不敢用在需要精确读代码的场景。但它的思路太漂亮了，我赌半年内会有更成熟的版本出来。

OmniRoute 我装了但没重度用。237 个供应商的管理复杂度对我来说有点重，而且免费层的不确定性让我焦虑。不过如果你是一个团队的管理者，需要给多人配 AI 编程工具，OmniRoute 的 Quota-Share 功能值得认真看看。

最后一句实话。这三个项目都还年轻，数据会变，策略会迭代。但「token 太贵」这个需求不会消失，直到模型推理成本降到可以忽略不计。在那之前，Token 压缩经济学是一门正在快速发育的手艺。

现在入局，一点都不晚。