通过将庞大的上下文渲染为图像来削减 Claude Code 的输入 token——相同的系统提示词、工具文档和历史记录，仅需一小部分 token。

图像的 token 成本由其像素尺寸决定，而非内部包含的文本量。在真实的 Claude Code 流量中，密集内容（代码、JSON、工具输出）每个图像 token 可容纳约 3.1 个字符，而每个文本 token 仅约 1 个字符。pxpipe 是一个利用这一差距的本地代理：它在请求离开你的机器之前，将请求中庞大的部分（系统提示词、工具文档、较早的历史记录）重写为紧凑的 PNG 图像。

节省效果取决于工作负载——pxpipe 在 token 密集的内容上表现优异，而稀疏/小型请求则保持不变——因此这些是实测快照，而非恒定值。主要且持久的结果是输入 token 的减少：密集的系统提示词、工具文档和历史记录以紧凑图像而非文本形式输入（上述示例中约 25k 文本 token 被渲染为约 2.7k 图像 token），每个请求都根据其自身的 count_tokens 反事实进行测量。费用是下游结果——按当前 Fable 标价计算，token 削减可带来约 59–70% 的端到端账单降低（压缩请求上约 72–74%；完整定价计算见 FAQ）。但标价明天可能变化，而 token 数量不会，因此应关注 token 而非金额。两者均可从 ~/.pxpipe/events.jsonl 复现。

这是模型看到的替代文本的内容：

约 48k 字符的系统提示词 + 工具文档（本仓库自身的 README、FINDINGS 和源代码），作为文本约 25k token，作为此页面约 2.7k 图像 token。由真实的 transformRequest 管道生成：空白字符最小化，重新排列为完整行，用 ↵ 标记原始换行，OCR 指令横幅共同渲染在顶部。模型在干净评估中以 100/100 读取此类渲染（见基准测试）。

演示

Fable 5 演示（默认，100/100 读取器）：

Fable-AB-Demo.mp4

• 两个演示均在 Fable 5 上显示双面板（左侧为纯文本，右侧为 pxpipe）。

• Fable 能读取 Opus 无法读取的内容。Opus 拒绝处理的图像化短语计数（见下方 Opus 演示）：pxpipe 分支在 39 个图像化填充文件中精确计数了 10/10 的 token（与 grep 真实结果逐行匹配），并正确完成了多步账本算术（8037 → … → 15,021）。
• 相同答案，成本降低约 7 倍。两次演示后的会话总计：普通版 $42.21，上下文占用 96%（964.5k/1M —— 再差一步就要强制压缩）；而 pxpipe 版仅 $6.06，上下文还有富余（73.5k/1M）。
• 坦诚说明（视频中可见）：pxpipe 分支先回答了计数问题，但需要一次后续提示才能按要求的一行格式打印账目余额；普通版则一次就遵循了格式。可读性问题已在 Fable 上解决 —— 单次回复的格式遵循是尚存的粗糙边缘。

Opus 4.8 演示（Opus 默认禁用）：

Opus-AB-Demo.mp4

并排对比 —— 普通版 Claude（左）vs pxpipe（右），均使用 Opus 4.8（需手动启用；pxpipe 针对 Fable 进行了调优 —— 见上方 Fable 片段）。点击图片观看（Google Drive）。

• 演示 1 —— 修复一个失败的测试套件：两者均通过；仪表盘显示 pxpipe 将请求削减至极少的 token 量（真实、服务器端测量的上下文/token 缩减）。
• 演示 2 —— 一个大文件上下文（40 个文件，约 382k tokens）加上一个数学问题和一个“统计此短语”任务：两者都能读出数学答案（一个小型文本针）。短语统计需要读取图片填充内容 —— 因此 Opus 上的 pxpipe 无法读取，并诚实地表明不会编造数字（已记录的有损限制：精确数值保留为文本）。而普通版则逐个文件地统计，陷入卡顿。

立即尝试（30 秒）

npx pxpipe-proxy                                  # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://localhost:47821 claude  # point Claude Code at it

