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

引言Fable 5 社区最近开始关注一个看起来相当“复古”的技巧：把冗长的文本上下文转换成高密度图像，再让模型通过其视觉能力把图像内容读回来。这听起来几乎像是在为考试制作一张微型小抄。但这次，“小抄”不是给人看的，而是给能够读取截图的多模态模型看的。一位开发者发现，把 Claude Code 的上下文转换为紧凑的 PNG 图像后，在测试工作负载中，输入 token 成本大约可以下降 59% 到 70%。其基本思路很简单：系统提示、工具文档、命令输出、日志以及较早的对话历史通常都会消耗大量 token。如果把这些内容块渲染成图像，那么它们的图像 token 成本主要取决于图像尺寸，而不是图像中塞进了多少文本。本文将介绍 pxpipe 的工作方式、为什么这种方法可以省钱、它会在哪些情况下失效，以及它与更早的研究（如 CLIPPO）和较新的光学上下文压缩工作（如 DeepSeek-OCR）之间的联系。## 来源说明本文基于 BAAI Hub 发布的中文原文撰写，该文称消息源自微信公众号 QbitAI。原始参考链接包括 pxpipe 的 GitHub 仓库和 CLIPPO 论文。下文保留的图片均为与文章相关的截图、演示图、示意图和社交讨论截图。二维码、推广关注提示、互动号召以及与内容无关的平台装饰均已移除。## 把上下文变成“小抄”，然后砍掉账单这项走红的方法叫做 pxpipe。它是一个开源的本地代理，会在请求离开你的设备之前，重写体积庞大的 Claude Code 输入上下文。根据项目说明，pxpipe 通过把大块文本渲染成图像来减少 token 使用量。当模型足够擅长读取高密度渲染文本时，同样的系统提示、工具文档、工具输出和较早历史记录，就可以被压缩进一个小得多的 token 占用中。在一个示例中，大约 48,000 个字符的系统提示和工具文档，如果以纯文本形式输入，需要大约 25,000 个 token。将相同内容渲染为一张 1573 × 1248 的图像后，据称只用了大约 2,700 个图像 token。成本下降的关键，就在这个差异上。粗略的原理如下：1. 文本 token 成本会随着文本量的增加而增长。

1. 图像 token 成本主要由像素尺寸决定。
2. 密集的代码、JSON、工具输出、系统提示词和日志，往往每一行都包含很多 token。
3. 如果模型仍然能够可靠地读取压缩后的图像，那么同样的上下文发送起来就会更便宜。一些开发者开玩笑说，这简直是“千言万语不如一张图”的字面案例。这里，这个玩笑却出乎意料地接近技术现实。## pxpipe 实际上做了什么pxpipe 不是一种新模型，也不是传统的 OCR 引擎。它作为 Claude Code 与模型 API 之间的本地代理运行。在请求发送出去之前，pxpipe 会寻找适合压缩的大块内容。然后它会把这些内容渲染成紧凑的 PNG 页面，并作为图像输入重新放回请求中。模型通过其常规视觉通道读取这些页面。简单来说，pxpipe 的行为就像一台面向长上下文的自动微型打印机。严格按照工程学意义来说，它并不是让模型去“做 OCR”识别文本。相反，它依赖的是模型内置的、读取类似截图视觉输入的能力。pxpipe 的 README 解释说，它主要处理以下这类体积庞大的输入上下文：- 大型 tool_result 内容，包括文件读取结果、命令输出和日志。

