RTK（Rust Token Killer）がAIコーディングのトークンコストを最大60%削減できるという広く共有されている主張——Xで313,000回の閲覧を記録した——は、体系的なベンチマークの下で揺らない。QuesmaはRTK 0.45.0をTerminal-Bench 2.1でテストした。これはターミナル操作に重点を置いたベンチマークで、AnthropicのFable 5.0を使用するClaude Codeと、OpenRouter経由でDeepSeek V4 Pro 0813を使用するOpenCodeの合計1,740回の試行を実施した。2026年9月11日に公開された結果によると、ターミナル出力を圧縮しても最終請求額を減らすのは稀で、むしろ増やすことがある。
このスクリーンショットは、313,000回の閲覧を記録した「RTKがAIコーディングコストを大幅に削減する」という広く広まった主張の出典の1つを捉えている。Quesmaは、Terminal-Bench 2.1での体系的なベンチマークで、実際の請求データに対してこの主張を検証するために設計された。
### RTKの仕組みと実際に影響する範囲
RTKはシェルコマンド（Claude CodeのBash、OpenCodeのbash）を傍受し、簡潔な出力を返す。例えば、`ls -la`は通常、所有者、日付、権限を表示するが、RTKは権限、ファイル名、サイズのみを保持する。しかし、RTKはシェルコマンドの書き換えにのみ作用する。両プラットフォームはファイルの読み取りや検索をRead、Grep、Globなどの個別ツールとして公開しており、RTKを完全に回避する。Claude CodeのBash呼び出しの約半数は既に`head`、`tail`、`wc`で自身の出力を制限している。
ベンチマークチャートは、RTKが報告する89%のトークン削減が、1,740回の試行にわたってFable 5.0とDeepSeek V4 Proで無視できるか否定的なコスト節紡に翻訳される様子を視覚化している。Fableは総コスト5%の削減を示し、DeepSeekは5%のコスト増を示している。
### 主な数値
85のFableタスクと89のDeepSeekタスク（各々5回の試行、RTKありとなし）を対象に:
- **Fable 5.0**：RTK使用時、総コストが5%削減（596ドル → 546ドル）、合格率が1%低下（84% → 83%）。 - **DeepSeek V4 Pro**：RTK使用時、総コストが5%増加（26ドル → 31ドル）、合格率が2%低下（71% → 69%）。
コストを合格を得られた回に換算すると（失敗を考慮）、FableはRTKで3%安く、DeepSeekは7%高くなった。しかし、すべての試行をプールするのではなく、各タスクのコスト変化を平均するタスクレベルの測定では、話が異なってくる：Fableは1%高くなった（ゼロとの差は明確ではない）、DeepSeekのタスクコストは平均で**17%上昇**した。さらに、DeepSeekの36タスクすべての10回の試行が合格したケースでも、18%の上昇が続いた。
### Fableの節約のほとんどは1つのタスクから
Fableの節約のほとんどは`winning-avg-corewars`という1つのタスクから来ていた。どちらの設定でもすべての試行を合格したが、RTKは約半分のターン数で終了した。残り84タスクでは、節約は1%未満だった。DeepSeekは同じタスクで逆の結果を示した：RTKはより多くのターンを要し、コストも高くなった。そのタスクを除外すると、DeepSeekのコストはRTKで高くなった。
### `rtk gain`指標はコスト指標ではない
RTKは`rtk gain`を「生のコマンド出力からフィルタ処理後の出力を減算したバイト数を4で割った値」としており、請求対象トークンではない。445回のDeepSeek RTK試行の中で、RTKは「349.2Mトークン節約」（89%削渡）を報告した。それにもかかわらず、タスクはより高価になった。
この指標は、エージェントが決して確認できなかった出力に対しても節約を帰することがある。`train-fasttext`タスクでは、モデルは`head -1 train.txt`を2回実行した。RTKは、これらの限定的な読み取りを全ファイルと比較して、それぞれ120.5Mトークンの節約を計算した。これは実行の9%の節約のうち69%を占めており、コマンドは決して全ファイルを返すことはなかった。また、`rtk gain`は圧縮によって引き起こされる余分なターンのコストを無視する。
### バグはコストを増す
あるDeepSeekの`git-multibranch`試行では、エージェントが`rtk find`0.45.0でサポートされていないフラグを指定した`find`コマンドでループに陥った。プラグインはこれを`rtk find`に書き換え、「findを直接使用してください」というエラーを返した。再試行のたびに再度書き換えが行われ、約12分間で339回の連続エラーが発生した。試行は最終的に合格したが、ベースラインの約9倍のコストがかかった。RTKはこの問題を0.46.0で修正したが、Quesmaのテストは既に終了していた。
### ターミナル出力は請求額の一部に過ぎない
RTKなしの場合、ツール出力はFableの入力トークンの11%、DeepSeekの40%を占めていた。RTK実行では、Claude Codeのターミナル呼び出しの31%、OpenCodeの51%のみがRTKを使用した。残りは専用ツールや自己制限フラグでRTKを回避していた。
さらに、エージェント型コーディングでは各ターン後にコンテキストをキャッシュする。ターミナル出力の後の読み取りはほとんどキャッシュ読み取りとして扱われ、Fableでは通常入力トークンの1/10、DeepSeekでは1/30のコストである。キャッシュ読み取りはRTK実行で入力トークンの94–98%を占め、請求額の26–30%を占めていた。
DeepSeekの場合、RTKによってターミナル出力の文字数は9%減少したが、プロンプトトークンは**9%増加**した。キャッシュされていない入力は1%減少したが、キャッシュされた入力は9%増加した。モデル出力（推論を含む）はRTKの有無に関わらず請求額の56–57%を占めていた。
### 余分なターンが圧縮節約を相殆化させる
RTKによってエージェントがより多くのターンを要した場合、通常、ターン数とともにコストも上昇する。DeepSeekのRTK試行は58タスクでより多くのターンを要した。そのうち44タスクはコストが高くなった。28タスクではより少ないターンで済んだが、23タスクでコストが安くなった。平均的なDeepSeekターンはRTKで7%少ない入力を持っていたが、全体として18%多くのターンが発生した。短いターンが合計入力を少なくするとは限らなかった。1つの余分なエージェントターンは、圧縮によって節約した分よりも費用がかかる可能性がある──これもまた「トークンフレーション」問題の別形である。JetBrainsもSkillsBenchで同じパターンを観察した：RTKは低い労力ではターン数を追加し、高い労力ではコストを下げなかった。
### なぜ報告された節約と実際のコストが乖離するのか
フォンティアモデルは既にターミナルを効率的に使用している。RTKなしでFableのコンテキストのうち約7%がターミナル出力だった。モデルは`head -n`や`tail -n`といった技術を駆使している。RTKの効果は、おそらく旧世代のモデルで大きかった。今日、RTKは一般的な節約手段ではなく、ニッチな最適化である。QuesmaはRTKを一般的なコスト削減ツールとしては推奨しない。
フォローアップ研究のため、軌跡データをリクエストに応じて利用可能。Quesmaは、別のターミナル出力フィルターであるHeadroomの未来のベンチマークを計画している。