pxpipe：將 Claude Code 上下文渲染成圖片來削減令牌用量
透過將文字上下文渲染為圖像來減少《神鬼寓言 5》標記的使用。閱讀器與 Anthropic 的電腦所使用的螢幕截圖所依賴的視覺通道相同。
秒懂
- 它是什麼？
- 一個本地 TypeScript 代理在請求離開機器之前，把其中體積龐大的部分改寫成緊湊的 PNG。README 把令牌計算、逐請求的測量方法和有損權衡都擺在前面。
- 適合誰用？
- pxpipe 是一個本地代理，押注在當前的視覺模型上，密集上下文以圖片形式比文字形式更省令牌。README 用可重現的數據記錄了有損權衡、逐請求的測量方法和尚未完成的研究項目，並沒有聲稱問題已經解決。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 5 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
pxpipe：一個用圖片令牌換文字令牌的代理
pxpipe 是一個本地 TypeScript 代理，在請求離開機器之前，把 Claude Code 請求中體積龐大的部分改寫成 PNG 圖片。其機制依賴視覺模型的一個性質：圖片的令牌成本由像素尺寸決定，而不由其中包含多少文字決定。README 報告，程式碼、JSON 和工具輸出等密集內容每個圖片令牌大約能裝 3.1 個字元，而在真實 Claude Code 流量中，每個文字令牌大約對應 1 個字元。所用的讀取通道正是 Anthropic 的 computer use 在截圖上已經依賴的同一條視覺通道，專案採用 MIT 授權。（pxpipe 1-1）
在 teamchong/pxpipe 的脈絡中，這一節只能由 README 已列出的入口來核對。請以 teamchong/pxpipe 的 README、main 分支內容與 releases 頁面確認版本，再保留實際命令輸出、設定鍵和錯誤訊息。素材未說明的效能、相容性、故障恢復或安全保證，不應從專案描述、star 數或單一範例推導。若要驗證本節，應選取一個與 pxpipe 直接相關的最小輸入，觀察輸出檔案、API 回應或終端日誌，並把成功與失敗結果分開記錄。（章節 1）
teamchong/pxpipe 第 1 節的入口還要和相鄰章節分開看：pxpipe README 明確寫出的命令、檔名或 API 只支持它所描述的範圍。執行時應保存輸入內容、程式版本和輸出結果，遇到錯誤則記錄完整訊息，不把一次成功執行延伸成所有平台都能成功。
teamchong/pxpipe 第 1 節的採用邊界，取決於 README 具體列出的版本與執行條件。測試時先檢查 pxpipe 的安裝入口是否成功，再逐項比對輸入、輸出和日誌；若需要外部服務、容器、憑證或特定作業系統，應把該條件寫入紀錄。pxpipe README 沒有描述的行為仍屬未知，不能用相似工具的經驗代替。這項紀錄也要標明實際執行日期與平台，方便區分版本差異。
pxpipe：文件裡給出的三種執行方式
README 記錄了三種入口。最簡單的是代理方式：執行 `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/ 上的儀表板顯示已節省的令牌、每次文字轉圖片的並排對比、一個終止開關和即時模型標籤。`pxpipe warp` 命令包裝 `claude`、`cursor-agent`、`codex` 或一個 shell 別名，不需要覆蓋 base URL，因此 /remote-control、claude.ai 連接器和第一方閘道繼續運作。第三種路徑是離線匯出：`npx pxpipe-proxy export src/` 在不執行代理、也不連接 Claude Code 的情況下把文字、檔案或差異渲染成 PNG 頁，並寫出一個全新的輸出資料夾，內含頁面 PNG、事實表、清單檔案和一個供貼到圖片上傳用戶端（如 Cursor）的提示文字。（pxpipe 2-1）
在 teamchong/pxpipe 的脈絡中，這一節只能由 README 已列出的入口來核對。請以 teamchong/pxpipe 的 README、main 分支內容與 releases 頁面確認版本，再保留實際命令輸出、設定鍵和錯誤訊息。素材未說明的效能、相容性、故障恢復或安全保證，不應從專案描述、star 數或單一範例推導。若要驗證本節，應選取一個與 pxpipe 直接相關的最小輸入，觀察輸出檔案、API 回應或終端日誌，並把成功與失敗結果分開記錄。（章節 2）
teamchong/pxpipe 第 2 節的入口還要和相鄰章節分開看：pxpipe README 明確寫出的命令、檔名或 API 只支持它所描述的範圍。執行時應保存輸入內容、程式版本和輸出結果，遇到錯誤則記錄完整訊息，不把一次成功執行延伸成所有平台都能成功。
teamchong/pxpipe 第 2 節的採用邊界，取決於 README 具體列出的版本與執行條件。測試時先檢查 pxpipe 的安裝入口是否成功，再逐項比對輸入、輸出和日誌；若需要外部服務、容器、憑證或特定作業系統，應把該條件寫入紀錄。pxpipe README 沒有描述的行為仍屬未知，不能用相似工具的經驗代替。這項紀錄也要標明實際執行日期與平台，方便區分版本差異。
pxpipe：哪些被成像，哪些保持文字
代理壓縮三類輸入塊，每一類都經過一個獲利門檻：大約 6k 字元以上、令牌密集的大型 tool_result 主體；較早折疊起來的歷史輪次（最近的輪次始終保留為文字）；以及靜態可快取的系統提示加工具文件塊。不可快取的系統塊保持即時文字，讓宿主自訂指令保持系統層級的顯著性。其餘一切都逐位元組原樣通過：使用者訊息、最近的輪次、模型的輸出（代理從不觸碰回應）、稀疏散文，以及任何小到不值得轉換的內容。在 Anthropic 請求上，靜態前綴和提示快取邊界得到保留。代理也處理 OpenAI Responses 與 Chat Completions、Google generateContent 請求，並能把 Anthropic Messages 橋接到設定的 OpenAI 相容提供者。（pxpipe 3-1）
在 teamchong/pxpipe 的脈絡中，這一節只能由 README 已列出的入口來核對。請以 teamchong/pxpipe 的 README、main 分支內容與 releases 頁面確認版本，再保留實際命令輸出、設定鍵和錯誤訊息。素材未說明的效能、相容性、故障恢復或安全保證，不應從專案描述、star 數或單一範例推導。若要驗證本節，應選取一個與 pxpipe 直接相關的最小輸入，觀察輸出檔案、API 回應或終端日誌，並把成功與失敗結果分開記錄。（章節 3）
teamchong/pxpipe 第 3 節的入口還要和相鄰章節分開看：pxpipe README 明確寫出的命令、檔名或 API 只支持它所描述的範圍。執行時應保存輸入內容、程式版本和輸出結果，遇到錯誤則記錄完整訊息，不把一次成功執行延伸成所有平台都能成功。
teamchong/pxpipe 第 3 節的採用邊界，取決於 README 具體列出的版本與執行條件。測試時先檢查 pxpipe 的安裝入口是否成功，再逐項比對輸入、輸出和日誌；若需要外部服務、容器、憑證或特定作業系統，應把該條件寫入紀錄。pxpipe README 沒有描述的行為仍屬未知，不能用相似工具的經驗代替。這項紀錄也要標明實際執行日期與平台，方便區分版本差異。
pxpipe：有損的部分一開始就寫明了
README 的 "honest part"（誠實部分）一節直說這種方案是有損的。密集成像內容中的 12 字元精確十六進位字串，在預設的 Fable 5 模型上得分為 13/15，在 Sol 上為 0/15；漏讀被描述為無聲的臆造（silent confabulation）而不是讀錯，因為模型視覺不是 OCR：圖像變成補丁嵌入（patch embeddings），永遠不是離散字元，所以沒有逐字形的信心可供大聲地失敗。建議是 ID、雜湊和密鑰這類必須逐位元組精確的值要留在文字裡，最近的輪次正是如此。專門的逐字風險防護尚未構建；文件給出的逃生通道是把逐位元組精確的工作路由到非白名單模型上的子代理，它們會以文字形式原樣通過。（pxpipe 4-1）
在 teamchong/pxpipe 的脈絡中，這一節只能由 README 已列出的入口來核對。請以 teamchong/pxpipe 的 README、main 分支內容與 releases 頁面確認版本，再保留實際命令輸出、設定鍵和錯誤訊息。素材未說明的效能、相容性、故障恢復或安全保證，不應從專案描述、star 數或單一範例推導。若要驗證本節，應選取一個與 pxpipe 直接相關的最小輸入，觀察輸出檔案、API 回應或終端日誌，並把成功與失敗結果分開記錄。（章節 4）
teamchong/pxpipe 第 4 節的入口還要和相鄰章節分開看：pxpipe README 明確寫出的命令、檔名或 API 只支持它所描述的範圍。執行時應保存輸入內容、程式版本和輸出結果，遇到錯誤則記錄完整訊息，不把一次成功執行延伸成所有平台都能成功。
teamchong/pxpipe 第 4 節的採用邊界，取決於 README 具體列出的版本與執行條件。測試時先檢查 pxpipe 的安裝入口是否成功，再逐項比對輸入、輸出和日誌；若需要外部服務、容器、憑證或特定作業系統，應把該條件寫入紀錄。pxpipe README 沒有描述的行為仍屬未知，不能用相似工具的經驗代替。這項紀錄也要標明實際執行日期與平台，方便區分版本差異。
pxpipe：節省量如何測量，以及在哪裡不成立
頭條節省數字既依賴負載，也依賴用戶端。README 報告在目前的 Fable 列表價格下，端到端帳單大約低 59% 到 70%，但強調真正持久的數字是令牌削減本身，它是逐請求用免費的 count_tokens 探針在原始未壓縮請求體上測得的，兩邊同時記錄到 ~/.pxpipe/events.jsonl 的同一行。代理只在對數學有利的地方成像，獲利門檻用 391 行生產數據校準。在每令牌約 1 個字元的令牌密集內容上有收益，在每令牌約 3.5 個字元的稀疏散文上會虧錢。節省量還跟隨用戶端仍以文字重新傳送的未快取批量；Claude Code 會重新傳送系統、工具和歷史，按 README 的說法通常落在 60% 到 70% 左右。（pxpipe 5-1）
在 teamchong/pxpipe 的脈絡中，這一節只能由 README 已列出的入口來核對。請以 teamchong/pxpipe 的 README、main 分支內容與 releases 頁面確認版本，再保留實際命令輸出、設定鍵和錯誤訊息。素材未說明的效能、相容性、故障恢復或安全保證，不應從專案描述、star 數或單一範例推導。若要驗證本節，應選取一個與 pxpipe 直接相關的最小輸入，觀察輸出檔案、API 回應或終端日誌，並把成功與失敗結果分開記錄。（章節 5）
teamchong/pxpipe 第 5 節的入口還要和相鄰章節分開看：pxpipe README 明確寫出的命令、檔名或 API 只支持它所描述的範圍。執行時應保存輸入內容、程式版本和輸出結果，遇到錯誤則記錄完整訊息，不把一次成功執行延伸成所有平台都能成功。
teamchong/pxpipe 第 5 節的採用邊界，取決於 README 具體列出的版本與執行條件。測試時先檢查 pxpipe 的安裝入口是否成功，再逐項比對輸入、輸出和日誌；若需要外部服務、容器、憑證或特定作業系統，應把該條件寫入紀錄。pxpipe README 沒有描述的行為仍屬未知，不能用相似工具的經驗代替。這項紀錄也要標明實際執行日期與平台，方便區分版本差異。
pxpipe：基準涵蓋了什麼，又沒有涵蓋什麼
README 給出了各模型的算術、要點、狀態、從未陳述和密集十六進位探針的品質分數，外加兩個成對的 SWE-bench 試點：SWE-bench Lite 雙臂都是 10/10，請求體縮小 65%；SWE-bench Pro 開啟 pxpipe 為 14/19，關閉為 15/19，請求體縮小 60%。這些被標註為小樣本試點執行，收據在 eval 目錄裡。README 提醒說這些結果不是跨模型比較，所有未列出的模型都沒有執行過，Gemini 的位置檢索掃描只是方向性證據，不是普遍的 Lost-in-the-Middle 結論。容量表報告了每個模型家族實測的每視覺令牌字元數，可以用圖表腳本重新產生。（pxpipe 6-1）
在 teamchong/pxpipe 的脈絡中，這一節只能由 README 已列出的入口來核對。請以 teamchong/pxpipe 的 README、main 分支內容與 releases 頁面確認版本，再保留實際命令輸出、設定鍵和錯誤訊息。素材未說明的效能、相容性、故障恢復或安全保證，不應從專案描述、star 數或單一範例推導。若要驗證本節，應選取一個與 pxpipe 直接相關的最小輸入，觀察輸出檔案、API 回應或終端日誌，並把成功與失敗結果分開記錄。（章節 6）
teamchong/pxpipe 第 6 節的入口還要和相鄰章節分開看：pxpipe README 明確寫出的命令、檔名或 API 只支持它所描述的範圍。執行時應保存輸入內容、程式版本和輸出結果，遇到錯誤則記錄完整訊息，不把一次成功執行延伸成所有平台都能成功。
teamchong/pxpipe 第 6 節的採用邊界，取決於 README 具體列出的版本與執行條件。測試時先檢查 pxpipe 的安裝入口是否成功，再逐項比對輸入、輸出和日誌；若需要外部服務、容器、憑證或特定作業系統，應把該條件寫入紀錄。pxpipe README 沒有描述的行為仍屬未知，不能用相似工具的經驗代替。這項紀錄也要標明實際執行日期與平台，方便區分版本差異。
pxpipe：函式庫用法、開發與尚未完成的事項
除代理之外，pxpipe 還匯出一個函式庫 API：renderTextToImages 把文字變成 PNG 頁，transformAnthropicMessages 改寫請求體，並提供把區塊固定為文字或恢復已成像區塊原始內容的選項。執行時期是純 JavaScript，適用於 Node 和邊緣 Worker，canvas 依賴只在建置時使用。開發流程是 pnpm install、pnpm test 和 pnpm run build，Windows 由社群透過貢獻者 PR 支援。研究狀態一節列出了尚未測試的內容：帶文字重新取得的執行時期金絲雀、替代讀取器預檢，以及為每個新模型做解析度掃描的發布絆線。有效上下文收益被描述為尚未證實，精確回憶受每字形像素限制，因此渲染改動並不能在有利可圖的密度下消除錯誤。MIT 授權授予使用、複製、修改、合併、出版、散布、再授權和販售的權利，否認擔保，並且對支援或安全性保證隻字未提。（pxpipe 7-1）
在 teamchong/pxpipe 的脈絡中，這一節只能由 README 已列出的入口來核對。請以 teamchong/pxpipe 的 README、main 分支內容與 releases 頁面確認版本，再保留實際命令輸出、設定鍵和錯誤訊息。素材未說明的效能、相容性、故障恢復或安全保證，不應從專案描述、star 數或單一範例推導。若要驗證本節，應選取一個與 pxpipe 直接相關的最小輸入，觀察輸出檔案、API 回應或終端日誌，並把成功與失敗結果分開記錄。（章節 7）
teamchong/pxpipe 第 7 節的入口還要和相鄰章節分開看：pxpipe README 明確寫出的命令、檔名或 API 只支持它所描述的範圍。執行時應保存輸入內容、程式版本和輸出結果，遇到錯誤則記錄完整訊息，不把一次成功執行延伸成所有平台都能成功。
teamchong/pxpipe 第 7 節的採用邊界，取決於 README 具體列出的版本與執行條件。測試時先檢查 pxpipe 的安裝入口是否成功，再逐項比對輸入、輸出和日誌；若需要外部服務、容器、憑證或特定作業系統，應把該條件寫入紀錄。pxpipe README 沒有描述的行為仍屬未知，不能用相似工具的經驗代替。這項紀錄也要標明實際執行日期與平台，方便區分版本差異。
編輯結論
pxpipe 是一個本地代理，押注在當前的視覺模型上，密集上下文以圖片形式比文字形式更省令牌。README 用可重現的數據記錄了有損權衡、逐請求的測量方法和尚未完成的研究項目，並沒有聲稱問題已經解決。 適合能依 teamchong/pxpipe README 管理相依環境、版本與輸出的人；不適合把 README 的功能清單當成未經條件限制的服務承諾。先執行 README 所列的最小命令或入口，核對 pxpipe 的實際輸入、輸出、錯誤訊息與資料保存位置，再決定是否放入正式工作負載；MIT 授權下的再發布與修改責任也要由部署者依 LICENSE 原文確認。
社群筆記