你刚打开 Claude Code，准备改一个中型项目。还没敲第一行指令，系统提示和工具文档已经吃掉了 20,000 token。翻一下对话历史——昨天的调试会话、前天的重构记录——又是 15,000 token。真正属于你当前任务上下文的空间，只剩下一小半。
这不是偶然。Claude Code 的长上下文窗口在工程上是个好东西，但在账单上是个坏消息：输入 token 按量计价，而这些「背景板」内容每次请求都要重新发送。
teamchong 写了一个叫 pxpipe 的工具，走了一条相当直接的路径来解决这个问题：把文本渲染成 PNG 图片，让 Fable 去「看」而不是「读」。
核心机制：像素比字符便宜
pxpipe 是一个本地 HTTP 代理，夹在 Claude Code 和 Anthropic API 之间。它拦截 outgoing 请求，把三类内容渲染成紧凑的 PNG 图片：(1) 大型 tool_result 返回值，(2) 旧对话历史，(3) 系统提示和工具文档的静态部分。近期对话保持文本不压缩，关键的标识符（SHA 哈希、数字常量）以 sidecar 文本形式单独保留。
这个策略之所以有效，根源在于 Anthropic 图像定价模型的一个特征：图片 token 按像素尺寸计算，不管里面塞了多少文字。一张 1568px 宽度的图片，无论内容是单行 hello world 还是 92,000 字符的 JSON 输出，token 数量是固定的。
这就形成了一个套利空间。文本 token 在高维向量空间中每个 token 对应约 8KB 的 KV cache——hidden dimension 达到 2^16 级别时，每个 token 的表示成本天然很高。而视觉 token 按 16×16 像素分块，一个视觉 token 可以编码远多于一个文本 token 的文字信息。用 pxpipe 官方 README 的数据：一张 1928×1928 的 PNG 约等于 4,761 个 vision token，却能容纳约 92,000 字符——同等文字按文本 token 编码需要 25,000+ token。
这不是魔术。DeepSeek-OCR 论文（arxiv 2510.18234）已在学术层面验证了同一方向：视觉-文本压缩可以实现 7-20 倍的 token 削减，通过调参（patch size、vision encoder 复杂度）可以在压缩率和准确度之间取得平衡。
实测：59-70% 的成本削减
pxpipe 团队在真实 Claude Code 流量上做了两组测量。第一组是 13,709 个请求快照，端到端节省约 59%——$100 的账单变成约 $41。第二组是后期 8,904 个请求的完整 trace，节省比例上升到约 70%。在压缩生效的请求上，单请求大小下降 72-74%。
这些数字会随工作负载变化——token 密度越高，节省越显著；短小稀疏的请求 pxpipe 会选择跳过，避免为小请求引入图片编码的开销。
SWE-bench 基准测试提供了更严谨的证据。在 SWE-bench Lite 上，10 个实例中 pxpipe ON 和 OFF 两臂结果完全一致，节省 65% 的请求大小。SWE-bench Pro 上则出现了一个微妙的分化：pxpipe ON 臂解决了 14/19，OFF 臂解决了 15/19——差一个实例；但两臂的判定一致率达到 18/19。换句话说，在绝大多数任务中，走图片路径的模型表现与纯文本路径几乎无差别，但确实存在边界 case。
图：pxpipe 将文本上下文渲染为 PNG 的示例。来源：https://raw.githubusercontent.com/teamchong/pxpipe/main/docs/assets/example-render.png
诚实的代价：有损压缩的边界
把文本变成图片再 OCR 回来，必然是一个有损过程。pxpipe 的文档对此相当坦诚。
最显著的失败模式出现在密集渲染场景中。在一项 needle-haystack 测试里，模型需要从图片中召回 12 字符的十六进制串。Fable 5 的召回率是 13/15，而 Opus 4.8 是 0/15——完全找不到。所以 pxpipe 默认只对 Fable 5 和 GPT 5.6 启用图片压缩，Opus 4.8 需要手动开启，文档明确标注其「对图片内容的误读率约 7%」。
这意味着 pxpipe 有明确的适用边界。编码姓名、API 密钥、精确数字常量、SHA 哈希等不可出错的信息时，这些内容必须放在 sidecar 文本里，不能进图片。工具文档里的大段说明文字、历史的调试日志、JSON schema 定义——这些「大致对就行」的内容，是压缩的理想目标。简而言之：语义容错的内容可以压缩，精确匹配的内容不能。
另一个边界是模型本身。Gemini 已经在后端做了 OCR 再喂给模型，不额外收费——这说明「先压缩再理解」有可能成为一个独立的架构方向。但 pxpipe 的效果依赖 Anthropic 的定价体系——如果图像计价规则某天调整，套利空间会直接消失。这属于定价层面的套利，架构层面并没有变化。
社区分歧：漏洞还是规律？
HN 上的讨论（item 48776464）清晰地分成了两派。
一派认为这是 Anthropic 的定价漏洞，迟早会被修复。「你把文本塞进 PNG 来省钱，本质上就是在钻空子。」这种观点将 pxpipe 归类为 clever hack——有用，但不可持续。
另一派的论证更底层。他们指出 DeepSeek-OCR 论文已经从信息论角度证明，视觉 token 编码文本的效率的确可以比文本 token 高一个数量级。问题出在文本 token 的表示方式上——LLM 的 hidden dimension 很大，每个 token 要消耗大量 KV cache，这导致文本 token 的「单位信息成本」天然高于视觉 token。从这个角度看，pxpipe 暴露的是表示效率的本质差异——定价差异只是这一差异的表层体现。
两边的论证各有重量。但有一个事实是确定的：在 Anthropic 改变定价策略之前，pxpipe 确实能让 Fable 5 的账单看起来舒适很多。
30 秒上手
用法极其简单：
npx pxpipe-proxy然后在另一终端：
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude代理会自动处理后续请求。无需修改 Claude Code 配置，无需 API key 二次配置。MIT 协议，代码全部开源。
趋势判断：压缩比 hack 更可能成为方向
pxpipe 的有趣之处，是它触及了一个比「省钱技巧」更大的问题：当我们讨论 token 优化时，到底在优化什么？
如果目标是降低推理成本，那么 DeepSeek-OCR 路线——用轻量视觉编码器压缩上下文再交给 LLM 理解——比在文本 token 层面抠字眼有更大的优化空间。Gemini 已经在这条路上走了：后端先 OCR，模型看到的仍然是文本，但输入侧的 token 成本已经按图片算了。这是一种架构选择。
当然，pxpipe 今天仍然是一个聪明的工具而非一个严肃的架构方案。它的价值取决于 Anthropic 的定价政策是否改变，取决于有损压缩在具体任务上的容错边界，也取决于开发者是否愿意接受「我的代码在被一张图片转述」这个略显荒诞的事实。
本文的素材来自 HN 相关讨论和项目公开文档。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
参考链接：