把文本画成图反而更便宜：pxpipe 钻计费空子给 Claude 省七成账单
哈喽，我是飞飞。
这两天 GitHub 冒出来一个项目叫 pxpipe，干的事有点反常识：它把 Claude Code 的系统提示、工具文档、聊天历史这些文本，渲染成 PNG 图片再发给模型。文本本来是给模型读的，现在改成让模型”看图”，听起来多此一举。但作者 Steven Chong 给了组数字：48k 字符的系统提示，文本模式约 25000 token，图片模式约 2700 token。Fable 5 的端到端账单省了 59 到 70 个百分点。
说实话，这个数字对天天在 Claude Code 里烧 token 的人是有冲击力的。你跑一个稍微复杂点的 agent 任务，系统提示加工具定义就占掉上下文一大块，每轮对话都要为这些”背景板”付满 token，眼看着额度往下掉。突然有人告诉你这部分能压成一张图，省掉九成，第一反应都是”真的假的”。
把文字画成图反而更便宜，这事能成立，是因为 Anthropic 的计费表上留了一个密度差。
漏洞不在代码里在计费表里
Anthropic 官方文档写得很清楚：图片 token 等于图片宽除以 28 向上取整，乘以高除以 28 向上取整。一句话，图片的 token 成本由像素尺寸固定，跟图片里塞了多少文字没关系。
一张 1928 乘 1928 的图，约 4761 个 vision token。这么大的画布，塞进约 92000 个字符的密集内容轻轻松松。同样的字符走文本模式，按真实 Claude Code 流量算大约 1 个字符 1 个 token，就是 92000 token。5 倍多的密度差，就藏在这条计费规则里。
pxpipe 做的就是把这个密度差兑现。它是个本地代理，拦住 Claude Code 发往 /v1/messages 的请求，把符合条件的批量文本重写成图片块再转发。最近几轮的对话保持文本，模型输出从不压缩，被压的是系统提示、工具文档、较早的历史这些”模型要读但不逐字操作”的部分。
说白了，它钻的是计费规则的空子，不是什么技术突破。
这招最省的是 Claude Code 长会话
Claude Code 的特点正好踩在 pxpipe 的甜区上。一次会话里，系统提示加工具定义能占一大坨上下文，这些内容模型每轮都要读，但很少逐字操作。长会话越往后，历史堆积越多，这部分”读但不逐字动”的占比越高，pxpipe 省得越多。
作者给的最猛的例子是个 Fable 5 demo：纯文本跑下来 42.21 美元，上下文用到 96 个百分点满；pxpipe 跑同样任务 6.06 美元，上下文还剩 73.5k。SWE-bench Lite 上 10 个实例全过，成本从 54 美元降到 27 美元。SWE-bench Pro 上 19 对测试 18 对判定一致，唯一分歧复测 3 次全过，属于运行间方差。
我自己用 Claude Code 的体感能印证这个方向。每个月给 Anthropic 的钱不算少，让 agent 干一件正经活之前，我都会下意识掂量一下值不值得动用 Opus，杂活就手动切便宜模型省点额度。这种”用之前先在心里过一遍秤”的绷着感，就是贵最真实的体感。最具体的场景是写文章这条流水线，光配图、查重、发公众号这些周边 skill 就挂了十几个，每次跑一遍，系统提示加工具定义那一坨上下文反复占位，token 烧得肉眼可见。pxpipe 等于在过秤之外多给了一条路：不换模型，换输入形态。
这条路的代价我得诚实讲。我那十几个 skill 全是照着 Claude Code 认 frontmatter、调 hook 的脾气一点点磨出来的，真要把模型底座换到别家，光是把工具调用的格式校回来就得搭进去好几个晚上。省模型钱的那本账上从来不记这些时间成本。pxpipe 这种本地代理的搞法好在它不动 skill 这层，只在请求出口加一道，迁移成本几乎为零，这对我这种 skill 重度用户是实打实的友好。
但要清醒，它不是什么都省。稀疏散文大约 3.5 字符换 1 个 token，低于图片化的盈利门槛，硬压反而亏钱。pxpipe 自己有判断逻辑，只在数学划算时才图片化，这个克制很重要。
省钱的代价是会静默虚构
这是最该讲清楚的一层，也是决定你敢不敢用它的关键。
从图片里逐字回忆本来就不靠谱。作者测了 12 字符的 hex 字符串，Fable 5 对了 13 个错了 2 个，Opus 直接 15 个全错。更危险的是误读不报错，模型会给一个看似合理但实际错误的答案。
这是 OCR 的结构性上限，调参救不回来。作者自己日常用就出过一次：从图片化的聊天历史里回忆一个人名，自信地答错，没有任何报错信号。这类 bug 最难查，因为模型不会说”我没看清”，它只会给一个语气笃定的错答案，你不核对就跟着错下去。在 agent 链路里这种错误还会向下游传染，一环错一环。
pxpipe 的应对是把字节精确值，ID、哈希、密钥这些强制保持文本，跟图片一起发。最近几轮对话也始终保持文本，保证模型当下要操作的内容是精确的。
代价还有速度。模型要走视觉编码器处理图片，比直接读文本慢。PNG 编码大型请求本身也要时间。所以 pxpipe 不是免费的午餐，是用准确性和延迟换 token。对”上下文重、推理轻”的活划算，对要逐字精确的活得绕开。
想想你自己的使用场景就能判断该不该碰它。如果你跑的是长会话调试、大仓库代码理解、多轮 agent 任务这类上下文堆积型的活，系统提示和工具文档占大头，模型主要做推理而不是逐字抄写，pxpipe 大概率能帮你省钱还不掉链子。如果你经常要让模型精确读哈希、对 ID、逐字引用配置值，那就得绕开，或者把那些精确值强制走文本通道。
这招能活多久是个真问题
The Decoder 那篇报道里有句判断很到位：如果这招流行开来，AI 公司可能提高图像处理价格。
这话不是吓唬人。Anthropic 只要改计费规则，比如对”文字密集图片”加价，或者图片 token 也按内容密度算，pxpipe 就失效。但短期内大概率不会改，因为图片按像素计费是视觉模型的通用规则，改了影响所有正常视觉用途，代价太大。
我自己判断这事会走一条折中路。官方更可能的做法是悄悄提升视觉编码器对文字密集图片的识别能力，让模型从图片里读文字的准确率往文本模式靠拢，顺便在计费层做更细的分档。这样既不动通用规则，又能让这类 hack 的收益自然缩水。真要一刀切改计费，伤的是所有正经视觉用途，Anthropic 犯不上。所以窗口期大概率有一段，但不会永远开着。
更有意思的，说实话，是这个形态本身。pxpipe 是个本地代理，不改 Claude Code，不改模型，一行 npx 命令就跑起来。这种”计费优化层”可能衍生出一类工具，在客户端和模型之间加一层，专门做 token 成本优化。跟缓存、路由、模型委托是同一类工程方向，只不过它压得更激进，直接换输入形态。
我会继续盯两件事。一是 Anthropic 会不会动计费规则堵这个口子，这决定了 pxpipe 这类工具的窗口期有多长。二是社区会不会把它跟模型委托、缓存叠加出更省的组合拳，毕竟压输入形态和换便宜模型是两条独立的省钱路，叠起来可能更猛。
你更在意哪种省 token 的路子，是换更便宜的模型，还是换更便宜的输入形态？
参考资料
- [[pxpipe-github-readme]]
- [[claude-vision-docs]]
- [[pxpipe-decoder-article]]
相关洞察
- [[pxpipe-token-hack]]