把文字压成图片喂给 Claude Code，token 成本直接砍一大半

这两天在 GitHub 上刷到一个仓库，叫 pxpipe，它干的事一句话就能说清楚，但那句话我第一次读的时候是拒绝的。

它把喂给 Claude Code 的一大堆文本，先在你本地渲染成图片，再把图片发给模型。就这么一手，作者号称账单能砍掉六成到七成。

我盯着那行字看了会儿。把文字变成图片，然后省钱？这不反了吗。图不是应该比文字更贵吗，一张图那么多像素。我脑子里第一反应是这人是不是把成本算错方向了。

结果是我算错了方向。

先把一个大前提摆出来，很多人（包括几个小时前的我）对多模态模型的计费有个想当然的误解。你以为一张图片的 token 数，是看图里塞了多少内容决定的。不是。一张图消耗多少 vision token（视觉 token，模型「看」一张图要花的计费单位），只由它的像素尺寸决定，跟图里画了一个字还是画了一整页密密麻麻的代码，一点关系都没有。

这就是整个 pxpipe 的命门所在。

我给你把数字摊开。在真实的 Claude Code 流量里，一段密度很高的内容（代码、JSON、命令行 log 那种），当纯文本喂进去，大概是 1 个字符顶 1 个 token。但你把同样这段内容渲染成一张图，图里每个 token 能装下大约 3.1 个字符。作者实测里更狠的一个数据，一张 1928×1928 的图，计费大约 4761 个视觉 token，却能塞进差不多 92000 个字符。你算一下这个密度，一个 token 装快 20 个字符。

所以什么时候图片划算，什么时候文本划算，是有一根清晰的分界线的。内容密度超过大约每 token 19 个字符，文本才开始比图片省。而 Claude Code 的真实流量密度是多少呢，作者统计了 391 条生产请求，平均 1.91。离那根 19 的线差着十倍。

好家伙。也就是说对 coding agent 这种场景，几乎所有的大块上下文，转成图片都是稳赚的。

我得说这个洞察挺漂亮的。它不是发明了什么新的压缩算法，它只是发现了一个计费规则上的缝，然后拿一个本地代理（proxy，就是架在你和 API 之间的一个中转小程序）钻了进去。

它到底压了什么

这里有个我一开始担心的问题，你把上下文都变成图，模型还读得懂吗？会不会我省了钱，结果 agent 变傻了。

pxpipe 的做法是有分寸的，不是无脑全压。它只对三类东西下手，而且每一类前面都架了一道「划不划算」的闸门（profitability gate），算下来省钱才压，不省就原样放行。

第一类，大块的 tool_result，就是你让 agent 读文件、跑命令、看日志吐回来的那一坨东西，超过大约 6000 字符的密集内容才压。第二类，聊到后面已经被折叠起来的老对话历史，越靠前的越会被重新渲染成图片页，但最近几轮永远保持文本。第三类，那个又臭又长、每次请求都要重发一遍的系统提示词加工具文档。

剩下的全部原样透传。你正在打的字、最近几轮对话、模型吐给你的输出（这本来就是响应，代理压根不碰），稀疏的散文，还有任何小到压了也不划算的东西，一个字节都不动。

我觉得这个「最近的留文本、老的才压成图」的设计是有讲究的。agent 干活时对眼前刚发生的事需要看得一清二楚，对几十轮之前的陈年历史只要记个大概就行。它把清晰度花在了刀刃上。

装起来也是真的简单，作者说三十秒。你本地跑一个代理，然后把 Claude Code 的请求地址指过去就完事了。

npx pxpipe-proxy
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude

跑起来之后本地还有个看板，能看到实时省了多少 token、每一次文本转图片的前后对比、一个随时能拍下去的 kill switch。响应照常流式返回，它只压请求，不动输出。

但它是有损的，作者自己拿大喇叭喊

聊到这我必须停一下，因为如果我只讲省钱那一半，就成了那种「AI 赋能降本增效」的营销号了，那不是我想干的事。

pxpipe 最让我服气的地方，恰恰是它对自己缺点的坦诚程度。整个 README 里有一整节，标题直接叫「诚实的部分」（The honest part），作者把刀递到你手里，指着自己说这儿有问题。

它是有损的。什么意思，就是把文字渲染成图，模型再从图里「认」出来的时候，会认错。而且最要命的是，它认错的方式不是报错，是一本正经地编一个看着挺合理的假答案出来。作者管这叫 silent confabulation，无声的虚构。

有多严重？作者给了实测。让模型从密集的图片内容里，逐字复述一个 12 位的十六进制字符串，Fable 5 能对 13/15，而 Opus 4.8 是 0/15。你没看错，Opus 从这种密集图片里读精确字符串，全军覆没，而且每一次都是自信地报一个错的。

