一个 Fable 5 节省成本的技巧爆火：借助基于图像的上下文将账单最多削减 70%

pxpipe 展示了一种巧妙降低 Fable 5 输入成本的方法：将令牌占用高的上下文渲染成紧凑图像，再让模型通过其视觉能力读取这些图像。对于高密度编码工作负载，这可以显著减少请求侧的令牌使用量，并降低端到端成本。这种方法的代价在于它是有损的。对于许多编码和状态跟踪工作流，它能够保留足够的语义，但不能用于对 ID、哈希、密钥或精确数字进行字节级精确回忆。更广泛的一点是，在 AI 系统内部，文本并不总是必须以文本形式存在。CLIPPO、DeepSeek-OCR 和 pxpipe 都指向同一个思路：像素可以成为长上下文的一种实用压缩层。 **最佳使用场景已经很明确：压缩臃肿、低精度的上下文，但将关键的精确值保留为普通文本。**

发布于 2026年7月8日•general•GEO 评分: 0•14 次阅读

Fable 5 成本节省pxpipeClaude Code 令牌减少图像令牌压缩Claude Code 代理上下文压缩文本到图像上下文图像令牌Anthropic Messages APIDeepSeek OCRCLIPPO光学上下文压缩AI 编码成本优化

选择语言

العربية Deutsch English Español Français Italiano 日本語 한국어 Português Русский 中文

这是一张宣传 Fable 5 成本节省技巧的图片，背景为深色渐变，右侧带有橙色放射状图案。图片中的文字“Fable 5 Cost-Saving Trick”里，“Cost-Saving”部分采用橙色到紫色渐变，“Use pxpipe to Reduce Claude Code Token Bills by Up to 70%”则为白色文字。下方有三个图标：左侧是文件图标，中间是带网格的圆柱形图标，右侧也是文件图标。该图呼应了文档所介绍的内容：pxpipe 通过将 Claude Code 上下文转换为紧凑的 PNG 图像，减少 Fable 5 输入令牌使用量，从而最多节省 70% 成本。

一种 Fable 5 省钱技巧火了：用基于图像的上下文将账单最高削减 70%

引言

Fable 5 社区最近开始关注一个看起来相当“复古”的技巧：把冗长的文本上下文转换成高密度图像，再让模型通过其视觉能力把图像内容读回来。

这听起来几乎像是在为考试制作一张微型小抄。但这次，“小抄”不是给人看的，而是给能够读取截图的多模态模型看的。一位开发者发现，把 Claude Code 的上下文转换为紧凑的 PNG 图像后，在测试工作负载中，输入 token 成本大约可以下降 59% 到 70%。

图片是一条推文，发布者为@IntCyberDigest，内容提到通过将Claude Code上下文转换为图像并让Fable OCR读取，可将Fable 5成本降低约70%。图片左侧展示了一张密集的灰度图像，右侧文字介绍了pxpipe，称其通过将上下文渲染为图像来减少输入令牌，图像的令牌成本主要取决于像素尺寸而非文本量，密集内容（代码、JSON等）每张图像可节省约3.1个令牌，pxpipe是一种本地代理，可将请求中的大块内容（系统提示、工具文档等）重写为紧凑的PNG图像。

其基本思路很简单：系统提示、工具文档、命令输出、日志以及较早的对话历史通常都会消耗大量 token。如果把这些内容块渲染成图像，那么它们的图像 token 成本主要取决于图像尺寸，而不是图像中塞进了多少文本。

本文将介绍 pxpipe 的工作方式、为什么这种方法可以省钱、它会在哪些情况下失效，以及它与更早的研究（如 CLIPPO）和较新的光学上下文压缩工作（如 DeepSeek-OCR）之间的联系。

来源说明

本文基于 BAAI Hub 发布的中文原文撰写，该文称消息源自微信公众号 QbitAI。原始参考链接包括 pxpipe 的 GitHub 仓库和 CLIPPO 论文。下文保留的图片均为与文章相关的截图、演示图、示意图和社交讨论截图。二维码、推广关注提示、互动号召以及与内容无关的平台装饰均已移除。

把上下文变成“小抄”，然后砍掉账单

这项走红的方法叫做 pxpipe。它是一个开源的本地代理，会在请求离开你的设备之前，重写体积庞大的 Claude Code 输入上下文。