打开 http://127.0.0.1:47821/ 查看实时仪表盘：节省的 token 数、每次会话统计、所有文本→图像转换的并排对比、全局终止开关，以及运行时模型芯片（包括 GPT 5.6 和 GPT 5.5）。

其他一切不变。响应正常流式输出；pxpipe 仅压缩请求（即你发送的上下文），绝不压缩模型的输出。最近的对话轮次保持为文本；系统提示词、工具文档以及较早的批量历史记录则被转换为图像。

这是坦诚的部分，在依赖它之前请先阅读。

它是有损的。pxpipe 属于 Gist 级别，并非无损存储。在一项“大海捞针”评估中，密集图像内容中的精确 12 字符十六进制字符串，Opus 返回结果为 0/15，而 Fable 5 为 13/15，其失败模式是静默虚构：给出一个看似合理但错误的值，而非报错。任何你需要逐字节精确返回的内容（ID、哈希值、密钥、精确数字）都必须保留为文本。最近的版本已如此处理；但专用的逐字风险防护机制尚未构建。

精确召回的安全出口。pxpipe 仅对 Fable 请求进行图像化处理（`PXPIPE_MODELS=claude-fable-5`），因此任何使用非 Fable 模型的子智能体都会以文本形式通过。将需要逐字节精确值的工作路由到该模型——全局设置可使用 `CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6`，或在智能体前置元数据中按智能体设置 `model: sonnet`。它从源文件（文件/JSONL）读取，而非图像化历史记录。这覆盖了你特意路由的精确召回场景；但无法捕获你未预料到的静默误读——这正是上述尚未构建的防护机制。

它会破坏实际工作吗？在我们衡量的指标上表现相当：一个包含 10 个实例的 SWE-bench Lite 试点（简单子集），两组均解决了 10/10，pxpipe 开启时 token 等效成本为 27 美元，关闭时为 54 美元；19 对 SWE-bench Pro 任务（更困难、长周期），pxpipe 开启时解决了 14/19，关闭时解决了 15/19，每次请求成本降低 60%：两组在 18/19 的任务上判定一致，唯一的分歧（一次开启失败）在复现时以 3/3 重新解决，即属于运行间的智能体方差，而非压缩问题。样本量较小，详情和注意事项见下文。

节省成本的效果取决于工作负载。它在 token 密集内容（约 1 字符/token：代码、JSON、哈希值）上效果显著，而在稀疏的英文散文（约 3.5 字符/token）上则会亏损。内置门控机制仅对数学计算上划算的内容进行图像化处理，并根据 N=391 条生产数据行进行了校准。

模型范围：一个 PXPIPE_MODELS CSV 文件控制着哪些模型基础会在两个系列中被成像——默认值为 claude-fable-5,gpt-5.6（GPT 5.5 是可选加入的；它在成像上下文上表现退化）。将 PXPIPE_MODELS 设为 off 可完全禁用成像功能，或者使用 ~/.config/pxpipe/config.json 并设置 { "models": "off" }（或一个列表）。对于 GPT，pxpipe 将工具定义保留为原生 JSON（只有冗长的 schema 描述文本会进入图像），因此工具调用保持可靠；与 Claude 路径不同，GPT 路径不会添加或依赖 Anthropic 的 cache_control 提示词缓存标记。仪表盘芯片可以在不更改客户端配置的情况下实时切换任何模型。Opus 4.7/4.8 原本是 Claude 的范围，但误读了约 7% 的渲染结果（10200→9400），因此在 Fable 5 以相同的图像计费达到 100/100 后，默认将其关闭——你可以通过 PXPIPE_MODELS 或仪表盘芯片自行承担风险将其重新启用。其他所有内容均原样通过。

基准测试（可复现）

使用模型不可能记忆过的新型随机数问题进行测量：

测试	N	文本	pxpipe（图像）	tokens
新型算术，claude-fable-5	100	100%	100%	−38%
新型算术，claude-opus-4-8	100	100%	93%	−38%
要点回忆 A/B（决策、数值、路径、名称、否定；含干扰项；15k-45k 字符会话），Fable 5	98/组	98/98	98/98	-
状态追踪（数值被修改 3 次，最终值/首次值/计数），Fable 5	18/组	18/18	18/18	-
对从未陈述过的事实的虚构（越低越好），Fable 5	16/组	0/16	0/16	-
逐字 12 字符十六进制回忆，密集渲染，Opus	15	15/15	0/15	-
逐字 12 字符十六进制回忆，密集渲染，Fable 5	15	-	13/15	-

