Pxpipe 评测：图像真能把 Claude Code 成本降低 60% 吗？

pxpipe 作者报告称，在测量的 Fable 5 Claude Code trace 上，端到端账单降低 59% 至 70%。这是特定 workload 的供应商 benchmark，同时引入新的正确性风险。代理会把符合条件的大块上下文，例如系统 prompt、工具文档、旧历史和大型工具结果，转成图像。最近轮次仍为文本；有限 factsheet 只保留部分被识别的关键字符串，并不保证每个标识符都留在图像之外。

这套逻辑听起来很荒诞，也正因如此才走红。在固定模型的视觉规则下，图像 token 数取决于图像几何，而不是其中有多少可读文字。因此，同样的字符渲染成密集图像后，处理成本可能低得多。

正在流传的工具是 pxpipe，一个开源（MIT）的本地代理。它位于你的机器和 API 之间，在请求离开你的笔记本之前，把体积庞大、大多静态的上下文渲染成密集的 PNG「页面」。仓库自带的演示显示，同一个多步骤任务作为纯文本花费 42.21 美元，用 pxpipe 则是 6.06 美元。它声称在 Fable 5 上按当前挂牌价可把端到端账单降低 59% 到 70%。

我们在 2026 年 9 月 2 日全面复核后的结论是：在兼容模型上，视觉计数可以让密集图像文本更便宜，但 pxpipe 应是对容错上下文进行测量后的优化，而不是生产默认值。关键在于 eval 能否在模型采取行动前发现被静默误读的标识符。

它为什么真的有效：定价的物理

文本与图像输入的计数方式不同。实际费率取决于模型和供应商价格表，因此减少视觉 token 本身不能证明账单会按相同比例下降。

Anthropic 当前把图像计为 28×28 像素视觉 patch：ceil(宽 / 28) × ceil(高 / 28)。超过模型层级的长边或视觉 token 上限时会缩小。标准层级上限为 1,568px 和 1,568 token；Claude 4.7 及更新高分辨率模型为 2,576px 和 4,784 token。这取代旧的 (宽 × 高) / 750 近似公式，也否定了通用的每图约 1,600 token 上限。Anthropic 视觉文档。

仓库在其实测 Claude Code 流量上报告，每个图像 token 约 3.1 个字符，而每个文本 token 约一个字符。图示密集页面是另一个几何特定案例：约 48,000 字符、25,000 文本 token 与 2,700 图像 token，相当于每视觉 token 约 17.8 字符。两者不能组合成通用盈亏阈值；密度、页面几何、模型计数、缓存类别、输出和未转换流量都会影响结果。

这就是模型实际收到的、用来替代你文本的东西：

一张画布不能容纳无限上下文。供应商限制图像数量、请求大小、分辨率和视觉 token，过大图像也可能被缩小。pxpipe 因此按模型专属 profile 生成多页。实际节省取决于这些页面与目标模型，而不是通用单图上限。

这不是奇技淫巧，而是一个研究方向

那个反直觉的部分，也就是文字的图像可能比文字本身更便宜，并不是某个代理工具的花招。它是一个活跃的研究领域。

DeepSeek-OCR 预印本报告称，当文本 token 少于视觉 token 的十倍时 OCR 精度为 97%，20× 压缩时约为 60%。这是模型特定 OCR 结果。经评审的 EMNLP 2025 Findings 论文 Text or Pixels? It Takes Half 在 RULER 与 CNN/DailyMail 实验中报告，decoder token 通常接近减半且任务表现未下降。

研究证明这是合理方向，却不能证明它适用于每个模型、字体、密度或任务。pxpipe 用模型专属渲染 profile 与作者自测，把这一思路用于商业多模态 API。风险正存在于已测 profile 与未测 workload 之间。

让它对大多数工作都显得荒诞的那个坑

把文本渲染成图像是有损的，而且损失是无声的。

作者当前的密集十六进制测试中，Fable 5 为 13/15，Gemini 3.6/3.7 Flash 为 14/15，Opus 5 为 2/15，GPT-5.6 Sol 在旧密集 profile 上为 0/15。仓库对 Sol 当前 14px profile 只提供了另一个 7/8 小型试验。这些小样本、profile 特定结果不能跨模型泛化。

所有需要逐字节准确的内容都必须通过明确政策保留为文本，包括 ID、哈希、密钥、精确数字和名字。pxpipe 保留最近轮次，并可在有限 factsheet 中放入最多 96 个被识别的关键 token，但仓库明确表示完整的逐字保护 guard 尚未实现。

标题还跳过了这几点：

• 它依赖模型。作者测试报告 Fable 5 为 13/15、Gemini 3.6/3.7 Flash 为 14/15、Opus 5 为 2/15，Sol 在旧 profile 上为 0/15。默认开启 Fable 与 Gemini；Opus 与 Sol 需手动开启。
• 它增加延迟。把大请求编码成 PNG 需要时间，而这发生在请求离开你的机器之前。
• 它和提示词缓存相互影响。最大、最静态的上下文也是理想的缓存对象。在 Anthropic 路径上，pxpipe 会保留或移动现有 cache_control 边界，让图像前缀继续可缓存；OpenAI 路径则单独统计缓存 token。各提供商语义不同，因此应与观测到的热缓存基线比较。Anthropic 的提示词缓存指南说明，缓存读取价格只是标准输入价格的一部分。

什么时候值得，什么时候会把你烧到

这不是一个是或否的问题。它是一个路由决策，和我们在选择模型时用的是同一套纪律。让技术去匹配负载。

如果你的负载是一大块庞大而稳定的指令，喂给一个大多只需要大意的 Fable 5 智能体，渲染可能是一次实打实的胜利。如果它是一个搬运精确数字和标识符的合规流程，同一个技巧就是一份无声的负债。

它在真实的成本栈里处于什么位置

把上下文渲染成图像是一根杠杆，而且不是我们会先拉的那一根。在动用一个有损技巧之前，通常是那些无聊的杠杆取胜，而且它们不会让你的数据冒险：

• 提示词缓存用于静态前缀，它是无损的，而且本就很大。
• 模型路由：便宜的模型做机械活，强的模型做判断。参见我们如何在 Fable、Opus、Sonnet 和 Haiku 之间路由工作。
• 衡量每完成一个任务的成本，而不是每 token 的价格，因为那才是落在你账单上的数字。参见每 token 更便宜，每个答案更贵。
• 一个网关用来集中管理回退、缓存和支出上限。参见我们的LLM 网关对比。
• 自托管或开放权重，当规模和数据驻留能够证明其合理时，详见在欧盟自托管 LLM 的真实成本。

把上下文渲染成图像处在这份清单激进的一端：潜在节省高，正确性风险真实，在更安全的杠杆都就位之后，值得在合适的负载上做一次试点。

该拉哪个杠杆、按什么顺序拉，衡量标准是真实账单而不是基准分数，这正是我们AI 落地服务背后的工作：先把当前支出做上埋点，再把无损的杠杆用尽，最后把任何有损的手段放在一道真能抓出错值的评估之后。Twinsoft AI 就是把同样的顺序用在一套生产系统上，而我们的技术选型指南写明了通用规则：按那些一旦选错就很难回头的约束来决定。

"定价的物理是真的，研究也是认真的。但一个偶尔会编造哈希或名字的 60% 节省不是节省，而是被推迟的调试。渲染那些只需要大意的大批量上下文，把每一个精确的值都保持为文本，永远不要把它指向一个读不好图像的模型。"