• 较早且已折叠的对话历史。
• 静态系统提示词和工具文档。它会刻意避免把一切都转换掉。最近几轮对话、用户消息、精确标识符、小块内容、稀疏散文以及模型输出仍然保留为文本。## 为什么它能节省这么多核心的定价错配在于，图像输入和文本输入的计量方式不同。对于文本密集型的开发者工作流，源材料通常具有很高的 token 密度。代码、日志、JSON、堆栈跟踪和工具 schema 以纯文本形式发送时，成本可能很高。pxpipe 的作者估计，在真实的 Claude Code 流量中，这类高密度内容每个图像 token 大约可容纳 3.1 个字符，而每个文本 token 大约只能容纳 1 个字符。这个比例让 pxpipe 在文本足够密集时有空间降低成本。作者还分享了一个对比演示。在原始文本版本中，据称一次测试运行最终账单为 42.21 美元，且上下文窗口几乎被占满。而在 pxpipe 版本中，同样的任务以 6.06 美元完成，并且剩余了更多的上下文空间。一个重要细节是，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在图像
• 文本任务表现的直观呈现。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/91a2665d-2d20-4b76-9dfe-a9416cf2685c-09-fc96a503-72cb-43c4-9f12-52f05dcbd382.png)报告中的基准测试表简化后如下所示：| 测试 | 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 自己的说明也强调了这一点：这种权衡非常严肃，其失败模式可能不是明显报错，而是给出一个自信但错误的答案。下方这条推文由 @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 指向这个代理。```Bash
  npx pxpipe-proxy # 在 127.0.0.1:47821 上运行代理
  ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude # 让 Claude Code 指向它

启动后，pxpipe 还会提供一个本地仪表盘：Plaintext
http://127.0.0.1:47821/

传统的 CLIP 风格模型通常采用双塔结构：一塔处理图像，另一塔处理文本。CLIPPO 则取消了这种划分，它将文本渲染为 RGB 图像，并将图像和渲染后的文本一起送入共享的 Vision Transformer。这里的重要启示是：文本并不总是必须以离散文本 token 的形式输入模型。它也可以被转换为像素，并通过视觉通路进行处理。## DeepSeek-OCR 与光学上下文压缩讨论还提到了 DeepSeek-OCR，它专注于面向长上下文的光学压缩。其代码仓库将该项目描述为“上下文光学压缩”。![图片展示的是一个GitHub页面，页面标题为“deepseek

• ai/DeepSeek
• OCR: Contexts Optical Compression”。页面显示贡献者1人，问题248个，星标23k，fork 2k。下方有Matthew Campbell的评论，提到Deepseek在2025年10月也发布过类似内容，不确定这次还有什么新意。该图片与文档中关于pxpipe和DeepSeek
• OCR的讨论相关，表明pxpipe与DeepSeek
• OCR在光学压缩方面有相似之处，引发对二者关系的思考。](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c078a32c-73e0-4766-bc59-9c40d0253f1e-14-ab418c5b-0ed8-4a8c-b44b-fa0edae93c3a.png)从这个意义上说，pxpipe 不只是一次性的成本优化技巧。它连接了几个趋势：1. CLIPPO 证明了文本可以作为图像来处理。

1. DeepSeek-OCR 探索了长上下文的光学压缩。
2. Fable 5 似乎已经足够擅长高密度视觉阅读，使这项能力能够在真实编码工作流中变得实用。不过仍然存在一个硬性限制：精确字符串的可靠性。一些评论者认为，只要把更强的视觉语言模型继续做大，这个问题可能就会改善。## 实际要点当上下文规模大、内容密集且不要求极高精度时，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：一个本地代理，会将体积庞大的 Claude Code 上下文渲染为 PNG 图像，以减少输入 token 使用量。

• Claude Code：Anthropic 的智能体式编码工具，适用于终端、IDE、桌面端和浏览器工作流。
• Anthropic Messages API：用于发送 Claude 风格消息请求的 API 接口。
• Anthropic Token Counting：用于估算消息请求中 token 数量的官方 API 参考。
• DeepSeek-OCR：一个探索长上下文文本光学压缩的开源项目。## 相关链接- Original BAAI Hub Article：讨论这一走红的 pxpipe 成本节省方法的中文原始文章。
• pxpipe GitHub Repository：项目源代码、README、基准测试、限制说明和使用命令。
• CLIPPO Paper on arXiv：2022 年的一篇论文，探讨了仅基于像素的图像与语言理解。
• DeepSeek-OCR GitHub Repository：Contexts Optical Compression 的官方代码仓库。
• Claude Code Documentation：在不同环境中使用 Claude Code 的官方文档。
• Anthropic Computer Use Tool：关于 Claude 基于截图进行计算机交互能力的官方文档。
• Anthropic Messages API：向 Claude 模型发送基于消息请求的官方参考。## 摘要pxpipe 展示了一种巧妙的方法来降低 Fable 5 的输入成本：将高 token 消耗的上下文渲染为紧凑图像，并让模型通过其视觉能力读取这些图像。对于高密度编码工作负载，这可以显著降低请求侧的令牌使用量更低，端到端成本也更低。权衡之处在于，这种方法是有损的。对于许多编程和状态跟踪工作流，它可以保留足够多的意义，但不应依赖它来实现对 ID、哈希、密钥或精确数字的逐字节精确回忆。更广泛的一点是，在 AI 系统内部，文本并不总是必须以文本形式存在。CLIPPO、DeepSeek-OCR 和 pxpipe 都指向同一个理念：像素可以成为长上下文的一种实用压缩层。最佳使用场景很明确：压缩体积大、低精度的上下文，但将关键的精确数值保留为普通文本。