@paul_cal: 他们自己确实尝试了一些东西。没有审计过，但很容易让一个代理指向仓库并扩展...

@menhguin 他们确实自己尝试了一些东西。虽然没有审计，但很容易让一个智能体指向该仓库并扩展一些测试 https://t.co/orRawJLeQx https://t.co/mZq4sKitCk — # teamchong/pxpipe 来源: https://github.com/teamchong/pxpipe # pxpipe 通过将冗长的上下文渲染为图像，削减 Claude Code 的输入消耗——相同的系统提示、工具文档和历史记录，只需消耗一小部分令牌。 一张图像的令牌成本由其像素尺寸决定，而非其中包含的文本量。对于密集内容（代码、JSON、工具输出），在真实的 Claude Code 流量中，每图像令牌可承载约3.1个字符，而文本令牌仅约1个字符。pxpipe 是一个本地代理，利用了这一差距：它在你机器上，将每个请求中冗长的部分重写为紧凑的 PNG 图像，然后才发送出去。按照当前的 Fable 标价，这相当于最终账单降低了 约59%-70% ——但价格会变动，工作负载也各不相同，因此更持久的衡量标准是令牌削减本身，通过 ~/.pxpipe/events.jsonl 中免费的 count_tokens 反事实基准，按每个请求独立测量。 这是模型看到的图像代替文本的示例：一个真实的 transformRequest 输出：系统提示 + 工具文档重新排版为一页密集的 1573×1248 页面，顶部有指令横幅，↵ 标记原始换行符 约48k字符的系统提示 + 工具文档：作为文本约为25k令牌，作为此页面约为2.7k图像令牌。这是真实的管道输出；模型以 100/100 的渲染质量读取此类渲染（参见基准测试）。 ## 演示 Fable 5（默认设置，100/100 读取器）—— 左侧纯文本，右侧 pxpipe： https://github.com/user-attachments/assets/1c8ee63a-fcd7-4958-917b-da788d718349 pxpipe 在 39 个成像的填充文件中，精确计数了 10/10 个令牌（与 grep 逐行匹配），正确完成了多步账本算术，并以 6.06** 结束会话，上下文仍有剩余（73.5k/1M），而左侧为 **42.21，上下文使用率达 96%。视频片段中可见一个注意事项：pxpipe 一侧需要稍微修正才能匹配所要求的一行输出格式。 Opus 4.8（默认禁用）—— 相同布局： https://github.com/user-attachments/assets/f4e50137-31b5-426f-a6ed-b83f829b4a2c 文本关键信息在两侧均可正常读取；但 Opus 无法读取成像的短语计数——而 pxpipe 会直接说明这一点，而非虚构一个数字。这种误读率正是 Opus 需要主动选择加入的原因。 ## 尝试（30 秒） bash npx pxpipe-proxy # 代理运行在 127.0.0.1:47821 ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude # 将 Claude Code 指向它 仪表盘显示：已节省的令牌、每个文本→图像转换的并排对比、终止开关、实时模型芯片。响应正常流式传输——pxpipe 仅压缩请求，从不压缩模型的输出。最近的会话轮次保持文本；系统提示、工具文档和较早的批量历史记录被成像。 ## 坦诚说明 - 它有损。 在密集成像内容中，精确的 12 字符十六进制字符串：Fable 5 上 13/15，Opus 上 0/15——而遗漏是无声的虚构，并非错误。字节精确的值（ID、哈希、密钥）必须保持文本；最近的轮次正是这样做的。专用的逐字风险防护尚未内置。 - 逃生舱： 非白名单模型上的子代理以文本形式通过——可将字节精确的工作路由到那里（CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6，或代理前置数据中的 model: sonnet）。 - 实际任务： SWE-bench Lite 试点 两侧均为 10/10，请求大小减少 −65%；SWE-bench Pro 19 中 14 对 vs 19 中 15 对，请求大小减少 −60%，判定一致性 18/19，唯一的差异在重复测试中 3/3 重新解决——属于运行间方差，而非压缩问题。样本量小；收据见 eval/。 - 依赖工作负载。 在令牌密集内容（约1字符/令牌）上受益，在稀疏散文（约3.5字符/令牌）上亏钱；一个盈利性门控（基于 N=391 条生产数据校准）仅在数学上有利可图时才进行成像。 - 模型范围： 默认 PXPIPE_MODELS=claude-fable-5,gpt-5.6。Opus 4.7/4.8 约 7% 的渲染误读，GPT 5.5 在成像上下文中性能下降，因此两者均需通过 PXPIPE_MODELS 或仪表盘芯片主动选择加入。PXPIPE_MODELS=off 禁用成像。其他所有内容原样通过。在 GPT 路径上，工具定义保持原生 JSON，且不使用 Anthropic 的 cache_control 标记。 ## 基准测试（可复现） 使用模型无法记忆的新颖随机数问题测量： | 测试 | N | 文本 | pxpipe（图像） | 令牌 | |—|—:|—:|—:|—| | 新颖算术，claude-fable-5 | 100 | 100% | 100% | −38% | | 新颖算术，claude-opus-4-8 | 100 | 100% | 93% | −38% | | 要点回忆 A/B（决策、值、路径、名称、否定；带干扰项；15k-45k 字符会话），Fable 5 | 98/arm | 98/98 | 98/98 | - | | 状态跟踪（值变化 3 次，最终/首次/计数），Fable 5 | 18/arm | 18/18 | 18/18 | - | | 从未陈述事实的虚构（越低越好），Fable 5 | 16/arm | 0/16 | 0/16 | - | | 逐字 12 字符十六进制回忆，密集渲染，Opus | 15 | 15/15 | 0/15 | - | | 逐字 12 字符十六进制回忆，密集渲染，Fable 5 | 15 | - | 13/15 | - | SWE-bench 运行总计、收据和注意事项：eval/swe-bench/ · eval/swe-bench-pro/ · eval/needle-haystack/ · eval/gist-recall/ · 分析见 FINDINGS.md。（GSM8K 在成像下得分为 96%，但由于在训练数据中——记忆的答案可承受误读——因此我们以新颖数字评估为主。） ## 工作原理 tool_result 字符串 ──► 在 1928px 宽的列上换行 ──► 每页打包约 92,000 字符 ──► PNG[] 代理拦截 /v1/messages，将符合条件的批量内容重写为图像块，再以缓存友好的方式拼接回去（静态前缀保留，提示缓存继续工作），并转发。一张 1928×1928 的图像约消耗 4,761 个视觉令牌，容纳约 92,000 个字符，因此文本仅在超过约 19 字符/令牌时才有优势——Claude Code 流量约为 1.91（N=391）。每个请求的估算器决定；稀疏散文保持文本。事件记录到 ~/.pxpipe/events.jsonl。 ## 库使用（无需代理） ts import { renderTextToImages, transformAnthropicMessages } from "pxpipe-proxy"; const { pages } = await renderTextToImages(toolResultText); // pages[i].png: Uint8Array const { body, applied, info } = await transformAnthropicMessages({ body: requestBytes, model: "claude-fable-5", }); options.keepSharp(block) 将块固定为文本；options.emitRecoverable 返回成像块的原始内容。纯 JS 运行时（Node 和 edge/Workers）；@napi-rs/canvas 仅在构建时使用。完整 API：src/core/index.ts。 ## 开发 bash pnpm install && pnpm test pnpm run build # 重新生成 dist/ ## 常见问题 标题中的节省是端到端的，还是仅针对你接触的请求？ 端到端，整个账单。大多数压缩工具只报告其所处理输入部分的节省，这会美化数字。端到端的分母是每个生产请求：pxpipe 正确保持不变的少量请求、所有缓存写入和读取，以及所有输出令牌（代理从不压缩这些）。在一个 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. 大的 tool_result 主体（文件读取、命令输出、日志）超过约 6k 字符的令牌密集内容 2. 较早的折叠历史：尾部的会话轮次被重新渲染为图像页面，最近的轮次始终保留文本 3. 静态系统提示 + 工具文档块 其他所有内容原样通过：你的消息、最近的轮次、模型的输出（它是响应，代理从不接触）、稀疏散文以及任何太小而不划算的内容。白名单之外的模型完全通过——默认范围仅限 Fable 5 和 GPT 5.6。Opus 4.8 和 GPT 5.5 读取成像内容的能力明显较差（FINDINGS.md 2026-06-16），因此它们需要通过仪表盘或 PXPIPE_MODELS 故意选择加入，绝不会被静默成像。 它在真实场景中，基准测试之外，有没有失败过？ 有，在数周的日常使用中发生过一次：模型从成像的聊天历史中回忆出一个人的名字，并且自信地给出了错误的名字。没有错误，只是一个合理的错误名称。这就是文档记载的失败模式：成像内容中的精确字符串不是字节安全的。编码会话可以容忍这一点，因为智能体在编辑前会重新读取文件；纯聊天回忆没有这样的检查。这种失败模式是被测量的，而非轶事性：可读性审计 量化了从渲染页面中回忆精确字符串的情况（盲读密集标识符时最高仅 63%，每次遗漏都由字形混淆矩阵预测），并记录已发布的缓解措施——页面几何被限制在 API 的重采样上限内，使实际计费像素实际到达视觉编码器，以及精确标识符（SHA、数字）作为文本一同传输。 为什么这个 README 读起来像是 AI 写的？ 因为确实是。这个仓库的大部分提交——代码和文档——是由运行在 pxpipe 自身之上的 Opus/Fable 智能体会话创作的，它们在工作时读取自己折叠的历史记录（作为图像页面）。 ## 限制 - 有损（如上所述）；从图像中逐字回忆不可靠。 - PNG 编码会在大型请求离开前增加延迟。 - ASCII/Latin-1 经过充分测试；CJK 可工作但较为保守。 ## 路线图 以下为假设，并非宣称——它们会附带数字和样本量发布，否则就会被剔除：更清晰的字形渲染（eval/glyph-matrix/，已暂停运行）、成像的批量内容是否延伸有效上下文（在相同的 1M 窗口中容纳约 2 倍的真实内容）、以及较小的活动上下文是否提高长任务准确性。 ## 许可证 MIT.