用途：Honey PX 用于把庞大、密集、只读的文本以渲染后的 PNG 页面形式读取，而非原始文本。图像 token 成本由像素面积决定，与字符数无关；密集文本约每图像 token 承载 3 个字符，而纯文本约 1 个，因此 9 万字符文件按 PNG 页面读取的成本远低于文本读取。渲染由 pxpipe export（teamchong/pxpipe）完成，智能体读取页面。
主要能力：支持导出文件或目录，也支持 --git、--diff <ref>、--stdin。输出目录 pxpipe-export-<hash>/ 包含 page-*.png、factsheet.txt、manifest.json（token 报告）。factsheet.txt 以文本形式携带路径、SHA、id、数字等需逐字精确的 token，必须一并读取。
使用方式：npx pxpipe-proxy export --json --out <scratchpad> <file-or-dir>。随后读取每个 page-*.png 和 factsheet.txt。若把渲染结果通过原始 API 传给模型（子智能体提示、面板），需包含导出的 prompt.txt 横幅，否则密集渲染可能触发 Fable 类模型的 stop_reason: refusal。以 manifest 的 percentSaved 作为是否采用的判断，若数值低则改读文本。
适用场景：只读参考的大批量内容，如浏览大型 vendored 文件、用于审查上下文的大型 diff、文档、生成代码等需要推理而非逐字节复制的内容。密集（代码、JSON、日志）且体量大时值得使用，约 6k 字符以上；稀疏散文不划算。读取方为 Fable 级模型；Opus 约误读 7% 的渲染，其他模型更差，应改读文本。
限制：设计上是有损的，对精确字符串的误读是静默虚构而非报错。不要用于将要编辑的文件（old_string 必须逐字节精确），编辑前须用 offset/limit 读取真实文件。不要用于机密、哈希、id、将据以行动的数字，任何仅从图像回忆的精确内容都视为未验证，先用 Grep 核对源文件。不要用于用户要求逐字查看或会被写回的内容，也不要用于小或稀疏内容。更省的做法是不读取，优先使用 Grep/offset/limit 与 eson crush（CCR）。