Paritok

Paritokは、コードベースを書き換えず、エージェントの挙動も変えずに、AIコーディングエージェントのコンテキストを圧縮するゲートウェイだ。ローカルプロセスとして動き、エージェントがすでに送っているAPI呼び出しをそのまま受け取り、上流のモデルへ転送する前にペイロードを削る。エージェント側は、コンテキストウィンドウに使える余白が増えたこと以外、違いに気づかない。

狙う問題は現実にあり、軽く見られがちだ。コーディングエージェントは毎ターン、ツール一覧の全部、読んだファイルの全部、コマンド出力の全部を送り直す。40Kトークンで始まったセッションは20ターンで250Kを超えることもあり、そのたびにその全額を払い直す。このゲートウェイ層でのトークン圧縮は、短いプロンプトを書けと求める代わりに、その膨張を根本から叩く。これはコンテキスト圧縮ゲートウェイであって、プラグインではない。

この違いは大きい。プラグインはエージェントの内部で動き、そのエージェント固有のフックや癖に依存するため、対応範囲はばらばらで、更新のたびに壊れる。ゲートウェイは1層外側に位置する。だから同じリクエストとレスポンスがそのまま流れ、線路上のトークン数だけがターンを追うごとに静かに減っていく。

主な限界は適用範囲だ。Paritokはコーディングエージェントの通信のために作られており、一般的なチャットや文書作業向けではない。エージェントが多くのツールに頼り、多くのファイルを読むときほど効果を発揮する。では、いつ元が取れなくなるのか。セッションが短く、使うツールも少ないなら、節約量は小さく、余分なローカルプロセスが場所に見合わないこともある。若い製品なので、珍しいプロバイダーや細かなセットアップの違いでは粗さが出る。重要な作業を任せる前に、自分のエージェント構成がドキュメント通りに動くか確かめる時間を少し見ておくといい。

はじめ方

1. Paritokゲートウェイをインストールし、エージェントのリクエストを待ち受けるローカルで実行する。
2. 環境変数を1つ設定してエージェントを向ける。例えば ANTHROPIC_BASE_URL=http://127.0.0.1:8080 だ。
3. 既存のモデルプロバイダーとキーはそのまま使う。ParitokはOpenAI互換の上流ならどこへでも転送する。
4. いつも通りClaude Code、Cursor、Codex、OpenHandsでセッションを始め、トークン計が下がるのを見る。
5. エージェントが正確な内容を必要としたら、read_original(ref) を呼んで元のバイト列を取り戻す。ローカルで行われ、ターンを消費しない。