RTK端末出力圧縮ツールの大規模ベンチマークでは、コーディングエージェントに表示されるテキストを削減しても、ソフトウェア作業を完了する費用が一貫して下がるわけではないことが判明した。この結果は、表示出力の劇的な削減が、モデルのトークン数や料金の同程度に劇的な節約へ直接つながるという主張に疑問を投げかけている。

Quesmaは、Terminal-Bench 2.1上で、Fable 5.0を実行するClaude Codeと、DeepSeek V4 Pro 0813を実行するOpenCodeを使ってRTKをテストした。各タスクは、同じルートと制限時間の下、RTKありで5回、なしで5回試行された。拒否応答を引き起こした4タスクを除外した後、比較対象はFableの85タスクとDeepSeekの89タスク、計1740回の試行となった。

総費用では、Fableの試行はRTK使用時に5%安くなった一方、DeepSeekの試行は5%高くなった。合格率もわずかに低下し、Fableは1ポイント、DeepSeekは2ポイント下がった。Quesmaが総支出を成功した完了件数で割ると、ツールを有効にした場合、Fableは3%安く、DeepSeekは7%高くなった。

タスク加重分析では、より不利な結果となった。Fableは約1%高くなったが、ゼロとの差は明確ではなかった一方、DeepSeekのタスク平均費用は17%増加した。Fableで見られた節約の大半は、RTKを使うとターン数が約半分で完了した1件のタスクによるものだった。そのタスクを除外すると、残る作業全体の節約率は1%未満に低下した。

RTKの内部カウンターと請求対象の使用量との差は、特に顕著だった。DeepSeekの445回の試行全体で、RTKは3億4920万トークン、率にして89%を削減したと報告した。しかし、このカウンターは未加工バイトとフィルター処理後のバイトを比較して、削除されたコマンド出力を推計するもので、請求対象トークンを測定せず、その後のエージェントのターンの変化も考慮しない。ある例では、出力を限定したファイル読み取りコマンドをファイル全体と比較したため、元のコマンドが完全な内容を返すことは決してなかったにもかかわらず、推定節約量が非常に大きくなった。

圧縮はエージェントの動作も変え得る。DeepSeekのある実行では、RTKが未対応のオプションを使ってコマンドを書き換えた後、長いエラーループに陥った。この問題は後のRTKリリースで修正されたが、その試行の費用は対応するベースラインの約9倍になった。Quesmaは、この外れ値を除外しても、より広範な傾向は変わらなかったと述べた。

キャッシュとツール設計も、シェル出力が短くなれば必ず請求額が下がるという前提をさらに弱める。端末コンテキストの多くは、割引されたキャッシュ料金で再度読み込まれる。また、コーディングプラットフォームは、シェル出力の書き換えを迂回するファイル読み取りツールや検索ツールを提供することが多い。エージェントも一般的に、head、tail、wcなどのコマンドを使って自ら出力を制限する。

Quesmaは、RTKが特定のワークロードに役立つ可能性はあるものの、一般的なコスト削減レイヤーとして扱うべきではないと結論付けた。このベンチマークは、チームが圧縮カウンターだけに依存せず、タスク全体の費用、完了品質、ターン数を評価すべきだと示唆している。