著者 Paritokでコーディングエージェントの料金は安くなる？
Paritokはファイル読み取りやツール出力を圧縮するゲートウェイです。トークンを74%削減する仕組みと、料金が逆転する損益分岐点を検証します。
リクエストに対して Paritok が行う処理
Paritok はトークンゲートウェイです。コーディングエージェントとモデル API の間に配置され、各リクエストを圧縮してから転送するプロキシです。エージェントはプロバイダーの API ではなく http://127.0.0.1:8080 と通信します。プロキシはツールスキーマ、ファイル読み取り、ツール出力、過去のターンを書き換え、より小さいペイロードを上流へ送信し、応答を変更せずに返します。
プロバイダーは、プロバイダーに到着した内容に対して課金します。そのため、ペイロードが小さければ請求額も小さくなります。これが基本的な考え方です。これは「コンテキストがより長く保持される」という主張とは異なります。この点が、Paritok を単なる整理用ツールではなく、興味深いツールにしています。
このプロジェクトは新しいものです。最初の公開タグは July 2026 付けで、現在のタグは 5 August 2026 付けの v1.3.0 です。重みとゲートウェイコードのライセンスは Apache 2.0 です。圧縮モデルは Qwen3-4B-Instruct-2507 に対する LoRA（low-rank adaptation）アダプターです。実際のコーディングエージェントの軌跡から取得した、教師モデルで蒸留した 45,000 件のサンプルを使って学習されています。
コンテキストのトリミングではない理由
トリミングは削除です。エージェントがコンテキストの上限に近づき、古いターンから削除すると、ターン 3 で読み取ったファイルは失われます。ターン 20 でそのファイルが必要になると、再度ファイルを読み取るため、そのトークンの料金をもう一度支払うことになります。節約分は一時的な借り入れにすぎません。
Paritok はセグメントを、短い形式とタグ [REF:id] に置き換え、完全なテキストをプロキシ上に保持します。モデルは read_original または expand_context を呼び出して、セグメントを復元します。これにより、障害の発生形態が変わります。トリマーは、忘れることで失敗し、その事実を通知しません。コンプレッサーは、情報が欠落した要約をモデルに渡すことで失敗しますが、要約だけでは不十分な場合、モデルは元のテキストを要求できます。
ツールフィルターも同じように動作します。フィルターで除外されたツールスキーマは削除されず、スタブに置き換えられます。モデルは gateway_search_tools を呼び出して、スキーマを復元します。これは重要です。ツールを恒久的に隠すフィルターを使うと、エージェントが実行できる処理自体が変わるためです。そして、その影響は、タスクが気付かないうちに失敗することで初めて分かる可能性があります。
3 つのレバーと、無料で使えるもの
1 つ目のレバーは、ツールスキーマフィルターです。すべてのリクエストに、tools 配列全体が含まれます。複数の MCP（model context protocol）サーバーを接続した Claude Code の 1 回のターンでは、このブロックは約 29,000 トークンになります。フィルターは、BAAI/bge-small-en-v1.5（130 MB の埋め込みモデル）を使ってユーザーのリクエストと各ツールの説明を埋め込み、該当するツールを残して、それ以外をスタブに置き換えます。これにより、ブロックは約 8,000 トークンまで減少します。この埋め込みモデルは CPU で動作します。
2 つ目のレバーはコンテンツ圧縮です。ここで 4B モデルを GPU 上で実行する必要があります。ファイルの読み取り結果、ツールの出力、履歴を、元のサイズの 25.7% まで圧縮します。74% という見出しの数字は、この処理によるものです。注意してください。74% は圧縮対象のコンテンツに対する圧縮率であり、請求額の削減率ではありません。
3 つ目のレバーは履歴の要約です。コンテキストの予算がいっぱいになると、直近のウィンドウより前のターンを要約します。これにより、長いセッションでも上限に達して停止せず、実行を継続できます。
GPU が必要なのは 2 つ目のレバーだけです。これが、このページで最も重要な説明です。pip install "paritok[toolselect]" を使えば、通常の CPU VPS 上でツールフィルターを利用できます。しかもこれは、月額費用がかからない製品の半分に当たる機能です。GPU を借りる前に試してください。
プロジェクトが測定した内容と、その測定ハーネス
The data behind this chart
[
{
"label": "Paritok-4B-v1",
"compressed_to_pct": 25.7,
"quality_retained_pct": 86.5
},
{
"label": "gpt-4.1-mini",
"compressed_to_pct": 50.2,
"quality_retained_pct": 85.6
},
{
"label": "gpt-5",
"compressed_to_pct": 61.9,
"quality_retained_pct": 93.6
}
]これらは、プロジェクトが独自のハーネスを使用し、SWE-bench Lite に対して測定した、プロジェクト自身の公開値です。Paritok-4B-v1 は、元のサイズの 25.7% まで内容を圧縮しながら、非圧縮時の解決率の 86.5% を維持します。圧縮に gpt-5 を使うと、93.6% と品質をより多く維持できますが、圧縮後のサイズは 61.9% にしかなりません。つまり、frontier 価格を節約するために frontier 価格を支払うことになります。
品質の列は正確に読み取ってください。解決率の 86.5% を維持するということは、非圧縮の実行では解決できた問題を、圧縮した実行では失敗したという意味です。ほぼ 7 問に 1 問の割合です。ベンチマークでは表の中の数値にすぎません。しかし、リポジトリでは同じタスクを 2 回実行することになります。
The data behind this chart
[
{
"label": "Turn 1",
"saved_pct": 25
},
{
"label": "Turn 5",
"saved_pct": 39
},
{
"label": "Turn 12",
"saved_pct": 57
},
{
"label": "Turn 20",
"saved_pct": 63
}
]セッションが進むほど、エンドツーエンドの削減量は増えます。履歴が蓄積し、圧縮対象になるのがその履歴だからです。プロジェクトの報告では、1 ターンでは約 25%、5 ターンでは 39%、20 ターンでは 63% を削減します。また、増加が止まる箇所も示されています。200,000 トークンの予算では、絶対的な削減量は 1 ターンあたり約 48,000 トークンで頭打ちになります。これはおよそ 8 から 12 ターン付近です。コンテキストが一杯になると、履歴が増えなくなるためです。広く引用される「85%超」という値は、コンテキストが飽和したセッションを表します。これは最良のケースなので、この値を前提に計画しないでください。
24GB GPU は Paritok の費用を回収できるか
このサイズのモデルでは、24 GB カードが一般的なレンタル単位です。2026 年 8 月 7 日時点で、24 GB の RTX 4090 に対する公開オンデマンド料金の中央値は 1 時間あたり $0.44 で、最安の掲載は $0.20 前後でした。ここでは $0.44 を使います。1 か月間連続で稼働させると 730 時間なので、$321 です。稼働時間を平日の 1 日 8 時間、22 日間だけにすると 176 時間で、$77 です。
次に、トークン削減量を金額の削減量に換算します。削減されるのは入力トークンです。出力トークンはプロキシをそのまま通過するため、まったく変わりません。コーディングエージェントでは入力トークンが請求額の 80% を占めるのが一般的なので、これを前提にします。実際の請求額と照合してください。金額の削減率は、トークン削減率に 0.8 を掛けた値になります。
The data behind this chart
[
{
"label": "Turn 5 (39% saved)",
"bill_always_on_usd": "1,030",
"bill_workday_only_usd": 248
},
{
"label": "Turn 20 (63% saved)",
"bill_always_on_usd": 637,
"bill_workday_only_usd": 154
},
{
"label": "Saturated (85% saved)",
"bill_always_on_usd": 472,
"bill_workday_only_usd": 114
}
]セッションが飽和した場合の 85% では、請求額の 68% を維持できます。そのため、カードを常時稼働させる場合、月間のエージェント利用額が約 $472 を超えると元が取れます。勤務時間外にインスタンスを停止する場合は、約 $114 です。turn-20 の 63% では、それぞれ $637 と $154 になります。短いセッションで実際に近い turn-5 の 39% では、カードをレンタルする価値が生じる前に、月額約 $1,030 が必要です。
この表より有利になる要因が 2 つあります。モデルは 24 GB を必要としません。q4 ビルドは約 2.5 GB、bf16 ビルドは約 8 GB なので、より小さいカードや、別の用途ですでに稼働させている GPU ボックスを使えば、表のすべての金額が下がります。また、誰もコーディングしていない時間にインスタンスを停止することが最大の節約策です。レンタル料金を約 4 分の 1 に削減できるためです。
不利になる要因も 1 つあります。圧縮処理には実際の計算が必要です。4B モデルが圧縮する各トークンは、モデルが読み取ってから書き出す必要があるため、エージェントの各 turn に遅延が加わります。時間単位でレンタルするカードでは、このコストは請求書の項目ではなく待ち時間として現れます。そのため、実際に遅延を感じるまで見落としやすくなります。
レンタル GPU の稼働時間と API トークンを一般的に比較する場合は、GPU VPS と API トークンの損益分岐点で推論自体について同じ計算を行っています。
VPS で Paritok gateway を実行する
Python 3.10 以降が必要です。Ubuntu 24.04 には Python 3.12 が含まれているため、CPU のみを使う構成では標準の VPS イメージで十分です。
sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"バージョンを固定します。リポジトリは 2026 年 7 月 29 日に v1.2.8、2026 年 8 月 5 日に v1.3.0 をタグ付けしています。この速度で更新されるプロジェクトでは、リリース間で設定キーが変更されます。単なる pip install paritok や main の git clone を使うと、次週には別の gateway が導入され、測定した値をどのバージョンが生成したのか記録も残りません。
デフォルトのバックエンドは Ollama です。モデルを pull し、proxy が参照する短い名前を付けます。
ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1ローカルモデルは、圧縮する各セグメントを書き換えるため、長時間実行される圧縮処理は agent のターンが停止したように見えます。Ollama の出力長を制限する num_predict の上限が、その長さを制限する設定です。
その横に paritok.yaml を記述します。use_gpu_server: false により、圧縮処理を自分のハードウェア上で実行できます。
use_gpu_server: false
local_model:
base_url: http://localhost:11434paritok proxy --port 8080 --config-file paritok.yamlparitok up は、これまでの処理をまとめて行うショートカットです。モデルがなければ pull し、port 8080 で proxy を起動します。agent を接続する前に proxy を確認してください。
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats/health は、"status":"ok" とバージョン文字列を含む小さな JSON オブジェクトを返します。/stats は圧縮の合計値と、proxy 自身が見積もった削減量を返します。この見積もりは proxy が自分の処理を評価した値にすぎないため、provider の使用量ページでも確認してください。
利便性よりスループットを優先する場合は、vLLM を使ってベースモデル上で adapter を提供します。
vllm serve Qwen/Qwen3-4B-Instruct-2507 \
--enable-lora \
--lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
--port 8000Ollama はすぐに構築できます。一方、vLLM は同時リクエストをはるかに効率よく処理します。1 台のホストを複数の agent で共有すると、この差がすぐに重要になります。Ollama と vLLM の実用上の違いを基準に選択してください。
base URL の環境変数を使い、agent の接続先を proxy にします。
export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080Codex CLI は OPENAI_BASE_URL を無視するため、paritok.yaml で codex.enabled: true が設定されている場合、プロジェクトが ~/.codex/config.toml を書き込みます。環境変数だけを export すると、Codex は provider に直接接続します。その場合の兆候は、作業中も /stats カウンターがまったく増えないことです。
listener は 127.0.0.1 で待ち受けさせ、0.0.0.0 では待ち受けさせないでください。proxy は provider の API key を上流へ転送します。インターネットから到達できる proxy は、その key のオープンリレーになります。port を見つけた第三者は、key 自体を見なくてもあなたの費用で利用できます。port を開放するのではなく、SSH tunnel または VPN 経由で laptop から接続してください。
再起動後も動作するように、systemd で実行します。インストール先に合わせてパスを調整してください。
[Unit]
Description=Paritok compression proxy
After=network-online.target
[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure
[Install]
WantedBy=multi-user.targetsudo systemctl enable --now paritok で有効化し、その後もう一度 /health を実行します。起動直後に終了する unit は、通常、設定ファイルのパスが正しくないことを示します。journalctl -u paritok -n 50 で理由を確認できます。
ホスト型の選択肢と、その代償
このプロジェクトは、圧縮機能をサービスとしても提供しています。API key を使って use_gpu_server: true を設定すると、4B model がサービス提供者のハードウェア上で実行されます。料金は処理した 1000000 tokens あたり $0.30 ですが、公式ドキュメントによると 2026 年 8 月末までは無料です。これにより、上記の GPU のレンタル費用と運用作業がすべて不要になります。
一方で、prompt と agent が読み取るファイルは、model provider に届く前にマシンから離れ、第三者に送信されます。Self-hosting は、まさにこの経路を避けるためのものです。use_gpu_server: true を設定する前に、どちらを優先するかを決めてください。flag の変更は 1 行で済みますが、その結果は同じではありません。
自分で実施前後を測定する方法
公開されている数値は、SWE-bench Lite 上でプロジェクト独自のハーネスを使って測定した、プロジェクトの数値です。あなたのリポジトリは SWE-bench Lite ではありません。自分の環境で測定してください。
- プロキシを経路に置かず、通常の作業を 1 週間行います。プロバイダーの使用量ページから、入力トークン、キャッシュ読み取りトークン、出力トークンを、それぞれ別の行として記録します。合計金額だけを記録してはいけません。
- 次の 1 週間はプロキシを前段に置き、同じ種類の作業を行います。
- 入力とキャッシュ読み取りの行を比較します。出力は何も圧縮されないため、おおむね一定になるはずです。出力が大きく変化した場合は、プロキシ以外の要因が変わっています。
- やり直しが必要になったタスク数を数えます。これはこのトレードオフにおける品質面の指標ですが、どのダッシュボードにも表示されません。
- 合計を比較する前に、2 週目の GPU 時間を加算します。
入力と出力を分けて確認することが重要です。両者の料金は大きく異なり、コンプレッサーが処理するのは一方だけだからです。2026 年 8 月時点で、Claude Sonnet 4.6 の料金は入力トークン 100 万あたり $3、出力トークン 100 万あたり $15 です。プロンプトキャッシュの読み取りは入力料金の 10% で、100 万あたり $0.30 です。入力トークンと出力トークンの料金差によって、入力側のコンプレッサーが自分の環境で有効かどうかが決まります。Claude Code のトークンが実際に消費される場所では、圧縮を検討する価値があるほど大きなコンテキスト部分がどれかを確認できます。
特にツールフィルターの計算では、プロンプトキャッシュが複雑な要因になります。ツールブロックはリクエストの先頭に置かれるため、通常、最初のターン以降は入力料金の 10% でキャッシュヒットします。キャッシュ済みブロックから 21,000 トークンを削減しても、節約額はキャッシュされていない場合の料金から算出した $0.063 ではなく、100 万あたり $0.30 で計算した 21,000 トークン分、つまり 1 ターンあたり約 $0.006 です。プロジェクトはセッション中、フィルター済みブロックを固定します。これにより、キャッシュ済みのプレフィックスが変化しません。ターンごとにツールを再選択するフィルターでは、そのプレフィックスが無効になり、節約額を上回るコストが発生します。
検証が済んでいない点
ここまでに示した性能値は、すべてプロジェクト自身が公表したものです。SWE-bench Lite の結果を独立して再現した検証はなく、最初のタグが 2026 年 7 月付けであるため、コードの運用実績もほとんどありません。圧縮率と品質維持率は、どちらも良い結果を示すことで利益を得る当事者が測定した値です。だからといって、誤りとは限りません。ただし、未確認の値です。自分で測定した値とは分けて扱う必要があります。
自分の環境を原因と判断する前に、把握しておくべき仕様が 1 つあります。このツールのフィルターが使用する embedding model は起動時ではなく、最初のリクエスト時に読み込まれます。そのため、プロジェクトでは 10 to 15 秒のウォームアップ時間を記載しており、その後は 1 回あたり約 15 ms です。proxy の起動後に使い捨てのリクエストを 1 回送っておけば、最初の実際の agent turn がハングしたようには見えません。
午後のうちに、自分で確認できる点は 4 つあります。proxy が起動して稼働し続けるか、作業中に /stats が変化するか、provider の input-token の明細が実際に減るか、そして agent が作業を最後まで完了するかです。これらの結果のほうが、公開されたベンチマークよりも、自分の環境に適用できるかどうかを正確に判断できます。
他のツールとの位置付けについて説明します。自己ホスト型の LiteLLM gateway はリクエストの内容を変更せずに、ルーティングと使用量の計測を行います。そのため、両者は異なる問題を解決し、組み合わせて利用できます。Paritok は agent に最も近い位置に配置します。目的がこの特定のツールではなく、請求額を下げることであれば、VPS 上の agent に適用できる幅広いコスト削減策には、最初に無料で試せる変更がいくつかあります。
FAQ
Paritok は API 料金を削減しますか。それともコンテキスト使用量だけを削減しますか。
API 料金を削減します。プロキシがプロバイダーに到達する前にリクエストを書き換え、プロバイダーは受信した内容に対して課金するためです。ただし、削減幅は見出しから受ける印象より小さくなります。74% という数値は、圧縮対象のコンテンツに対する圧縮率です。エンドツーエンドでは、プロジェクトの報告によると、1 回のターンで約 25%、20 ターン目までで 63% です。変化するのは入力トークンだけです。出力トークンはそのまま通過します。
圧縮モデルをセルフホストするには、どの程度の GPU が必要ですか。
q4 ビルドは約 2.5 GB、bf16 ビルドは約 8 GB です。そのため、モデルは 24 GB のカードに十分な余裕を残して収まります。より小容量のカードでも動作し、損益分岐点の計算は有利になります。ツールスキーマフィルターには GPU は不要です。BAAI/bge-small-en-v1.5 という 130 MB の埋め込みモデルを使用し、CPU で動作します。通常の VPS に paritok[toolselect] をインストールすれば、少量の RAM だけでツールブロックを削減できます。
コンプレッサーがエージェントに必要なものを削除した場合、どうなりますか。
何も削除されません。圧縮されたセグメントには [REF:id] タグが付加され、モデルは read_original または expand_context を使用して全文を復元します。フィルタリングされたツールスキーマは削除されず、スタブ化されます。モデルは gateway_search_tools を使用して復元します。実際のリスクは、ファイルが欠落する場合より気付きにくいものです。モデルが情報の欠落した要約を基に処理し、元の内容を要求すべきだと認識しない可能性があります。SWE-bench Lite での 86.5% という品質保持率は、この点を測定しています。
最初のリクエストに 15 秒かかるのはなぜですか。
ツールフィルターの基盤となる埋め込みモデルは、起動時ではなく最初のリクエスト時に読み込まれます。プロジェクトでは、ウォームアップに 10 から 15 秒かかり、その後は 1 回の呼び出しあたり約 15 ms になると説明しています。プロキシの起動後に curl を付けた使い捨てのリクエストを 1 回送信すれば、最初の実際のエージェントターンで処理が停止することはありません。
セルフホストではなく、ホスト型 GPU サーバーを使用すべきですか。
GPU のレンタル費用と保守作業をなくせます。2026 年 8 月時点の料金は、処理したトークン 100 万個あたり $0.30 です。一方で、プロンプトとエージェントが読み取るファイルは、モデルプロバイダーに到達する前に第三者へ送信されます。管理下のインフラストラクチャにコードを保持するためにセルフホストしている場合、この設定はセルフホストを始めた理由を失わせます。セルフホストでは、コンテキストとプロバイダーの API key の両方を自分のサーバーに保持できます。