pxpipe：把 Claude Code 的文本上下文渲染成图片，token 能省多少？
通过将文本上下文渲染为图像来减少《神鬼寓言 5》标记的使用。阅读器与 Anthropic 的计算机使用的屏幕截图所依赖的视觉通道相同。
秒懂
- 它是什么？
- pxpipe 是一个本地代理，把 Claude Code 请求里的系统提示、工具文档和旧历史转成 PNG，利用视觉通道降低 token 消耗。实测数据来自项目自带的评估，但它在精确标识符上会丢字，适合场景有限。
- 适合谁用？
- 如果你的工作负载是代码、JSON、工具输出这类 token 密集内容，且你能容忍非精确标识符偶尔被模型幻觉替换，pxpipe 值得一试。它不适合处理字节精确值（ID、哈希、密钥）的场景，这类内容必须留在文本通道。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 5 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的问题：token 账单里藏着大量重复文本
Claude Code 这类 agent 每次请求都会把系统提示、工具定义、历史对话重新发给模型。这些内容大部分没变，但按 token 计费。pxpipe 的切入点很直接：一张图片的 token 成本由像素决定，和里面写了多少字无关。项目 README 给出的数字是，密集内容（代码、JSON、工具输出）大约 3.1 字符对应一个图像 token，而文本是 1 字符一个 token。也就是说，同样一段 48k 字符的系统提示加工具文档，文本形式约 2.5 万 token，渲染成一页 PNG 后约 2.7 千图像 token。这个思路不是新发明，Anthropic 的 computer use 早就用视觉通道读截图，pxpipe 只是把同一通道用来读上下文。它的目标用户是重度使用 Claude Code、账单里 token 消耗大头是重复 bulk 内容的开发者或团队。
机制：本地代理改写请求，只压缩入站不碰出站
pxpipe 是一个跑在 127.0.0.1:47821 的本地代理。启动后把 Claude Code 的 ANTHROPIC_BASE_URL 指到它，它拦截 /v1/messages 请求，把其中体积大的文本部分渲染成 PNG，再转发给 Anthropic。模型读的是图片，不是原始文本。代理只压缩请求方向，模型的输出照常流式返回，不经过任何改写。最近的对话轮次保持文本，系统提示、工具文档和较早的历史被图像化。判断哪些内容该转图不是拍脑袋，项目里有一个基于 391 条生产数据校准的 profitability gate，只在数学上划算时才转。这个设计避免了无脑压缩所有文本，因为稀疏的散文（约 3.5 字符/token）转图反而亏钱。
启动方式：两条命令，外加一个离线导出模式
快速上手就两步：先跑 npx pxpipe-proxy 启动代理，再把 Claude Code 指过去。README 给了完整命令：npx pxpipe-proxy 监听 127.0.0.1:47821，然后 ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude。代理自带一个仪表盘，地址是 http://127.0.0.1:47821/，能看到 token 节省量、每次文本转图像的对照、一个 kill switch 和模型选择。不想改环境变量的可以用 pxpipe warp -- claude，它支持 cursor-agent、codex 或 shell alias，这样 /remote-control 和 claude.ai 连接器也能工作。如果 agent 走的是其他 base URL，需要加路由规则，比如 pxpipe warp --route '127.0.0.1:9090/v1/*=http://127.0.0.1:47821' -- codex。另外还有一个不经过代理的离线导出：npx pxpipe-proxy export src/ 或 cat prompt.txt | npx pxpipe-proxy export --stdin，会生成一个 pxpipe-export-XXXXXX/ 目录，里面有 page-*.png、factsheet.txt、manifest.json 和 prompt.txt，可以手动把图片上传到 Cursor 这类客户端。
实测数字：token 削减真实存在，但账单节省有前提
README 里最硬的数字来自 SWE-bench Lite 试点：10/10 两臂都通过，请求体积减少 65%。SWE-bench Pro 是 14/19（开启）对 15/19（关闭），体积减少 60%，判定一致 18/19，唯一分歧在复现时 3/3 重新解决。作者自己说样本量小，证据在 eval/ 目录。token 削减本身是实打实的，但换算成账单节省要看客户端行为。Claude Code 会把系统、工具、历史作为未缓存 bulk 重新发送，所以能省 60% 到 70%。如果客户端已经缓存了这些内容，或者走的是稀疏散文，节省就会缩水甚至变成亏损。项目给出的端到端账单降低 59% 到 70% 是基于 Fable 列表价，作者也提醒价格会变、负载不同，真正可靠的指标是 token 削减本身，可以用 ~/.pxpipe/events.jsonl 里的 count_tokens 对照来量。
诚实声明：图像通道会丢精确性，这不是 bug 是特性
pxpipe 自己承认是有损压缩。实测里，密集图像内容中的 12 字符十六进制字符串，Fable 5 上 13/15 正确，Sol 上 0/15。更危险的是，错误不是报错，而是模型安静地编造一个看起来合理的值。字节精确的 ID、哈希、密钥必须留在文本通道，代理也确实这么做了：最近的对话轮次保持文本，factsheet 会选择性保留最多 96 个被识别为精度关键的 token。但项目明确说，专门针对 verbatim 风险的防护还没建。这意味着如果你在代码里贴了一长串 API key，或者依赖精确的 commit hash，把那段内容转成图片就是在赌模型能看清每个字符。对于视觉模型来说，小字号、低对比度、密集排版的文本本来就容易读错，pxpipe 的渲染参数（默认 100/100 reader）能缓解但不能消除。
模型兼容性：默认白名单只有三个，其他要手动开
pxpipe 不是对所有模型一视同仁。默认的 PXPIPE_MODELS 是 claude-fable-5、gemini-3.6-flash、gemini-3.7-flash。Opus 5、Sol、GPT 5.5 和 Grok 需要手动在仪表盘或环境变量里开启。Sol 的 ID 必须精确匹配，像 gpt-5.6-terra 这种兄弟变体不会自动继承 Sol 的允许列表或渲染配置。PXPIPE_MODELS=off 可以完全禁用图像化，其他情况全部原样透传。不同模型的渲染 profile 也有差别：基础 profile 保留最近六对已完成的函数调用，允许 32 张图；Sol 只保留一对但允许 64 张；Grok 允许 24 张。GPT 路径上工具定义保持原生 JSON，不用 Anthropic 的 cache_control 标记。这些细节说明，pxpipe 的优化是逐模型调过的，不是一套参数走天下。如果你的主力模型不在默认列表里，得先确认它被支持，否则可能白跑。
维护与许可：MIT 协议，但升级和故障排查要自己来
项目是 MIT 许可，可以自由使用、修改、商用，没有附加限制。最近一次发布是 v0.13.2，更新节奏看起来是月度级别，v0.13.0 到 v0.13.2 间隔不到两周，说明还在活跃迭代。但 README 里没有提到升级路径或迁移指南，代理的配置和渲染参数都可能在版本间变化，升级前最好先看 changelog 或跑一次离线导出验证输出格式。故障排查方面，events.jsonl 记录了每次转换的 token 数，仪表盘有 kill switch，但没有任何自动回退机制。如果代理崩溃，Claude Code 会直接连不上，因为 base URL 被指到了本地端口。建议在关键任务前手动测试代理稳定性，或者准备一个不经过代理的备用启动脚本。整体上，这个项目的维护成本取决于你是否愿意跟踪版本更新，以及你是否接受图像通道在精确性上的妥协。
编辑结论
如果你的工作负载是代码、JSON、工具输出这类 token 密集内容，且你能容忍非精确标识符偶尔被模型幻觉替换，pxpipe 值得一试。它不适合处理字节精确值（ID、哈希、密钥）的场景，这类内容必须留在文本通道。采用前先在 ~/.pxpipe/events.jsonl 里跑几轮真实请求，用 count_tokens 对比同一请求的文本与图像 token 数，确认你的客户端确实会重发未缓存的 bulk 内容。还要检查你的模型是否在默认允许列表（claude-fable-5、gemini-3.6-flash、gemini-3.7-flash）内，否则需要显式配置 PXPIPE_MODELS。项目是 MIT 许可，代理本身不改动模型输出，但图像渲染的 lossy 特性决定了它不能作为通用压缩方案。
社区笔记