所以作者划了条死线，凡是需要一个字节都不能错的东西，身份 ID、哈希值、密钥、密码，必须留在文本里，绝对不能压成图。这也是为什么最近几轮对话它坚持保持文本，因为你眼前正在操作的东西最可能包含这种精确值。

作者还讲了一个真实翻车案例，不是跑分里的，是日常用了好几周里唯一一次出事。模型从图片化的聊天历史里回忆一个人的名字，然后特别自信地说错了。没有任何报错，就是一个听起来很像的错名字。作者说 coding 场景能扛住这种事，因为 agent 编辑文件前会重新读一遍原文，有个自我校验的兜底，但纯聊天的记忆回溯没有这道保险。

我看到这段是真的舒服。你知道现在多少 AI 项目的 README 是把优点吹上天、缺点塞进最底下小字里。pxpipe 反过来，专门辟一节把最难看的数字亮出来，还配了一份可读性审计报告，量化了模型从渲染页面里认精确字符串的失败率，盲读密集标识符的正确率上限也就 63%，每一次认错都能用一个「字形易混矩阵」提前预测出来。

这种坦诚，比那六成的省钱数字更让我愿意信它。

为什么它只让 Fable 5 上桌

还有个细节挺有意思。pxpipe 默认只对两个模型开启图片压缩，Fable 5 和 GPT-5.6。Opus 4.8 和 GPT-5.5 是默认关掉的，你想开得自己去看板上手动点亮。

原因就是上面那个读图能力的差异。Fable 5 从图片里读内容读得极好，作者给它打的分是 100/100 的读者。而 Opus 4.8 会误读大约 7% 的渲染页，GPT-5.5 在图片化的上下文上也会掉链子。所以作者的处理是，读图靠谱的模型才默认压，不靠谱的绝不偷偷压，必须你自己知情了主动开。

顺带说个反差数据。在一组模型没法背下来的全新随机数算术题上（专门挑没法靠记忆蒙的），Fable 5 无论喂文本还是喂图片，都是 100% 全对，但图片版省了 38% 的 token。同一份题给 Opus 4.8，文本 100%，图片版掉到 93%。你看，这就是为什么 Opus 得关着。

至于省下来的钱到底有多少，作者在演示里跑了一整个 session 做对比。同样的活，普通模式跑到 96% 上下文满，花了 42.21 美元。开了 pxpipe 那条，跑完还剩一大半上下文（73.5 万 / 100 万），只花了 6.06 美元。

当然作者自己也反复强调，这个具体的百分比是跟你的工作负载强相关的。压密集内容才赚，压稀疏的大白话反而亏钱，所以那道划算闸门很关键。他甚至把整个测算方法都摊开了，每一次请求，代理会并行发一个免费的 count_tokens 探针去算「如果不压会是多少 token」，再读回 API 实际计费的用量，两个数落在同一行日志里，你可以自己从 FINDINGS.md 里的公式重新推一遍，不用信他的一面之词。

连 SWE-bench 的实测都给了。Lite 那档，开和不开都是 10/10，请求体积小了 65%。Pro 那档，开着 14/19、关着 15/19，差的那一道题复现时又稳稳解出来了，作者判断是跑与跑之间的正常波动，不是压缩把它压坏的。样本量不大，他也老实标了小 n，收据全在 eval 目录里。

最骚的是这一句

README 快到结尾有个 FAQ，其中一问是「为什么这 README 读起来像 AI 写的」。

作者的回答是，因为它就是 AI 写的。这个仓库里大部分的提交，代码也好文档也好，都是 Opus 和 Fable 的 agent session 干的，而这些 agent 在干活的时候，正跑在 pxpipe 自己后面，一边工作一边把自己的折叠历史当图片页读着。

我读到这儿笑了一下。这画面有点绕但特别对味，一个用来压缩 agent 上下文的工具，是由一群被它自己压缩着上下文的 agent 写出来的。自己吃自己的狗粮，吃到连 README 都是狗粮喂出来的。这在软件史上有个词叫 self-hosting，编译器能编译自己才算成年。pxpipe 这算是某种意义上的成年礼。

聊完这些我其实有点走神。这一年我们都在为上下文窗口焦虑，1M、2M、往上卷，好像窗口越大就越自由。但 pxpipe 提醒了我另一个方向，同样的窗口，你能往里塞多少有效信息，取决于你用什么形态去塞。文字是一种形态，图片是另一种，而计费规则在这两种形态之间，留了一道没人注意的缝。

有人看见了缝，弯下腰，钻了进去。

它不完美，有损，会在你最不设防的时候编一个假名字给你。但它把每一个坑都插了根旗子，明明白白告诉你这儿有雷别踩。一个把自己的短处摊在阳光下的工具，比一百个只报喜的要可信得多。

想玩的可以去 teamchong/pxpipe 自己 npx 跑一下，MIT 协议，代码全开。跑之前记着作者那句话，精确的东西留文本，图片只压那些糊一点也无所谓的大块历史。省钱可以，别把密钥省进图里去了。