根据项目说明，pxpipe 通过把大块文本渲染成图像来减少 token 使用量。当模型足够擅长读取高密度渲染文本时，同样的系统提示、工具文档、工具输出和较早历史记录，就可以被压缩进一个小得多的 token 占用中。

图片展示的是pxpipe处理后的系统提示和工具文档内容，以图像形式呈现。上方文字说明约48,000字符的系统提示和工具文档，作为文本需25k token，而渲染成此页图像仅需2,7k图像token。下方是实际管道输出的图像，模型可可靠读取，其压缩效果在100/100的基准测试中表现良好。该图直观呈现了pxpipe将文本转换为图像以减少token数量，从而降低成本的核心功能，与上文介绍的pxpipe通过渲染大文本块为图像来减少token使用量的内容相呼应。

在一个示例中，大约 48,000 个字符的系统提示和工具文档，如果以纯文本形式输入，需要大约 25,000 个 token。将相同内容渲染为一张 1573 × 1248 的图像后，据称只用了大约 2,700 个图像 token。

成本下降的关键，就在这个差异上。

粗略的

原理如下：

文本 token 成本会随着文本量的增加而增长。
图像 token 成本主要由像素尺寸决定。
密集的代码、JSON、工具输出、系统提示词和日志，往往每一行都包含很多 token。
如果模型仍然能够可靠地读取压缩后的图像，那么同样的上下文发送起来就会更便宜。

一些开发者开玩笑说，这简直是“千言万语不如一张图”的字面案例。这里，这个玩笑却出乎意料地接近技术现实。

图片展示了一条推文，发布者为Rishabh Poddar，用户名为@rishpoddar，发布时间为20小时前。推文内容为“A picture is worth a thousand words. Literally 😂”及“一张图片胜过千言万语。真的呢😂”，并配有笑脸表情。该推文与文档中介绍的pxpipe技术相关，pxpipe通过将大文本块渲染为图片来减少token使用，文档中提到一些开发者认为这“一张图片胜过千言万语”，此推文是对这一观点的幽默表达。

图片展示的是一个推文界面。上方显示用户名为Roman，带有蓝色验证标志，用户名为@romxdev，发布日期为7月5日。推文内容为“Don't show this to Dario 😅 不要把这个给达里奥看 😅”，并配有两个笑脸表情符号。下方有350条评论，界面右上角有放大镜和三个点组成的图标。该图片与文档中介绍pxpipe成本节约技巧的内容相关，可能是某开发者在推特上分享pxpipe相关趣事或评论。

pxpipe 实际上做了什么

pxpipe 不是一种新模型，也不是传统的 OCR 引擎。它作为 Claude Code 与模型 API 之间的本地代理运行。

在请求发送出去之前，pxpipe 会寻找适合压缩的大块内容。然后它会把这些内容渲染成紧凑的 PNG 页面，并作为图像输入重新放回请求中。模型通过其常规视觉通道读取这些页面。

图片展示的是pxpipe项目的介绍内容。标题为“About”，介绍pxpipe通过将文本内容以图像形式呈现来减少《神鬼寓言 5》中的代币使用量。项目包含Readme、MIT license、Activity等信息，有3k stars、15 watching、201 forks等数据，底部有“Report repository”选项。该图片与上文介绍pxpipe作为本地代理、压缩文本块等信息相呼应，直观呈现了pxpipe项目的相关信息。

图片展示的是pxpipe项目的GitHub页面。页面左侧为项目导航栏，包含Code、Issues、Pull requests、Actions、Projects、Security & quality、Insights等选项。右侧是项目代码列表，显示了多个文件和文件夹，如gpt2、gpt2-1.5、gpt2-2.0等，部分文件有修改时间标注。页面右上角有“Go to file”按钮，右下角有“Code”按钮。该图片与上文介绍pxpipe作为Claude Code与模型API之间本地代理，处理长上下文内容等上下文内容相关，直观呈现了pxpipe项目的GitHub界面。

简单来说，pxpipe 的行为就像一台面向长上下文的自动微型打印机。严格按照工程学意义来说，它并不是让模型去“做 OCR”识别文本。相反，它依赖的是模型内置的、读取类似截图视觉输入的能力。

pxpipe 的 README 解释说，它主要处理以下这类体积庞大的输入上下文：

大型 tool_result 内容，包括文件读取结果、命令输出和日志。
较早且已折叠的对话历史。
静态系统提示词和工具文档。

