著者 Paritokでエージェント料金は安くなる？仕組みと損益分岐点
Paritokはファイル読み取りやツール出力を圧縮し、プロジェクトはトークン74%削減を主張します。v1.3.0の仕組みと、導入費用を回収できる損益分岐点を計算します。
リクエストに対して Paritok が行う処理
Paritok はトークンゲートウェイです。コーディングエージェントとモデル API の間に置くプロキシで、各リクエストを圧縮してから転送します。エージェントはプロバイダーではなく http://127.0.0.1:8080 と通信します。プロキシはツールスキーマ、ファイル読み取り、ツール出力、過去のターンを書き換え、より小さいペイロードを上流へ送信し、返ってきた応答を変更せずにエージェントへ返します。
プロバイダーはプロバイダーに到着したデータ量に対して課金するため、ペイロードが小さくなれば請求額も小さくなります。これが全体の考え方です。「コンテキストがより長く維持される」という主張とは異なります。この点が、単なる整理用ツールではなく、このツールに注目する理由です。
このプロジェクトは新しいものです。最初の公開タグは 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 の費用に見合いますか？
この規模のモデルでは、24GB カードが一般的なレンタル単位です。2026年8月7日時点で、24GB の 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 つあります。モデルに 24GB は必要ありません。q4 ビルドは約 2.5GB、bf16 ビルドは約 8GB なので、より小さいカードや、別の用途ですでに稼働させている GPU ボックスを使えば、表のすべての金額が下がります。また、誰もコーディングしていない時間にインスタンスを停止することが、ここでは最大の効果を持ちます。レンタル料金を約 4 分の 1 に削減できるためです。
不利になる要因も 1 つあります。圧縮処理には実際の計算時間がかかります。4B モデルが圧縮する各トークンは、モデルが読み取ってから書き出す必要があるため、エージェントの各ターンに遅延が加わります。時間単位でレンタルするカードでは、このコストは請求書の項目ではなく待ち時間として現れます。そのため、実際に待たされるまで見落としやすい点に注意してください。
一般に、レンタル GPU の稼働時間と API トークンのどちらを使うか検討している場合は、GPU VPS と API トークンの損益分岐点で推論自体について同じ計算を行っています。
VPS で Paritok ゲートウェイを実行する
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 では、翌週には別のゲートウェイが導入され、測定した数値をどのバージョンが生成したかも記録されません。
デフォルトのバックエンドは Ollama です。モデルを取得し、プロキシが参照する短い名前を付けてください。
ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1その横に 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 は、上記の処理をまとめて行うショートカットです。モデルがなければ取得し、ポート 8080 でプロキシを起動します。エージェントを接続する前に、プロキシを確認してください。
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats/health は、"status":"ok" とバージョン文字列を含む小さな JSON オブジェクトを返します。/stats は圧縮の合計値と、プロキシ自身が推定した削減量を返します。この推定値は、プロキシが自分の処理を自己評価したものとして扱い、プロバイダーの使用量ページと照合してください。
利便性ではなくスループットを重視する場合は、vLLM でベースモデル上にアダプターを提供します。
vllm serve Qwen/Qwen3-4B-Instruct-2507 \
--enable-lora \
--lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
--port 8000Ollama は短時間で構築できます。vLLM は同時リクエストの処理に優れており、同じサーバーを複数のエージェントが共有するとすぐに差が現れます。Ollama と vLLM の実用上の違いが、どちらを選ぶかを決めるポイントになります。
ベース URL の環境変数を使用して、エージェントをプロキシに接続します。
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 を自動的に書き込みます。環境変数だけをエクスポートすると、Codex はプロバイダーへ直接接続します。その場合の兆候は、作業中に /stats カウンターがまったく変化しないことです。
リスナーは 127.0.0.1 で待ち受けさせ、0.0.0.0 では待ち受けさせないでください。プロキシはプロバイダーの API キーを上流へ転送します。そのため、インターネットから到達できるプロキシは、そのキーを直接見られなくても、発見したユーザーがキーを使って料金を発生させられるオープンリレーになります。ポートを開放するのではなく、SSH トンネルまたは VPN を使用してノート PC から接続してください。
再起動後も動作するように、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 がサービス提供元のハードウェア上で実行されます。料金は処理した 1 million tokens あたり $0.30 ですが、公式ドキュメントによると 2026 年 8 月末までは無料です。これにより、GPU の利用料金と、前述した運用作業が不要になります。
一方で、プロンプトと agent が読み取るファイルは、model provider に届く前に、あなたのマシンを離れて第三者に送信されます。Self-hosting は、まさにこの経路を避けるためのものです。この flag を設定する前に、どちらを優先するのかを決めてください。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 のトークンが実際に消費される場所では、コンテキストのどの部分が圧縮を検討するほど大きいかを確認できます。
特にツールフィルターの計算では、プロンプトキャッシュが事情を複雑にします。ツールブロックはリクエストの先頭に置かれるため、通常、1 ターン目以降は入力料金の 10% でキャッシュヒットします。キャッシュされたブロックから 21,000 トークンを削減しても、節約額は非キャッシュ料金から計算した $0.063 ではなく、100 万あたり $0.30 で計算した 1 ターンあたり約 $0.006 です。プロジェクトでは、セッション中にフィルター済みブロックを固定します。そのため、キャッシュされたプレフィックスは変化しません。ターンごとにツールを選び直すフィルターでは、このプレフィックスが無効になり、節約額を上回るコストが発生します。
未検証の点
上記のパフォーマンス数値は、すべてプロジェクト自身が示したものです。SWE-bench Lite の結果を独立して再現した例はありません。最初のタグが 2026 年 7 月付けであるため、コードの運用実績もほとんどありません。圧縮率と保持された品質の数値は、どちらも良好に見えることで利益を得る当事者が測定したものです。だからといって、誤りとは限りません。ただし、未確認の数値です。自分で測定した数値とは区別して扱うべきです。
設定を疑う前に知っておくべき、文書化された動作があります。このツールのフィルターが使用する embedding model は、起動時ではなく最初のリクエスト時に読み込まれます。そのため、プロジェクトでは 10 to 15 秒のウォームアップ時間と、その後は 1 回あたり約 15 ms の処理時間が示されています。proxy の起動後に破棄用のリクエストを 1 回送っておけば、最初の実際の agent のターンがハングしたようには見えません。
午後のうちに自分で確認できる点は 4 つあります。proxy が起動して稼働し続けるか、作業中に /stats が変化するか、provider の input-token の項目が実際に減少するか、そして agent が作業を完了できるかです。これらの結果のほうが、公開されているベンチマークよりも、あなたの環境に適用できるかどうかを正確に判断できます。
他のツールとの位置付けについては、self-hosted LiteLLM gateway がリクエストの内容を変更せずにルーティングと使用量の計測を行うため、両者は異なる問題を解決します。併用も可能で、Paritok は agent に最も近い位置に置かれます。目的がこの特定のツールではなく請求額の削減であれば、VPS 上の agent 向けの幅広いコスト管理策には、まず無料で試せる変更がいくつかあります。
FAQ
Paritok は API 料金を削減しますか。それともコンテキスト使用量だけを減らしますか。
料金を削減します。プロキシがプロバイダーに到達する前にリクエストを書き換え、プロバイダーは受信した内容に対して課金するためです。ただし、実際の削減幅は見出しの数値より小さくなります。74% という数値は、圧縮対象のコンテンツに対する圧縮率です。エンドツーエンドでは、プロジェクトの報告によると、1 ターンでは約 25%、20 ターンでは 63% です。変化するのは入力トークンだけで、出力トークンはそのまま通過します。
圧縮モデルをセルフホストするには、どの程度の GPU が必要ですか。
q4 ビルドは約 2.5 GB、bf16 ビルドは約 8 GB です。そのため、24 GB のカードなら十分な余裕を残してモデルを収められます。より小さいカードでも動作し、損益分岐点の計算は有利になります。ツールスキーマフィルターには GPU は不要です。CPU で動作する 130 MB の埋め込みモデル、BAAI/bge-small-en-v1.5 を使用します。通常の 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 キーの両方を自分のサーバー上に保持できます。