把 Claude Code 輸入轉成圖像：開源工具 pxpipe 實測省下 60% API 帳單

編按：本文綜合整理自 teamchong/pxpipe GitHub 倉庫、Hacker News 討論串（291 分）、DeepSeek-OCR 論文 arXiv:2510.18234，並加入 Siami 編輯部觀點與分析。

開源工具 pxpipe 兩天內衝上 Hacker News 291 分、72 則留言，宣稱能讓 Claude Code 使用者的 API 帳單直接砍 59–70%。方法聽起來很反直覺：把本來用文字送的 context 轉成 PNG 圖片，再讓模型「看圖」回來讀。作者 teamchong 把整個代理掛在 Claude Code 與 Anthropic API 之間，攔截請求、把體積最大的系統提示、工具說明、過期的對話歷史全部轉成圖塊，再丟給視覺編碼器。

為什麼圖片比文字便宜

一般人直覺會覺得「圖片比文字貴」，但 pxpipe 給的數字完全相反：在一張 1928×1928 像素的 PNG 裡，Anthropic 的視覺編碼器只算約 4,761 個 vision token，卻塞得下 92,000 個字元。換算下來是 每個 vision token 撐 19 個字元，而真實 Claude Code 流量每個文字 token 只能撐約 1.91 個字元（作者量測 N=391 個 production request）。

換句話說，模型硬體上 vision token 的 KV cache 比 text token 輕很多。文字 token 因為要承載豐富語意，每個 byte 在記憶體裡可能要吃 megabytes；vision token 是 lossy 表示，每個 byte 大概只要 kilobyte。文字贏的臨界點是 ~19 chars/token，低於這個密度把文字丟去當圖反而更省——Claude Code 預設 context 就是 ~1.91 chars/token 這種「內容密度高、字少訊息多」的工作負擔。

實測下來，一段約 48k 字元的系統提示 + 工具說明，純文字要 25,000 tokens，轉成圖只要 2,700 tokens。這是 9 倍壓縮。但成本不是 9 倍：因為 vision token 計價係數比 text token 低，最終帳單落在 59–70% 下降。

安裝方式：30 秒掛上本地代理

pxpipe 是純本地 proxy，夾在 Claude Code 跟 Anthropic API 中間：

npx pxpipe-proxy        # 啟動 127.0.0.1:47821

ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude   # 把 Claude Code 指過去

啟動後打開 http://127.0.0.1:47821/ 可以看 dashboard：每筆請求省了多少 token、text→image 的對照、kill switch、即時 model 切換。回應保持正常串流——pxpipe 只壓縮 request，不壓縮 model 的 output。最近幾輪對話保持文字，老的對話歷史、靜態 system prompt、工具說明才轉圖。

預設啟用的模型清單是 claude-fable-5, gpt-5.6。Opus 4.7/4.8 因為讀圖 misread 率約 7%，GPT 5.5 在圖 context 上表現退化，兩者都是 opt-in，要手動加 PXPIPE_MODELS 環境變數或從 dashboard 開。

測試結果：novel-number 評估 100 分，公開榜單幾乎不打折

作者很誠實地區分「公開榜單」跟「novel 評估」——因為 GSM8K 這種標準 benchmark 已經在訓練資料裡，分數漂亮不能說明 vision 壓縮的正確性。所以他自製了「模型一定沒背過的隨機數字題」來測：

測試	N	text 答對率	pxpipe 答對率	token 變化
novel arithmetic, claude-fable-5	100	100%	100%	−38%
novel arithmetic, claude-opus-4-8	100	100%	93%	−38%
gist recall（多輪記憶）	98/arm	98/98	98/98	—
state tracking（值改三次）	18/arm	18/18	18/18	—
confabulation（沒講過的事瞎掰）	16/arm	0/16	0/16	—

比較硬的測試是 SWE-bench Pro：text arm 15/19，pxpipe arm 14/19，分歧的那一題重跑 3 次都是同一邊贏（run-to-run variance，不是壓縮問題）。SWE-bench Lite 兩邊都 10/10，token 降 65%。n 還太小，receipts 放在 eval/swe-bench-pro/。

重要警告：lossy。作者坦白說「12 字元 hex string」這種要逐字對的東西，imaged 後只剩 13/15 對（Fable 5），Opus 是 0/15，而且錯的時候 model 會自信地掰一個答案給你，不會丟錯。SHAs、hash、secrets 必須留在文字；需要 byte-exact 工作的話用 CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6 把 subagent 路由到非 allowlist 模型，會原樣 pass-through。

