Anthropic 的图片定价有个”漏洞”：一张图片的 token 费用只看像素尺寸，不管里面塞了多少字。pxpipe 正是利用这一点，把你的系统提示词、工具文档、旧聊天记录这些冗长的文字全部渲染成 PNG，塞进一张 1928×1928 的图片里。原来 25000 token 的系统提示，变成图片只要 2700 token。
这不是什么理论推演，是实打实的账单对比：Fable 5 一场完整会话，纯文本跑下来花了 $42.21，用 pxpipe 只花了 $4.51。13,709 个生产请求的平均节省是 59%，压缩请求的节省接近 70%。
听起来有点邪门？确实。但数据摆在那儿，而且工具已经开源了。本文就讲清楚它怎么用、省多少、哪里会翻车。
30 秒上手
两条命令就能跑起来：
npx pxpipe-proxy
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude第一条启动本地代理，监听 `127.0.0.1:47821`。第二条让 Claude Code 把请求发到这个代理而不是 Anthropic 官方 API。代理拦截请求，把大块文字渲染成图片，再把改写后的请求转发给上游。整个过程对你来说完全透明——你还是正常用 Claude Code，只是账单变低了。
启动后访问 `http://127.0.0.1:47821/` 可以看到 Dashboard：已节省的 token 数、每次转换的并排对比、紧急停止开关、实时模型状态。比盲跑安心不少。
如果你不想用代理模式，也可以当库调用：
import { renderTextToImages, transformAnthropicMessages } from "pxpipe-proxy";
const { pages } = await renderTextToImages(toolResultText);
const { body, applied, info } = await transformAnthropicMessages({
body: requestBytes,
model: "claude-fable-5",
});这种方式适合你自己搭工具链，不依赖代理转发。
为什么图片比文字便宜
Anthropic 的计费规则是这样的：文字按字符算，大约一个字符一个 token。图片按像素算——一张 1928×1928 的 PNG 大约消耗 4,761 token，不管图片里写了多少字。
pxpipe 用 5×8 的代码字体图集渲染文字，100 列软换行。一张图片能塞大约 92,000 个字符。如果这些字符当纯文本发，要消耗约 91,000 token。塞进图片里，只消耗约 4,761 token。压缩率接近 19 倍。
当然，实际流量里不是所有文字都这么密。Claude Code 的真实流量大约是 1.91 字符/token，所以实际节省达不到 19 倍，但 59-70% 是实测数据。
到底省了多少
先看官方数据：
| 数据来源 | 请求数 | 节省比例 |
|---|---|---|
| 生产快照 | 13,709 | 59%（$100 → ~$41） |
| 后续追踪 | 8,904 | ~70% |
| 仅压缩请求 | — | 72-74% |
再看 Fable 5 的 A/B 对比：
| 指标 | 纯文本 | pxpipe |
|---|---|---|
| 费用 | $42.21 | $4.51 |
| 上下文使用 | 96% 满 | 73.5k/1M（有余量） |
| Token 精确计数（39个文件） | 10/10 | 10/10 |
上下文利用率的变化也值得注意：纯文本模式已经把 1M 窗口塞到 96%，几乎撑满；pxpipe 只用了 73.5k，还有大量余量可以继续对话。这意味着不只是省钱，还可能让你在长任务里少撞上下文上限。
之前我们聊过 AI 编程助手的 token 省钱方案，那篇讲的是 Codebase Memory MCP 和 Headroom 两款工具。pxpipe 的思路完全不同——不是减少上下文内容，而是换一种更便宜的编码方式把同样多的内容塞进去。如果你的项目比较大、Claude Code 经常撞上下文墙，pxpipe 可能比删减上下文更管用。
它压缩了什么，没压缩什么
pxpipe 不会把所有文字都变成图片。它有选择性：
会被压缩的内容：
- 大型 `tool_result`（文件读取、命令输出、日志）——超过约 6k 字符的密集内容
- 旧的折叠历史——活跃尾部之后的对话轮次被重新渲染为图片页面
- 静态系统提示 + 工具文档块
不会被压缩的内容：
- 你最近发的消息和模型的最近回复
- 模型的输出（代理从来不碰响应）
- 稀疏的散文内容
- 太小不值得压缩的内容
- 不在白名单里的模型——完全透传，不做任何处理
这个设计逻辑很清楚：最新的、需要精确处理的对话保持文字，旧的、密集的、只当参考的上下文变成图片。既省钱又不影响当前对话质量。
支持哪些模型
默认启用两个模型：
PXPIPE_MODELS=claude-fable-5,gpt-5.6Fable 5 是目前效果最好的——基准测试里 100% 准确率，图片阅读能力没有退化。GPT-5.6 也默认启用。
其他模型需要手动开启，因为效果有折扣：
| 模型 | 状态 | 说明 |
|---|---|---|
| claude-fable-5 | ✅ 默认启用 | 图片阅读 100% 准确 |
| gpt-5.6 | ✅ 默认启用 | 支持 |
| claude-opus-4-8 | ⚠️ 可选 | 误读约 7% 的渲染内容 |
| claude-opus-4-7 | ⚠️ 可选 | 同样误读约 7% |
| gpt-5.5 | ⚠️ 可选 | 图片上下文性能退化 |
如果你用的是 Opus 4.8 或 GPT-5.5，想开启 pxpipe，设环境变量：
PXPIPE_MODELS=claude-fable-5,gpt-5.6,claude-opus-4-8 claude或者直接在 Dashboard 上通过模型芯片切换。
如果你想完全禁用图片渲染（比如跑一个特别需要精确性的子任务），设 `PXPIPE_MODELS=off`。
子代理还有个逃生舱：在 agent frontmatter 里写 `model: sonnet`，或者设环境变量 `CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6`，这样子任务会用不压缩的文本模式跑。
基准测试：靠谱吗
开发者做了不少测试，结果相当有意思：
新颖随机数算术题（模型不可能背答案）：
| 模型 | 文本准确率 | 图片准确率 | Token 节省 |
|---|---|---|---|
| claude-fable-5 | 100% | 100% | -38% |
| claude-opus-4-8 | 100% | 93% | -38% |
Fable 5 在图片模式下做数学题的准确率和纯文本完全一样。Opus 4.8 会误读约 7%。
SWE-bench（代码修复能力）：
| 基准 | 纯文本 | 图片 | 请求大小变化 |
|---|---|---|---|
| SWE-bench Lite | 10/10 | 10/10 | -65% |
| SWE-bench Pro | 15/19 | 14/19 | -60% |
Lite 完全没影响，Pro 略差一个（18/19 判决一致，分歧项复制后 3/3 解决）。
精确字符串回忆：
这里就有坑了。12 字符的 hex 字符串，Fable 5 能从图片里正确回忆 13/15，Opus 4.8 是 0/15。也就是说，如果你需要模型从上下文里精确回忆一个 SHA 哈希、一个 ID、一个密钥，图片模式可能出错——而且出错的方式不是报错，而是自信地给你一个看起来很像但不对的答案。
这其实是 pxpipe 最大的风险，下面单独说。
会翻车的地方
有损性：这是最关键的问题。
pxpipe 不是无损压缩。它把文字变成图片后，模型要通过视觉编码器”读”图片里的文字。这个过程中精确字符串会被搞错。哈希值、ID、数字、密钥这些东西，从图片里读回来可能有偏差。
而且错误方式是”静默虚构”——模型不会告诉你”我读不太清”，而是自信地给出一个看似合理但实际错误的答案。开发者自己在日常使用中碰到过一次：模型从图片化的聊天历史里回忆一个人名，给出了一个看起来对但实际不对的名字。
速度：
处理图片比读文字慢。模型要跑视觉编码器来理解图片内容，而不是直接读文本。对大型请求，PNG 编码本身也增加延迟。
语言支持：
ASCII 和 Latin-1 字符充分测试过了。CJK（中日韩）能用但偏保守——渲染效果不如英文那么密集。中文用户用 pxpipe 的压缩率可能达不到英文的 59-70%。
开发者已经做了一些缓解措施：精确标识符（SHA、数字）以文本形式附带；页面几何尺寸限制在 API 的重采样上限内；有可读性审计文档。但本质上，这个方案就是有损的。
什么时候该用，什么时候不该用
适合用的场景：
- Claude Code 长会话，经常撞 1M 上下文上限——pxpipe 不只省钱，还帮你多塞内容
- 大项目重构，需要喂大量文件给模型做参考
- 你的工作流里模型主要看”大意”而不是精确字符（比如理解文档结构、找代码模式）
- 用 Fable 5 作为主力模型（它读图片最准）
不适合用的场景：
- 需要模型精确回忆 ID、哈希、密钥等短字符串
- 跑 Opus 4.8 或 GPT-5.5 做精确操作（误读率太高）
- 中文密集的工作流（压缩率打折）
- 你对每一分钱都不在意（那就没必要折腾）
一个实用建议：把 pxpipe 当成”长对话省钱模式”。开始一个新任务时先用纯文本，确保最近几轮对话精确无误；当对话变长、上下文开始膨胀时，开启 pxpipe 让旧内容压缩。这样你既保证了当前对话质量，又避免了长会话的账单爆炸。
如果你用的是 Claude Sonnet 5，目前它不在 pxpipe 的默认白名单里。Sonnet 5 的图片阅读能力还没经过 pxpipe 的基准测试，建议先观望。
和其他省钱方案的关系
我们之前介绍过两款 token 省钱工具：Codebase Memory MCP 和 Headroom。它们的核心思路是”减少上下文内容”——删除不必要的代码、压缩 prompt、过滤无关文件。pxpipe 的思路是”换一种更便宜的编码方式”——同样的内容，用图片代替文字。
两种思路可以叠加：先用 Memory MCP / Headroom 减少内容总量，再用 pxpipe 把剩下的密集内容压缩成图片。理论上省钱效果能叠加到 80-85%。但这也让问题叠加了——删减内容可能丢信息，图片编码也有损，两层有损叠加，出错的概率更高。
还有个叫 Caveman Prompting 的思路，用”原始人式”极简沟通风格来减少 token 消耗，号称省 65%。这个方案零成本、零技术门槛，和 pxpipe 不冲突。想极致省钱的话：Caveman 减 prompt 长度 → Memory MCP 减无关内容 → pxpipe 压缩剩余内容。三层叠加，账单可能直接砍到原来的 10-20%。代价就是准确性——你需要自己判断省钱的边界在哪。
如果你还在犹豫
pxpipe 是个有意思的实验性工具。它证明了一个定价机制的”漏洞”可以被利用来大幅降低成本，而且数据相当扎实——Fable 5 下 100% 准确率、SWE-bench Lite 完全不受影响。
但”实验性”这个词不是随便说的。它是有损压缩，静默虚构的风险真实存在。开发者自己在 README 里写得很坦诚，基准测试数据也公开透明。这种诚实比很多商业产品强得多。
我的建议是：先在非关键任务上试跑几天。用 Dashboard 观察节省比例和转换效果，跑几次需要精确回忆的小测试（比如让模型从上下文里回忆一个 12 位 hex 字符串），看看实际误读率在你的场景下是多少。数据说服你了，再在正式项目里启用。
毕竟 $42 变 $4 这个数字，确实很难让人不动心。
项目地址：github.com/teamchong/pxpipe（MIT 许可证，TypeScript，当前版本 v0.8.0）
相关阅读：
发表回复