pxpipe：Claude Code のコンテキストを画像としてレンダリングし、トークン使用量を削減

teamchong-pxpipe-deep-analysis: テキストトークンを画像トークンに交換するプロキシ

pxpipe は、リクエストがマシンから出る前に、Claude Code の各リクエストのかさばる部分を PNG 画像に書き換えるローカル TypeScript プロキシだ。その仕組みはビジョンモデルの性質に依拠している。画像のトークンコストはピクセル寸法で決まり、中にどれだけのテキストが入っているかでは決まらない。README によれば、コード、JSON、ツール出力などの密集したコンテンツは、画像トークン 1 つあたりおよそ 3.1 文字を詰め込めるのに対し、実際の Claude Code トラフィックではテキストトークン 1 つあたり約 1 文字だ。読み手は Anthropic の computer use がスクリーンショットで既に頼っているのと同じビジョンチャネルで、プロジェクトは MIT ライセンスだ。

pxpipe は Claude Code の大きな tool_result、古い履歴、静的な system prompt を条件付きで PNG に変換するローカル TypeScript プロキシだ。最近のターン、ユーザーメッセージ、モデル出力、疎な散文、小さすぎる本文はテキストのまま通る。画像化の対象をこの分類に照らせば、何が変換されたかをダッシュボードで追える。

teamchong-pxpipe-deep-analysis: ドキュメントに記された 3 つの実行方法

README は 3 つの入り口を記している。最も単純なのはプロキシだ。`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` コマンドは、base URL の上書きなしで `claude`、`cursor-agent`、`codex`、またはシェルエイリアスを包むので、/remote-control、claude.ai コネクタ、ファーストパーティのゲートが動き続ける。3 つ目はオフラインエクスポートだ。`npx pxpipe-proxy export src/` は、プロキシを起動せず Claude Code に接続せずに、テキスト、ファイル、または差分を PNG ページにレンダリングし、ページ PNG、ファクトシート、マニフェスト、そして Cursor のような画像アップロードクライアントに貼り付けるプロンプトを含む新しい出力フォルダを書き出す。

npx pxpipe-proxy は 127.0.0.1:47821 で起動し、ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude で Claude Code を向ける。pxpipe warp は claude、cursor-agent、codex、シェルエイリアスを包む別入口だ。オフラインでは npx pxpipe-proxy export src/ が PNG ページ、ファクトシート、マニフェストを出力する。

teamchong-pxpipe-deep-analysis: 何が画像化され、何がテキストのままか

プロキシは 3 種類の入力ブロックを圧縮する。それぞれが収益性のゲートの後ろにある。約 6k 文字以上のトークン密集型の大きな tool_result 本体、古く折り畳まれた履歴のターン（最近のターンは常にテキストのまま）、そして静的でキャッシュ可能なシステムプロンプトとツールドキュメントのスラブだ。キャッシュ不能なシステムブロックはライブテキストのまま残り、ホストのカスタム指示がシステムレベルの顕著性を保つ。それ以外のすべて、ユーザーメッセージ、最近のターン、モデルの出力（プロキシはレスポンスに触れない）、疎な散文、小さすぎて勝てないものは、すべてバイト単位でそのまま通過する。Anthropic リクエストでは、静的プレフィックスとプロンプトキャッシュの境界が保たれる。プロキシは Anthropic Messages、OpenAI Responses と Chat Completions、Google generateContent リクエストを扱い、Anthropic Messages を設定済みの OpenAI 互換プロバイダにブリッジできる。

正確な 16 進文字列、ID、ハッシュ、secret は画像化してはいけない。README の probe では Fable 5 が 13/15、Sol が 0/15 で、読み間違いが静かな捏造になると説明される。逐語的に一致すべき作業はテキストのまま通し、必要なら対象外モデルのサブエージェントへ分けるという逃げ道が示されている。

teamchong-pxpipe-deep-analysis: 劣化する部分は最初に明かされている