它会刻意避免把一切都转换掉。最近几轮对话、用户消息、精确标识符、小块内容、稀疏散文以及模型输出仍然保留为文本。

为什么它能节省这么多

核心的定价错配在于，图像输入和文本

输入的计量方式不同。

对于文本密集型的开发者工作流，源材料通常具有很高的 token 密度。代码、日志、JSON、堆栈跟踪和工具 schema 以纯文本形式发送时，成本可能很高。pxpipe 的作者估计，在真实的 Claude Code 流量中，这类高密度内容每个图像 token 大约可容纳 3.1 个字符，而每个文本 token 大约只能容纳 1 个字符。

这个比例让 pxpipe 在文本足够密集时有空间降低成本。

作者还分享了一个对比演示。在原始文本版本中，据称一次测试运行最终账单为 42.21 美元，且上下文窗口几乎被占满。而在 pxpipe 版本中，同样的任务以 6.06 美元完成，并且剩余了更多的上下文空间。

图片展示了Fable 5中使用pxpipe前后成本节省的对比。左侧为原文本版本，显示测试运行结束时账单为$42.21，上下文窗口几乎满。右侧为pxpipe版本，同样任务完成，账单为$6.06，且上下文空间剩余较多。图片与上下文紧密相关，直观呈现了pxpipe在成本节省方面的效果，通过具体数据对比，说明pxpipe在文本密集型开发工作流中能显著降低费用。

一个重要细节是，pxpipe 只压缩请求侧。模型的响应仍会像往常一样以文本形式流式返回。它不会压缩输出 token。

基准测试结果与主要注意事项

这种方法令人印象深刻，但它并非无损。高密度图像上下文在很大程度上依赖于模型的视觉读取能力。

pxpipe 的基准测试截图显示，Fable 5 在多种图像上下文任务中表现良好，包括新型算术、要点回忆、状态跟踪以及一些高密度渲染回忆测试。但精确字符串回忆是一个薄弱点，尤其是在那些不擅长读取高密度文本的模型上。

图片展示的是Fable 5在不同测试任务中的表现数据。表格包含测试、样本数N、文本、pxpipe（图像）和tokens等列。如“novel arithmetic”测试，claude - fable - 5和claude - opus - 4 - 8的文本均为100%，pxpipe（图像）分别为100%和93%，tokens变化均为-38%。此外，还有“gist recall A/B”“state tracking”等测试数据。该图与上下文紧密相关，是对文档中Fable 5在图像 - 文本任务表现的直观呈现。

报告中的基准测试表简化后如下所示：

测试	N	文本	pxpipe 图像	Token 变化
新型算术，`claude-fable-5`	100	100%	100%	-38%
新型算术，`claude-opus-4-8`	100	100%	93%	-38%
要点回忆 A/B，Fable 5	每组 98	98/98	98/98	—
状态跟踪，Fable 5	每组 18	18/18	18/18	—
从未陈述事实上的虚构生成，Fable 5	每组 16	0/16	0/16	—
逐字 12 字符十六进制回忆，Opus	15	15/15	0/15	—
逐字 12 字符十六进制回忆，Fable 5	15	—	13/15	—

风险很明显：基于图像的上下文对于宽泛的语义理解、状态跟踪以及许多编码任务来说可能已经足够好，但它也可能在不知不觉中误读精确字符串。

ID、哈希、密钥、固定数字以及其他需要字节级精确的值，不应被塞进高密度图像中。pxpipe 自己的说明也强调了这一点：这种权衡非常严肃，其失败模式可能不是明显报错，而是给出一个自信但错误的答案。

图片展示了两条推文。上方推文由@IntCyberDigest发布，提醒使用pxpipe时，将ID、hash、密钥等精确字符串推入密集图像会存在风险，数据在传输中可能丢失，且可能被错误解读。

下方这条推文由 @sanixdarker 回复，他表示这种做法并不新鲜，自《Opus》发布以来他就一直在这样做，而且与《Fable》系列没有直接关系。图片与上下文密切相关，直观展示了关于将特定数据压入密集图像可能带来风险的讨论。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/8d83ec15-fc8e-4019-8909-2d441f51f258-10-af6628e8-7211-4ee2-8a25-33b3a4e2a529.png)

pxpipe 会保留为文本的内容