🚨 為什麼這件事重要

這不是「單純一個 proxy 工具」，而是 Anthropic vision encoder 計價模型的試金石。Claude Code 一個月重度使用者帳單可以到 $300-$1,200，光一個本地 proxy 不用改任何 model 行為、不用換 model、純靠把 text 轉 vision 就能砍 60%，等於直接挑戰 Anthropic 對「一個 token 值多少錢」的定價假設。

更值得注意的是 DeepSeek 10 月公開的 DeepSeek-OCR: Contexts Optical Compression 論文（arXiv:2510.18234）已經系統性地證明：vision encoder 可以把 10 倍以上的文字量壓進極少 vision token，20× 壓縮還能保留 60% 精度。也就是說，「文字 vs 圖」不是哪個比較便宜的問題，是要看 vision encoder 怎麼設計。Anthropic 的 vision encoder 設計顯然讓 vision token 計價係數偏低——這是設計決策，不是 bug。

對企業 IT 跟 FinOps 團隊的含意更直接：「用哪個模型」不再是唯一的成本槓桿，「怎麼把 context 餵給模型」是另一條獨立變數。把 pxpipe 這種工具當作「短期省錢外掛」會誤判形勢——它的真正訊號是 vision encoder 的成本結構正在快速改變，未來一年的 LLM 計價模型很可能會重新設計。

🚨 數據解讀與質疑

幾個不能跳過的質疑：

「end-to-end 59–70%」是 anomaly case，不是平均。作者在 FAQ 裡坦白：13,709 個 production request 量下來是 59%（$100 → $41），但後來 8,904 個 request 跑到 70%。只壓縮的子集（compressed-only）可以到 72-74%，但那不是 end-to-end。如果你只關心 10% 的高密度 text，那個數字漂亮；關心平均帳單，就是 60% 出頭。
Anthropic 可能隨時改計價模型。hn_throwaway_99 的 89 分留言直接點出：Gemini 處理 PDF 是「OCR + text+image 同送」但不收 text token 費用，Claude 八成也是同一條計價邏輯。這不是成本優勢，是 token 計算的疏漏。一旦 Anthropic 修補（比方說把 vision token 計價係數拉到跟 1.5× 或 2× text token 看齊），pxpipe 的省錢效果會直接蒸發。
「59%」是 30 天前的工作負載，未來不一定重現。作者在 FAQ 明確說「the exact figure is workload-dependent — reproduce it on your own log」。如果你跑的全是稀疏自然語言對話（每句話很多字但少結構化資料），可能完全省不下來——profitability gate 在 ~3.5 chars/token 之上就會放棄影像化。
Opus 4.7/4.8 為什麼被排除？作者說 misread 率 7%，但 Fable 5 的 hex string 也只有 13/15。如果哪天 Anthropic 推的 default model 換到 misread 率更高的版本，這條路就不通了。整個 pxpipe 假設 Fable 5 永遠是「讀圖最好的 frontier model」——這個假設比你想的脆弱。
lossy 是結構性問題，不是工程問題。verbatim string 從圖裡撈回來不可靠是視覺 token 化的根本限制，不會因為換模型就消失。SHAs、API key、secrets、UUID——這些 12-char hex 識別符本來就是 token 經濟裡的「大宗成本」，但偏偏是最不能省的。pxpipe 把這塊放在 escape hatch（subagent route），但代表整體節省率還有上限。

實際用法與限制

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

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

可以不用 proxy 直接用 library：options.keepSharp(block) 強制某個 block 留文字；options.emitRecoverable 拿回原始文字 fallback。整個 runtime 是純 JS，Node 跟 edge/Workers 都能跑，@napi-rs/canvas 只在 build time 用。

roadmap 上的方向：更清楚的 glyph 渲染（eval/glyph-matrix/，跑一半暫停）、imaged bulk 是否能把有效 context 撐到 2×、更小的 active context 能否提升 long-task 精準度。作者說「這些是 hypothesis，不是 claim，要嘛有 n 撐起來，要嘛砍掉」——這個態度在開源 AI 工具裡算少見的誠實。

整個 repo 本身（包括 README）就是用 pxpipe 加上 Opus/Fable agent session 寫出來的，agent 在工作中讀自己的 collapsed history（imaged 過的）來保持 context 不爆。作者親自示範了「吃自己的狗糧」。