SWE-bench Lite 试点（端到端任务质量）

10 个 SWE-bench Lite 实例，Claude Code + Fable 5，通过 pxpipe 开启与关闭进行配对运行，使用官方 swebench Docker 测试框架评分：

	pxpipe 开启	关闭
已解决	10/10	10/10
请求大小 vs 自身未压缩主体	−65%	±0

−65% 是每个请求的（在压缩前对每个主体进行 count_tokens 探测），因此没有轮次计数的混淆。n=10/组，Lite 偏向简单。运行总计、收据、注意事项：eval/swe-bench/。

SWE-bench Pro 基准测试（更困难，长周期）

两次运行中完成了 19 个配对（2 个被丢弃：两个分支的检出均失败），相同设置，官方 SWE-bench_Pro-os Docker 测试框架：

	pxpipe 开启	关闭
已解决	14/19	15/19
请求大小 vs 自身未压缩的请求体	−60%	±0

在 18/19 个实例上，裁决结果一致（其中三个实例的两条测试臂均失败，有一条臂的补丁字节完全相同）。唯一出现分歧的实例（navidrome，ON 臂失败）在 ON 臂上重复了 3 次：三次运行均生成了相同的补丁并成功解决，因此最初的失败是运行间智能体方差所致，而非压缩问题。凭证：eval/swe-bench-pro/。

我们还运行了 GSM8K：得分 96%。但 GSM8K 存在于训练数据中，因此模型会通过自身的误读来回忆记忆中的答案，从而虚增分数，所以我们改用干净的新数字评测作为主要依据。复现：eval/gsm8k/ · eval/needle-haystack/ · eval/gist-recall/ · 完整分析见 FINDINGS.md。

常见问题

标题中的数字是端到端的，还是仅针对你处理过的请求？是端到端的，涵盖全部费用。大多数压缩工具只报告它们处理过的输入部分的节省，这会美化数字。端到端的分母是所有生产请求：pxpipe 正确保留未处理的小请求、所有缓存写入和读取，以及所有输出 token（代理从不压缩输出）。在一个包含 13,709 个请求的快照中，节省为 59%（$100 → ~$41）；后续一个包含 8,904 个已压缩请求的跟踪记录测得约 70%。仅压缩请求的运行结果更高（约 72–74%），会单独列出，从不作为标题数字。具体数字取决于工作负载——请在你的日志上自行复现。

费用是如何计算的？同一请求的两侧，在同一时刻计算。对于每个 /v1/messages POST 请求，代理会针对原始未压缩的请求体（反事实情况）并行发起一个免费的 count_tokens 探测，同时进行真实转发，并从响应中读取 Anthropic 实际计费的用量数据块。两者都记录在 ~/.pxpipe/events.jsonl 的同一行中，因此不存在轮次或运行间的混淆。美元换算使用 Fable 5 列表费率：输入 ×1.0，缓存写入 ×1.25，缓存读取 ×0.1，输出 ×5。缓存定价对两侧相同应用，因此缓存折扣相互抵消，不会重复计入"节省"。你可以从事件日志中自行推导：公式和字段名在 src/core/baseline.ts 中有文档说明。

它实际上压缩了什么？三种输入块，每种都经过一个盈利性门槛：

1. 大型工具结果体（文件读取、命令输出、日志）中超过约 6k 字符的高密度 token 内容
2. 较早折叠的历史记录：位于实时尾部之前的轮次会被重新渲染为图像页面，而近期轮次始终保持文本形式
3. 静态系统提示词 + 工具文档块

其余所有内容均以字节一致的方式通过：你的消息、近期轮次、模型的输出（它本身就是响应，代理从不触碰它）、稀疏的散文式文本，以及任何太小而无需处理的内容。非 Fable 模型则完全透传。