由于这种压缩是有损的，pxpipe 不会不加区分地把每个输入块都渲染成图像。它会将敏感内容和对精度要求极高的内容保留为文本形式。

应当保留为普通文本的示例包括：

ID 和哈希值。
密钥和访问凭证。
精确的数值。
最近活跃的对话轮次。
用户消息。
稀疏的散文式文本，因为其 token 密度不足，无法从压缩中受益。

这也是为什么该项目将节省效果定位为取决于具体工作负载。如果请求内容主要是长篇自然语言散文，那么压缩可能并不划算。如果请求中充满了代码、JSON、日志和工具输出，那么节省幅度就可能大得多。

如何试用 pxpipe

作者给出了一个非常简短的启动流程。先在本地运行代理，然后让 Claude Code 指向这个代理。

npx pxpipe-proxy                                  # 在 127.0.0.1:47821 上运行代理
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # 让 Claude Code 指向它

启动后，pxpipe 还会提供一个本地仪表盘：

http://127.0.0.1:47821/

该仪表盘可以显示 token 节省情况、文本到图像的并排转换、紧急关闭开关以及实时模型标签。这使得用户更容易准确看到哪些内容被压缩了，哪些内容原样透传。

Google 在 2022 年的 CLIPPO 论文其实已经指出了这个方向

在 pxpipe 开始传播后，一些研究人员指出，这一核心想法并不是全新的。

相关的研究方向早在 Google 2022 年的论文 CLIPPO：仅从像素中实现图像与语言理解 中就已出现。CLIPPO 的核心思想，是将文本视为像素，而不是视为一条独立的分词文本流。

图片展示的是 Lucas Beyer 关于 Fable 5 成本节省技巧的推文。他提到，当今前沿实验室突然削减成本，或宣称“找到了大幅减少推理所需内存的方法”时，其秘诀就在于视觉始终占优。图片中还展示了 Google Research 发表的 CLIPPO 论文，其核心思想是将文本视为像素而非独立的文本流，通过共享的 Vision Transformer 处理图像和渲染后的文本。与传统 CLIP 风格模型相比，CLIPPO 在相同参数规模下可以完成图像、文本和多模态任务，而且训练时间缩短了一半。

传统的 CLIP 风格模型通常采用双塔结构：一塔处理图像，另一塔处理文本。CLIPPO 则取消了这种划分，它将文本渲染为 RGB 图像，并将图像和渲染后的文本一起送入共享的 Vision Transformer。

图片展示了 CLIP 与 CLIPPO 的模型架构对比。左侧的 CLIP 模型中，图像通过 CONV 层进入 Vision Transformer，文本经过 WORD EMB 和 TOK 处理后进入 Text Transformer，二者通过 Contrastive 进行交互。右侧的 CLIPPO 模型中，图像和文本都通过 CONV 层进入 Transformer，取消了图像与文本的分离处理。该图与上下文密切相关，直观展示了 CLIPPO 将文本作为 RGB 图像处理并共享 Vision Transformer 这一核心思想，是理解 CLIPPO 模型架构的关键示例。

这里的重要启示是：文本并不总是必须以离散文本 token 的形式输入模型。它也可以被转换为像素，并通过视觉通路进行处理。

DeepSeek-OCR 与光学上下文压缩

讨论还

提到了 DeepSeek-OCR，它专注于面向长上下文的光学压缩。其代码仓库将该项目描述为“上下文光学压缩”。

图片展示了两条推文。上方推文由JQ发布，内容提到大约一年前，Deepseek在其Deepseek OCR项目中尝试了将文本处理为图像的技术，当时人们对此压缩可能性感到兴奋。下方推文由Lucas Beyer回复，表示自己隐约记得此事。这两条推文与文档中关于pxpipe、DeepSeek-OCR等技术的讨论相关，说明pxpipe并非单一成本节省技巧，还连接了光学压缩等趋势。

图片展示的是一个GitHub页面，页面标题为“deepseek - ai/DeepSeek - OCR: Contexts Optical Compression”。页面显示贡献者1人，问题248个，星标23k，fork 2k。下方有Matthew Campbell的评论，提到Deepseek在2025年10月也发布过类似内容，不确定这次还有什么新意。该图片与文档中关于pxpipe和DeepSeek - OCR的讨论相关，表明pxpipe与DeepSeek - OCR在光学压缩方面有相似之处，引发对二者关系的思考。

从这个意义上说，pxpipe 不只是一次性的成本优化技巧。它连接了几个趋势：

