Fable 5被网友薅出省钱神招量子位

没想到，人类当年靠微缩打印做小抄的土办法，在大模型身上也照样管用。

这两天，有位机智的老哥发现，只要把Fable 5的上下文转换成一张张密密麻麻写满文字的图片，再让模型通过OCR读回来，token输入成本最多能省下70%。

更离谱的是，不只是普通对话，系统提示、工具文档、历史记录，全都能一股脑塞进图里。

空说无凭，老哥还真给了一个例子：

大约4.8万字符的系统提示词和工具文档，如果直接按文本输入，大约需要2.5万token；

但把它们渲染成一张上面1573×1248的图片后，只需要约2700个image token。

按Fable 5现在的价格计算，实测端到端账单下降了59%到70%。

这一图胜过千言万语，还真有以前考试微缩、写小字的味儿了。

真·压缩即智能。

网友看完直接表示：这招可千万别让Dario知道了。

（你也不想你的Fable 5限制上传图片吧）

把上下文做成小抄，账单直接砍七成

开头提到的这个邪修Fable 5的方法，名叫pxpipe，目前在GitHub已经收获3000+ STAR。

在说明里，作者也是直抒胸臆的表示：

这玩意就是把Fable 5的文本上下文，渲染成图片，以降低的token用量。

之所以能这么“邪修”，关键在于一个计价差异：

图片的token成本，主要由像素尺寸决定，而不是由图片里塞了多少文字决定。

也就是说，只要模型还能读清图片里的字，那么同样一段内容，压成一张密密麻麻的PNG，可能就比直接作为文本输入更便宜。

尤其是代码、JSON、工具输出、系统提示词、工具文档这类内容，本身就非常token密集。

按照pxpipe作者的测算，在真实Claude Code流量中，这类内容如果作为图片输入，大约可以做到每个image token容纳3.1个字符；

但如果作为文本输入，约等于每个text token只能容纳1个字符。

而这，就给了pxpipe操作空间。

pxpipe本质上是一个本地代理：拦截Claude Code发出的请求，在请求离开本机之前，先把其中比较臃肿、适合压缩的上下文，重新排版成一张张紧凑的PNG图片，再塞回请求里发给模型。

模型读这些图片，走的则是同一个视觉通道——也就是Anthropic的computer use功能读取屏幕截图时依赖的那条通道。

换句话说，pxpipe并不是让模型“真正OCR”文本，而是利用模型本来就具备的看图能力，把大段上下文伪装成截图喂进去。

说白了，就是一个自动的微缩“打印机”。

后面，为了证明这招不是纯脑洞，作者也放了一个对比demo。

同样一组任务，原始文本版本跑到最后，账单是42.21美元，上下文窗口已经占满 96%；而pxpipe版本只花了6.06美元，上下文还只用了73.5k/1M。

也就在省钱的同时，任务也照样完成了，Fable 5依然能从图片化上下文中读出关键信息，完成计数和多步账本运算。

不过，这也不是一招鲜吃遍天。作者用Opus 4.8跑了同样的实验，普通文本needle没问题，但一到图片化内容里的词频统计，Opus就读不出来了。

与此同时，这也意味着，这是一种有损压缩，非常吃模型的视觉读取能力。

密集图片里的精确字符串，Fable 5还能勉强读，Opus就很容易翻车；更危险的是，错了也未必报错，而是自信编出一个看似合理的结果。

（注：这组benchmark证明：在Fable 5上，把高密度上下文渲染成图片，基本不影响语义理解和状态追踪，还能显著省token；但一旦涉及逐字读取精确字符串，就会暴露有损压缩的风险）