在基准测试之外，它是否真的失败过？是的，在数周的日常使用中出现过一次：模型从图像化的聊天历史中回忆了一个人的名字，并且自信地给出了错误答案。没有报错，只是一个看似合理的错误名字。这就是已记录在案的失败模式：图像化内容中的精确字符串不具备字节安全性。编码会话可以容忍这一点，因为代理在编辑前会重新读取文件；纯聊天回忆则没有这样的检查机制。

工作原理

tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]

代理拦截 /v1/messages 请求，将符合条件的批量历史记录重写为图像块，以缓存友好的方式将它们拼接回去（保留静态前缀，使提示词缓存继续正常工作），然后转发。每次请求的事件会记录到 ~/.pxpipe/events.jsonl 文件中。

经济性分析：一张 1928×1928 的图像成本约为 4,761 个视觉 token，最多可容纳约 92,000 个字符（按观测密度计算约为 48,000 个文本 token），因此纯文本只有在密度超过约 19 字符/token 时才更便宜。Claude Code 的转录文本远低于这个密度（观测值为 1.91 字符/token，N=391）。运行时估算器（estimateImageCount）加上字符/token 门控机制会按请求进行决策；稀疏的散文式文本则保留为文本形式。

库使用（无代理模式）

相同的引擎，无需代理。将文本渲染为 PNG 图像，或运行完整的缓存安全转换：

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

const imgs = await renderTextToPngs(toolResultText);            // RenderedImage[]
const { body, applied, info } = await transformAnthropicMessages({
  body: requestBytes,
  model: "claude-fable-5",
});

options.keepSharp(block) 可将指定块固定为文本形式（覆盖针对 ID、哈希值、路径的启发式规则）；options.emitRecoverable 返回已图像化块的原始内容，以便有状态调用方能够恢复它们——这是针对下面有损限制的保真度契约的两个组成部分。运行时为纯 JavaScript（支持 Node 和边缘/Workers 环境）；@napi-rs/canvas 仅在构建时使用。完整 API、类型和常量请参见 src/core/index.ts。

开发

pnpm install && pnpm test     # 376 tests
pnpm run build                # regenerates dist/

局限性

• 有损性：请参见上文"诚实的一面"。从图像中逐字回忆是不可靠的。
• 渲染延迟：在大型请求离开前，编码 PNG 会额外增加时间（这部分被模型摄入更少 token 所部分抵消）。响应正常流式输出。
• ASCII/Latin-1 字符集经过充分测试；CJK（中日韩）字符可用，但采用保守策略。
• 运行时为纯 JavaScript——可在 Node 和边缘/Workers 环境运行。@napi-rs/canvas 仅作为构建时的开发依赖（用于重新生成字形图集），而非运行时依赖。
• 仅支持 Fable 5。

路线图

以上所有内容均经过实测。以下内容均未经实测。这些是假设，而非声明；它们要么以带 n 前缀的数字形式发布，要么被砍掉。

• 更清晰的字形。13/15 的逐字差距部分源于字体可读性，而非仅模型原因。跨渲染风格的逐字符混淆矩阵测试已暂停（eval/glyph-matrix/）；若零成本样式能降低读取错误率，则门控机制可在相同保真度下实现更强压缩。
• 有效上下文。密集文本的 token 消耗约为图像的 1/3。若该结论在实时窗口中成立（而非仅计费层面），则 1M token 可承载约 2 倍的实际内容。待解问题：当大部分内容被图像化后，原本需要约 2M 原始上下文的任务能否在 Fable 的 1M 上下文窗口内运行？
• 更少的活跃文本，更敏锐的模型。长上下文随着内容填充会降低推理能力。将旧内容图像化可缩小模型实际读取的范围，同时保持其可访问性。假设：相同信息量，更小的活跃上下文，更优的长任务准确率。

一个赌注：基于同一套 Fable 5，实现更长的有效上下文和更敏锐的长任务模型。要么拿出数据，要么撤回，中间不掺杂任何炒作。

许可证

关于

通过将文本上下文渲染为图像来降低 Fable 5 的 token 用量