README の「honest part」の節は、この手法が劣化を伴うと率直に述べている。密集した画像化コンテンツ内の 12 文字の正確な 16 進文字列は、デフォルトの Fable 5 モデルで 13/15、Sol で 0/15 だった。読み損ねは読み間違いではなく、静かな捏造（silent confabulation）と表現されている。モデルのビジョンは OCR ではないからだ。画像はパッチ埋め込みになり、決して個別の文字にはならないため、大きな音を立てて失敗するグリフ単位の信頼度は存在しない。ID、ハッシュ、シークレットのようなバイト単位で正確でなければならない値はテキストのままでなければならず、最近のターンはそうなっている。専用の逐語リスクガードはまだ作られていない。文書化された逃げ道は、バイト単位で正確な作業を、ホワイトリスト外のモデル上のサブエージェントに回すことで、それはテキストとしてそのまま通過する。

効果測定には元の非圧縮 body に対する count_tokens とリクエスト単位の記録を使い、~/.pxpipe/events.jsonl の行を照合する。README の SWE-bench は Lite が両方 10/10、Pro が pxpipe あり 14/19、なし 15/19 の小規模 pilot である。これは価格や品質の保証ではなく、ワークロード別の比較材料として扱うべきだ。

teamchong-pxpipe-deep-analysis: 削減量の測り方と、成り立たない場面

見出しの削減数字は、ワークロード依存でありクライアント依存だ。README は現在の Fable リスト価格でエンドツーエンドの請求額がおよそ 59 から 70 パーセント下がると報告するが、永続する数字はトークン削減そのものであり、元の非圧縮ボディに対する無料の count_tokens プローブとリクエスト単位で比較して測られ、両側が ~/.pxpipe/events.jsonl の同じ行に記録されると強調する。プロキシは、391 行の本番データで校正された収益性ゲートの後で、計算が有利なところだけを画像化する。得になるのはトークン 1 つあたり約 1 文字のトークン密集コンテンツで、トークン 1 つあたり約 3.5 文字の疎な散文では損をする。削減はまた、クライアントがテキストとして再送信する未キャッシュのバルクに追従する。Claude Code はシステム、ツール、履歴を再送信し、README のクライアント依存の節によれば通常 60 から 70 パーセントあたりに落ち着く。

teamchong-pxpipe-deep-analysis: ベンチマークがカバーするものと、しないもの

README には、算術、要点、状態、決して述べられなかったこと、密集 16 進の各プローブに対するモデル別の品質スコアに加え、2 つのペアになった SWE-bench パイロットが含まれる。SWE-bench Lite は両腕とも 10/10 でリクエストサイズが 65 パーセント減、SWE-bench Pro は pxpipe ありで 14/19、なしで 15/19、リクエストサイズが 60 パーセント減だ。これらは eval ディレクトリに証拠を持つ小規模 n のパイロット実行と明記されている。README は、結果はモデル間比較ではなく、リストにないモデルは一切実行されていないこと、Gemini の位置検索スイープは方向性の証拠であって一般的な Lost-in-the-Middle の結果ではないことを注意書きしている。容量表は各モデルファミリーについて、ビジョントークンあたりの実測文字数を報告しており、チャートスクリプトで再生成できる。

teamchong-pxpipe-deep-analysis: ライブラリ利用、開発、そして未解決の項目

プロキシの他に、pxpipe はライブラリ API を公開している。renderTextToImages はテキストを PNG ページに変換し、transformAnthropicMessages はリクエストボディを書き換え、ブロックをテキストとして固定したり、画像化されたブロックの原本を復元したりするオプションがある。ランタイムは Node とエッジワーカー向けの純 JavaScript で、canvas 依存はビルド時のみだ。開発は pnpm install、pnpm test、pnpm run build で、Windows はコントリビューターの PR によるコミュニティサポートだ。研究状況の節は、まだテストされていないものを列挙している。テキスト再取得を伴うランタイムカナリア、代替リーダーの事前チェック、新しいモデルごとの解像度スイープというリリースの踏み石だ。実効コンテキストの利点は証明されていないとされ、正確な再現はグリフあたりのピクセル数に制限されるため、レンダリングの変更は収益性のある密度でエラーを排除しない。MIT ライセンスは使用、複製、変更、統合、公開、配布、サブライセンス、販売の権利を許諾し、保証を否認し、サポートやセキュリティ保証については何も述べていない。

編集部の結論

pxpipe は、現在のビジョンモデルでは密集したコンテキストはテキストよりも画像の方が安い、という賭けに出るローカルプロキシだ。README は劣化を伴うトレードオフ、リクエスト単位の測定方法、そして未解決の研究項目を証拠とともに記録しており、問題が解決済みだと主張してはいない。

公式情報源

1. Official README
2. Project repository
3. Release notes