RTKトークン節約：ベンチマークから明らかになったAIコーディングにおけるコスト削減の限界

RTKはAIコーディングエージェントの一般的なコスト削減を提供しない

Rust Token Killer (RTK)は、AIエージェントに到達する前にターミナル出力をフィルタリングおよび圧縮することで、AIコーディングのコストを削減することを目的としています。しかし、Terminal-Bench 2.1における実証的なベンチマークでは、RTKが一貫して総コストを低下させないことが明らかになりました。一部のモデルでは、タスクを完了するためにエージェントがより多くのターンを必要とするため、コストが実際に増加する場合もあり、個々のプロンプトが短くなった分の節約効果が相殺される結果となっています。

ベンチマーク手法：Terminal-Bench 2.1

RTKの影響を評価するために、研究者はClaude Code（Fable 5.0）とOpenCode（DeepSeek V4 Pro 0813）を用いて、Terminal-Bench 2.1で1,740回の試行を行いました。ベンチマークは、エージェントが通常成功するタスクに焦点を当てており、コスト最適化は成功完了に限られるためです。

コストと成功率の結果

結果は、総支出にほとんど影響がないか、むしろ悪化する傾向にあります。

Claude Code (Fable 5.0): 総コストは5%低下（ベースライン$731 vs RTK使用時$698）しましたが、その大部分は1つのタスク（winning-avg-corewars）に起因しています。この外れ値を除くと、節約は1%未満でした。
OpenCode (DeepSeek V4 Pro 0813): 総コストは5%上昇（ベースライン$51 vs RTK使用時$54）しました。タスク単位の測定では、平均タスクあたりのコストは17%増加しました。

成功率はほぼ安定しており、RTKを使用した場合、Fableでは1%、DeepSeekでは2%のわずかな低下がありました。

「rtk gain」は誤解を招く指標である理由

RTKは、rtk gainと呼ばれる指標を報告しています。これは、生の出力とフィルタリング後の出力のバイト数の差を4で割った値です。これは請求対象のトークン数のカウントではなく、実際の金銭的節約を反映していません。

ベンチマークの結果から、rtk gainは極端に高額に算出されることが判明しました。たとえば、あるタスクでは、headを使用して限定的な読み取りと全体ファイルサイズを比較したため、2億4100万トークンの節約とされたものの、元のコマンドは決して全ファイルを返すことはありませんでした。rtk gainはエージェントのその後の反応や追加ターンのコストを考慮しないため、高コストの試行が最適化されたように見せかけてしまう可能性があります。

「トークンインフレ」現象：ターン数増加によるコスト上昇

1ターンの入力サイズを小さくしても、総請求額が低下するとは限りません。エージェントコーディングでは、コンテキストがしばしばキャッシュされるため、ターミナル出力の後続読み取りははるかに安価になります（Fableでは1/10、DeepSeekでは1/30）。

RTKが出力を圧縮すると、モデルが混乱したり、重要な情報を削除したりする可能性があり、「トークンインフレ」問題が発生します。エージェントは同じ結論に達するためにより多くのターンを必要とします。DeepSeekの場合、RTKの試行は58のタスクでターン数が増え、そのうち44では総コストが高くなりました。平均的なDeepSeekターンの入力は7%減少しましたが、ターン数は全体で18%増加し、結果としてコストはネットで増加しました。

技術的リスクと制限

ツール互換性の欠如とループ

RTKはシェルコマンドを書き換えますが、これによりバグが発生する可能性があります。あるベンチマーク試行では、標準のfindコマンドがサポートする特定のフラグをrtk findがサポートしていなかったため、339回の連続エラーのループに陥りました。エージェントは同じ失敗するコマンドを繰り返し実行し、ベースラインと比べてコストが9倍にまで上昇しました。

バイパス機構

RTKはシェルコマンドにのみ作用します。多くのAIコーディングプラットフォームでは、Read、Grep、Glob操作に別個のツールが使用されており、これらはRTKを完全にバイパスします。さらに、最先端のモデルはターミナル自体を効率的に利用する能力が高まっており、多くの場合、head、tail、wcなどを手動で使用して出力を制限しています。

コミュニティの知見と代替案

業界の実務者や開発者は、生の出力圧縮に対するいくつかの反論と代替案を提示しています。

"出力が期待通りでない場合、LLMはツールが壊れていると判断し、以前よりも多くのツール呼び出しを行う可能性があります… それによりトークン数が増えます。"

"私は最も安価な範囲（たとえばflash-lite）でサブエージェントを起動して、ツールの使用を要約しています。私のベンチマークでは、これしかうまくいきませんでした。"

一部のユーザーは、MavenやCargoなど、出力が一貫して冗長な特定の高 verbosity ツールではRTKがまだ有用である可能性があると指摘していますが、すべてのターミナル出力をラップすることは一般的に逆効果であると同意しています。他のユーザーは、COMMAND 2>&1 | head -c 4000などの明示的なエージェントルールを使用して、出力を制限しつつ、第三者のラッパーによるコマンドの挙動変更を避けられるよう提案しています。