ニューラルネットワークに壁のようなコードの画像をそのまま食べさせて、トークン予算を60%節約する方法
最近、ふと我々が言語モデルのコンテキストウィンドウを専らテキストとして扱うことに慣れてしまったことに気づいた。50,000文字のファイルを送ると、12〜15,000のテキストトークンを支払うことになる。数時間Claude CodeやCursorを実行している場合、コンテキストはシステムプロンプト、ツールドキュメント、コマンド実行ログで絶えず補充されていく。月末のAPI請求書は少しずつ驚きへと変わり始めている。
pxpipeプロジェクトのデベロッパーは、最新のマルチモーダルモデル料金体系にある興味深い抜け道に気づいた。画像トークンのコストはピクセル単位の物理解像度のみに依存し、その上に描かれたテキスト量には関係しない。密集したテキストを小さいフォントでコンパクトなスクリーンショットに圧縮すれば、1つの画像トークンは標準テキストトークンの約3〜5倍多くの文字を保持できる。
こうして、ローカルプロキシサーバーのアイデアが生まれた——AnthropicやOpenAIにリクエストを送信する前に、重量級の部分をオンザフライでモノクロPNGページに再描画するサーバーだ。
この裏技の仕組み
テキスト形式では、JSON、データベースダンプ、コードなどの密集したデータはトークンあたり約1文字の速度で消費される。一方、Claude 3.5 Sonnet、Claude Opus、Geminiなどの最新のモデルは、内蔵のビジョンモジュールを通じてラスター画像を非常に 잘認識する。
pxpipeツールは、マシン上の送信APIリクエストを傍受し、扱いにくいコンテキストをカスタム等幅フォント（Spleen 5×8やJetBrains Monoなど）で密集した画像にスライスする。
システムプロンプトとツール説明の25,000トークンの生の代わりに、モデルはわずか2,700トークンの画像数枚を受け取る。100万トークンのコンテキストウィンドウでは、実際の文字容量は約5倍増加し、400万文字から1,900〜2,100万文字になる。
何が圧縮されて、何がテキストのままか
会話全体を画像に変換すると、モデルは正確な識別子で必ずミスを犯し始める。pxpipeの開発者はこれを考慮しているため、圧縮は選択的に機能する：
- 大きなツール実行結果。コンソールコマンド出力、テストログ、読み取りファイルが6,000文字を超える場合、PNGに変換される。
- 古いメッセージ履歴。長いセッションの初期ステップはアーカイブページにパックされる。
- 重量級のシステムプロンプトとMCPツール仕様。これらはキャッシュされ、グラフィックシートとして送信される。
ユーザーの最新の返信、最新のモデルの応答、短いテキストスニペットは元のテキスト形式で変更なく送信される。モデルは最近の編集をバイト単位でそのまま認識する。
クイックスタートとエージェントへの接続
永続的なインストールなしでユーティリティを実行できる。ローカルサーバーがポート47821で起動する：
npx pxpipe-proxy
その後、Claude Codeをローカルアドレスに向けるだけだ：
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude
環境変数を扱いたくない場合、リポジトリには特定のプロセスのネットワーク呼び出しをプロキシするラッパーコマンドが含まれている：
pxpipe warp -- claude
# либо для других агентов
pxpipe warp -- cursor-agent
プロキシとともに、Webダッシュボードがhttp://localhost:47821で起動する。節約したドル額、トリムされたトークン数、各生成されたページのプレビューと元のテキストがリアルタイムで表示される。
サーバーを起動せずにエクスポート
プロキシは不要だが、画像をサポートするチャットWebインターフェースに大規模なコードベースやgit diffを入力したい場合は、エクスポートモードを使用できる：
npx pxpipe-proxy export src/
cat logs.txt | npx pxpipe-proxy export --stdin
npx pxpipe-proxy export --git
このコマンドは、そのまま使用可能なPNGファイル、主要なエンティティの簡潔なファイル、そしてダイアログウィンドウに貼り付けるプロンプトを含むフォルダを作成する。
コインの表裏と正直な制限事項
このアプローチはチートのように見えるが、避けられない物理的な制限がある。開発者はドキュメントに直接記載している：
- ハッシュとIDの精度低下。LLMビジョンモジュールは、クラシックな文字単位の確率を持つOCRではなく、エンベッディングパッチを通じて動作する。文字あたりのピクセルが足りない場合、言語モデルは単に、もっともららしい文字を捏造する。開発者のテストでは、Fable 5での12文字の16進文字列の完全一致は15個中13個であり、一部のモデルではゼロまで低下した。重要な識別子はテキストのままにしておくべきだ。
- レンダリング遅延。大きなリクエストを送信する前に、プロセッサはメモリ内でPNGバッファを生成するために数百ミリ秒を費やす。
- 効果はコンテンツの密度に依存する。コード、スタックトレース、JSON構造体で節約が最大になる。自然な言語の通常の会話テキストでは、標準テキストではすでに1トークンあたり約3〜4文字なので、利点は最小限またはまったくない。
今のところ誰にとって有用か
自律型コーディングエージェントを定期的に使用する場合、ベンチマークを実行する場合、またはモデルに数メガバイトのビルドログを入力する場合、pxpipeは初日から費用対効果を示す。長いデバッグセッションでは、エージェントの動作の全体的なロジックを維持しながら、日次請求額が40ドルから6〜7ドルに低下する。
数分でツールを試すことができ、最初のテストでさえソースからビルドする必要はない。すべてのトークン統計はユーティリティによってローカルログに整然と保存されるため、ユーティリティでタスクの実質的な利点を簡単に確認できる。
関連プロジェクト