CLIPPO 证明了文本可以作为图像来处理。
DeepSeek-OCR 探索了长上下文的光学压缩。
Fable 5 似乎已经足够擅长高密度视觉阅读，使这项能力能够在真实编码工作流中变得实用。

不过仍然存在一个硬性限制：精确字符串的可靠性。一些评论者认为，只要把更强的视觉语言模型继续做大，这个问题可能就会改善。

这张图片展示了两条社交平台的推文对话，是对pxpipe相关技术问题的讨论。Shardul发布的推文指出，该技术存在信息丢失的弊端，像身份标识、哈希值这类需要精准完整的内容可能被错误解读；另一条Lucas Beyer的推文则简洁回应，认为只需扩大模型规模就能解决该问题。该对话对应文档中提及的pxpipe存在“精确字符串可靠性”局限，需依托更强的视觉语言模型优化的相关内容。

实际要点

当上下文规模大、内容密集且不要求极高精度时，pxpipe 最有用。编码会话是一个天然适配场景，因为代理通常会在编辑文件前反复读取文件，这可以降低因误读某个图像块而采取错误操作的风险。

对于那些要求精确到字符级回忆的工作流，它就不太适合。如果任务依赖标识符、哈希值、凭据、精确的法律措辞、财务数字，或类似对精度敏感的内容，那么应谨慎对待基于图像的压缩。

一种合理的 pxpipe 使用方式，是将其作为优化层，而不是信任边界。让它在数学上划算的地方压缩臃肿的上下文，但把关键数值保留为文本，并在调试模型异常行为时查看仪表板。

常见问题

什么是 pxpipe？

pxpipe 是一个本地代理，它通过将庞大的 Claude Code 输入上下文渲染为紧凑的 PNG 图像来减少令牌使用量。它专为高密度上下文而设计，例如工具输出、日志、代码、系统提示词以及较早的对话历史。

pxpipe 如何降低 Fable 5 的成本？

它利用了这样一个事实：图像令牌成本主要与像素尺寸相关，而文本令牌成本会随着文本量增加而增长。如果模型能够可靠地读取高密度渲染文本，那么大块内容以图像形式传输，可能比纯文本更便宜。

pxpipe 会压缩模型输出吗？

不会。pxpipe 只会在请求发送之前压缩选定的输入块。模型的

响应仍会像普通文本一样持续流式传输，因此输出 token 并不会减少。

基于图像的上下文压缩是无损的吗？

不是。这是一种有损压缩方法。它对于宽泛上下文、状态跟踪以及许多编码任务都可能效果不错，但像 ID、哈希、密钥和精确数字这样的精确字符串可能会被误读。

我可以将 pxpipe 与任何模型一起使用吗？

不能安全地这么做。pxpipe 自身的文档将模型支持视为有限且依赖具体工作负载。有些模型读取高密度渲染文本的能力比其他模型差得多，因此不受支持或较弱的模型应当以文本形式直通，除非被显式启用。

哪些类型的内容应该保留为文本？

ID、哈希、密钥、精确数字、用户消息、最近几轮对话，以及其他对精度要求极高的内容块，都应保留为文本。pxpipe 更适合较长、密集、对字节精确度不那么敏感的材料，例如日志、工具文档和较早的历史记录。

如何在本地运行 pxpipe？

先使用 npx pxpipe-proxy 启动代理，然后通过 ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude 运行 Claude Code。本地仪表板可通过 http://127.0.0.1:47821/ 访问。

摘要

pxpipe 展示了一种巧妙的方法来降低 Fable 5 的输入成本：将高 token 消耗的上下文渲染为紧凑图像，并让模型通过其视觉能力读取这些图像。对于高密度编码工作负载，这可以显著降低请求侧的

令牌使用量更低，端到端成本也更低。

权衡之处在于，这种方法是有损的。对于许多编程和状态跟踪工作流，它可以保留足够多的意义，但不应依赖它来实现对 ID、哈希、密钥或精确数字的逐字节精确回忆。

更广泛的一点是，在 AI 系统内部，文本并不总是必须以文本形式存在。CLIPPO、DeepSeek-OCR 和 pxpipe 都指向同一个理念：像素可以成为长上下文的一种实用压缩层。

最佳使用场景很明确：压缩体积大、低精度的上下文，但将关键的精确数值保留为普通文本。