この記事の結論（3文）
Claude Codeのトークンは「出力」「入力」「ツール出力（MCP等）」「セッション記憶」の4箇所で食われており、
10本のOSSはだいたいこのどれか1箇所を刈りにいく道具です。
公表削減率が派手な順に並べると、
context-mode 98%・Token Savior 97%・RTK 89%・Caveman 65%あたりが今のトップ集団。
ただし全部レイヤーが違うので、
数字を足してはいけません。
本記事は10本を4レイヤーに並べ直し、
公表値・GitHubスター・出典URL・効きどころを1枚の表にまとめた地図です。
単独ツールの使い方説明ではありません。
Max x20が1時間で枯れた、
$40/日のAPI請求が来た。
ここ1ヶ月、
X上でそういう悲鳴が目に見えて増えました。
The Registerが2026年3月31日付で報じたクォータ枯渇問題（出典）では、
Max 5xユーザーが「以前は8時間使えた枠が1時間で枯渇」と証言しています。
同時期に、
海外OSS界隈では「Claude Codeのトークンを刈る」専用ツールがほぼ毎週リリースされるようになりました。
Caveman 41,300★、
RTK 31,200★、
context-mode 8,500★。
数字だけ見ると派手ですが、
どれか1本だけ入れても効きどころがズレてると空振りします。
私は10本を「出力」「入力」「MCP/ツール出力」「セッション記憶」の4レイヤーに並べ直して読みました。
個人的にはこの地図が無いと選べない。
以下、
公表値・出典URL付きで並べます。
Claude Codeトークン削減ツール10選 比較マトリクス
まず一枚表から。
各数字は各プロジェクトの公式README／著者ブログ／第三者実測記事に記載された「公表値」であり、
私の実測ではありません。
出典URLは各ツール節で明示します。
| ツール | レイヤー | 公表削減率 | ★ | 主な効きどころ |
|---|---|---|---|---|
| Caveman | 出力削減 | 平均65%・最大75% | 41,300 | Claudeの返答テキストそのものを電報体化 |
| RTK | 入力圧縮（CLI出力） | 60〜90%・実測89% | 31,200 | cargo test等のターミナル出力をフックで圧縮 |
| Token Savior | 入力圧縮（コード） | 97%（170+セッション） | 559 | コードをシンボル化、ファイル全文読み込みを廃止 |
| context-mode | MCP/ツール出力 | 98%（出力）・94%（全体） | 8,500 | MCPツール戻り値をSQLiteにサンドボックス化 |
| Headroom | 入力圧縮（API前段） | 「使用量2倍」・100ログ87% | 1,500 | AST＋ML圧縮レイヤーをAPI前に挟む |
| claude-token-optimizer | 入力削減（設計） | 90%（RedwoodJS単一事例） | 196 | CLAUDE.md周辺の自動読込設計を刈り込む |
| Token Optimizer MCP | MCP層 | 「95%+」（測定根拠非公開） | 219 | MCPキャッシュ＋圧縮＋スマート選択 |
| MCP-Memory-Service | セッション記憶 | v10系は記載なし（旧v8.19が75〜90%） | 1,700 | セッション横断の記憶保存＋ハイブリッド検索 |
| token-reducer | 入力圧縮（RAG） | 「90〜98%」（根拠非公開） | 13 | BM25＋ベクター＋AST＋TextRank |
| Token Optimizer（ghost） | セッション管理 | ghost tokensが75〜85%を占有と主張 | 554 | 未使用スキル・孤立メモリの除去＋閾値コンパクション |
この表、
眺めるだけで結構示唆があります。
削減率が大きい順に並べても、
レイヤーが全部バラバラ。
ここ一番大事。
どのレイヤーでトークンが食われているのか
Anthropic公式の「Claude Codeコスト管理」ページ（出典）は、
主要な消費源として4つを挙げています。
MCPサーバー定義のオーバーヘッド、
ファイル全文の読み込み、
CLIコマンドの全出力、
会話履歴の蓄積。
Hacker Newsの分析（出典）では、
プログラミングタスクの内訳は「入力93.4%・推論2.5%・出力4.0%」。
この数字を見ると、
出力だけ削っても全体は動かないという話になります。
ここがCaveman問題の核心です。
つまり4レイヤーの分担はこう整理できます。
- 出力レイヤー: Claudeの返答テキスト（全体の約4%）→ Caveman、claude-token-efficient
- 入力レイヤー: ファイル読み込み・CLAUDE.md（全体の約93%のうち人間側で作るプロンプト）→ claude-token-optimizer、Headroom、Token Savior、token-reducer
- ツール出力レイヤー: Bash/MCPの戻り値（全体の約93%のうち機械が生成して注入する部分）→ RTK、context-mode、Token Optimizer MCP
- セッション記憶レイヤー: 会話履歴・ghost tokens → MCP-Memory-Service、Token Optimizer（ghost）
Jenny Ouyang氏のレポート（出典）では「Claudeに読ませたファイルはすべてセッション中コンテキストに恒久的に積み上がる」として、
これが$1,600の請求につながったと書かれています。
同レポートは入力とツール出力の2レイヤーに手を入れない限り体感は動かないと示唆しており、
全体の93%がこの2箇所に集中している数字と符合します。
Caveman: 出力レイヤーの定番・ただし全体効果は限定的
Cavemanは16歳のJulius Brussee氏が作ったCLAUDE.md方言集。
Claudeに「洞窟人みたいに話せ」と指示して返答テキストを圧縮する仕組みです。
GitHub公式READMEのベンチマーク表（出典）から数字を引きます。
10タスク平均: 1,214 → 294 トークン/レスポンス（65%削減）
最大: Reactレンダリングバグ説明 1,180 → 159 トークン（87%削減）
PostgreSQLセットアップ: 2,347 → 380 トークン（84%削減）— Caveman GitHub README
Redditでは「洞窟人話法で75%削減」投稿が10,000アップボート・400コメント、
Decrypt記事（出典）でも広く報じられました。
導入は5分。
ここから先が大事な話です。
Decryptの同記事内の分析では、
「実世界の節約は実際には全セッションの約4%程度」とも書かれています。
前段で見たとおり、
出力はそもそも全体の4%。
出力を65%削ると、
全体では4%×65%＝約2.6%の節約、
という計算です。
Nathan Onn氏のレビュー（出典）も「学習・アーキテクチャ議論・顧客向け生成には不向き」と明確に線引きしています。
私の見方だと、
Cavemanは「財布が痛いから入れる」ツールではなく「返答がうるさいから黙らせる」ツールです。
節約の主力として期待すると肩透かしになります。
RTK: ターミナル出力を刈る、実測89%の本命
Rust Token Killer（RTK）はCLIプロキシ型。
Claude CodeのPreToolUseフックでBashコマンドを傍受し、
Rust製バイナリ（<10msオーバーヘッド）でsmart filtering・grouping・truncation・deduplicationを効かせます。
入り口が93%の入力レイヤーのうち「機械が吐き出す部分」をダイレクトに狙うツール。
KiloCodeのDiscussion #5848（出典）でユーザーmuskiness氏が公表した数字がインパクト大。
2週間で約1,000万トークン削減（89%）。
cargo test: 155行 → 3行（98%）、
git status: 119文字 → 28文字（76%）。— KiloCode Discussion #5848
zerotopete.com の実測記事（出典）では、
cargo test 約4,800トークン→11トークン、
git diff 約21,500→1,259トークンと書かれています。
公式30分セッションデモは約118,000→約23,900トークン（約80%削減）。
Shidhin氏のXポスト（出典）もこの本質を突いています。
Claude Codeセッションが89%のトークンを浪費している。
プロンプトではない、
生のターミナル出力がコンテキストに突っ込まれているのが原因だ。— @shidhincr
対応エディタはClaude Code、
Cursor、
Gemini CLI、
Aider、
Codex、
Windsurf、
Cline。
公式READMEは「実測値はプロジェクトサイズに依存、
中規模TypeScript/Rustプロジェクト想定」と注記しています。
これは正直ありがたい注記。
万能じゃないと先に言ってくれる姿勢が好感持てます。
Token Savior: ファイル全文読み込みをシンボルに置換
Token Saviorは入力レイヤーの「人間が指示した読み込み」側を刈るツール。
105言語のコードをSQLiteにインデックス化し、
Claudeが `find_symbol()` や `get_backward_slice()` でポインタナビゲートできるようにします。
公式README（出典）のベンチマーク値。
find_symbol(): 4,100万文字 → 67文字（-99.9%）
get_backward_slice(): 130行 → 12行（-92%）
60タスクフルベンチマーク: 143万文字 → 21.6万文字（-85%）— Token Savior GitHub README
内部はSQLite WAL + FTS5 + sqlite-vec のハイブリッド。
BM25とベクター（all-MiniLM-L6-v2 384次元）をRRFで融合し、
TTLは「0.4×最近性 + 0.3×アクセス頻度 + 0.3×タイプ加重」。
v2.6.0は2026年4月20日リリース。
これ、地味にやばい構成。
Jenny Ouyang氏の「読ませたファイルは全部コンテキストに積み上がる」問題（前述）に対する、
もっとも根本的な対処がこの方向性です。
context-mode: MCPツール出力をサンドボックス化する新世代
Mert Köseoğlu氏のcontext-modeは、
MCPツール呼び出しの戻り値をそのままコンテキストに注入せず、
SQLite+FTS5にサンドボックス化してBM25検索で必要行だけ返す仕組み。
著者ブログ（出典）の記述が核心を突いています。
誰もが「生データをコンテキストに投げ込むツール」を作っていた。
出力側を解決する人間がいなかった。— Mert Köseoğlu（context-mode著者）
公式READMEの数字（出典）がえげつない。
Playwrightスナップショット: 56.2KB → 299B（99%削減）
GitHubイシュー20件: 58.9KB → 1.1KB（98%削減）
アクセスログ: 45.1KB → 155B（100%削減）
30分で壁に当たっていたセッションが、同じ200Kトークンで3時間走るようになった。— context-mode README / 著者ブログ
著者Xポスト（出典）では全体94%削減と公表。
6つのサンドボックスツール（ctx_execute / ctx_batch_execute / ctx_execute_file / ctx_index / ctx_search / ctx_fetch_and_index）で11言語対応。
対応は12プラットフォーム（Claude Code・Gemini CLI・VS Code Copilot・Cursor・OpenCode・Codex CLI・Kiro他）。
v1.0.89は2026年4月14日。
ひとつ注意点。
ライセンスはElastic License 2.0（ソースアバイラブル）で、
自社SaaSに組み込んで利用する分は許可範囲。
禁止されるのは「context-mode自体をマネージドサービスとして他者に再販する」ケースだけです。
残り6本：短く並べる（Headroom／claude-token-optimizer／Token Optimizer MCP／MCP-Memory-Service／token-reducer／Token Optimizer）
残り6本は粒度を落とします。
トップ4ほどの実測厚みは各READMEに無いので、
公表値と仕組みだけ拾います。
| ツール | 仕組みの一行 | 最新ver | 出典 |
|---|---|---|---|
| Headroom | API前段に挟む圧縮レイヤー。AST圧縮（CodeCompressor）+ JSON圧縮 + ML圧縮（Kompress-base）。100ログ中FATAL 1件の検索で10,144→1,260トークン（87%）、GSM8K精度維持を公表 | v0.8.2（2026/4/21） | GitHub |
| claude-token-optimizer | CLAUDE.md周辺の「自動読み込みファイル設計」を刈り込むテンプレ。RedwoodJSでドキュメント11,000→800トークン（約93%）。汎用保証ではない単一事例 | — | GitHub |
| Token Optimizer MCP（ooples） | MCPサーバーとしてキャッシュ＋圧縮＋スマートツール選択。公表「95%+」。測定根拠がREADMEに公開されていない点は明示しておきたい | 31リリース | GitHub |
| MCP-Memory-Service（doobidoo） | REST API 15エンドポイントでセッション横断記憶。ローカルONNXエンベディング＋BM25＋ベクター＋ナレッジグラフ（causes/fixes/contradicts）。v10.39.1では「75〜90%」表記なし（旧v8.19時点の公表値） | v10.39.1（2026/4/20） | GitHub |
| token-reducer（Madhan） | ローカル完結のRAGパイプライン。BM25＋ベクター＋Tree-sitter AST＋TextRank。スター13・コミット24で採用実績は限定的。公表「90〜98%」の根拠詳細は非公開 | v1.4.0 | GitHub |
| Token Optimizer（alexgreensh・ghost tokens） | 「ghost tokensが75〜85%のコンテキストを占める」と主張し、未使用スキル・孤立メモリ・重複を除去。20/35/50/65/80%の充填閾値でプログレッシブコンパクション | v5.5.1（2026/4/21） | GitHub |
補足。
token-reducerはスター13・コミット24で、
他の6本と同列に扱うのは公平じゃない気もしますが、
アーキテクチャ（BM25+ベクター+AST+TextRank）としては面白いので名前だけ拾っています。
Token Optimizer MCPの「95%+」も、
他ツールのように測定条件が公開されていないため、
表では括弧付きで扱いました。
4箇所を同時に刈る：組み合わせは可能か
doobidoo氏のGist（出典）が、
実用レベルで一番まとまった検討資料です。
6層スタック（RTK + context-mode + MCPlex + Caveman + Context-Provider + Memory-Service）で1時間セッション合計約58,500トークン削減、
約58%削減と試算。
削減率の単純加算は罠です。
Caveman 65%＋RTK 89%＋Token Savior 97%＝251%引けるわけではない。
同じレイヤーを刈り合うケース（例えばclaude-token-optimizer と Token Savior）は食い合って伸びません。
組み合わせの鉄則はこうなります。
- レイヤーが違えば独立して効く（Caveman×RTK×context-mode×MCP-Memory-Service）
- 同じレイヤーは食い合うので1本に絞る（Token Savior と claude-token-optimizer は同時運用しない）
- 合計値は「各レイヤー1本ずつ足し上げた doobidoo Gist の58%」が現実的な天井の目安
Pasquale Pillitteri氏のまとめ（出典）でも、
.claudeignore＋7つの運用対策で「50〜60%のクォータ削減」が現実的レンジと報告されています。
doobidoo氏の試算と符合。
導入優先順位：どこから手を付けるか
私の見方だと、ヘビーユーザーが今日から進めるならこの順番です。
- Anthropic公式の基本運用 — `/clear`・`/compact`・CLAUDE.md 200行以下・subagents分離。無料かつ効果デカい（公式出典）
- RTK — ツール出力レイヤーは全体93%の一部を占めるので効きどころがデカい。Rustバイナリ5分インストール
- context-mode — MCPツールを多用するならRTKより優先してもいい。ライセンス確認だけ必要
- Token Savior — ファイル全文読み込みが習慣化している人はここで大きく動く
- Caveman — 「返答がうるさい」体感を消したいなら入れる。節約額には過剰期待しない
- MCP-Memory-Service または Token Optimizer（ghost） — セッションを跨ぐ開発運用ならここ
Cavemanを1番目に入れたくなる気持ちはわかるんですが、
全体の4%レイヤーから始めると「入れたのに請求が変わらない」という感想になりがち。
入力とツール出力から潰すのが合理的です。
キャッシュと公式機能：ツール入れる前の土台
Anthropic公式のプロンプトキャッシング（出典）だけで、
キャッシュ読み取りは通常単価の0.1倍。
Sonnet 4.6 で $3/MTok → $0.30/MTok、
Opus 4.7 で $5/MTok → $0.50/MTok。
ただしThe Register 同記事によれば、
2026年3月に「10〜20倍のトークンコスト増加を引き起こすキャッシュ関連バグ」がユーザーによって特定されました。
Anthropicは「Extra Usage有効時はキャッシュTTLが60分→5分に短縮」と説明。
ここもユーザー側で設定を見直す余地があります。
公式Compaction（出典）もbeta中ですが、
1Mコンテキスト使用時は約83.5%でコンパクション発動、
バッファ約33Kトークン確保。
`/compact Focus on the API changes` のようにカスタム指示を付けられるので、
OSSツールを足す前にこの挙動を把握しておいたほうが建設的です。
批判・限界：ツール入れれば万事解決にはならない
Hacker Newsの長いスレ（出典）は、
この手のツール全体に対する冷めた指摘が並んでいて参考になります。
「Answer is always line 1」のような指示は自己回帰モデルの動作原理に反する。モデルが誤った方向に早期コミットする。
Anthropicは出力のデフォルトを最適化するインセンティブがある。Claudeに統合されていない機能は、おそらく性能を改善しない。— Hacker News コメント
Nathan Onn氏もCavemanについて「顧客向けアプリケーション」「ニュアンスが必要なコンテンツ」「学習コンテキスト」では不向きと明言しています。
正確性・丁寧さが必要な場面で切り替えるためのスイッチ設計（セッション単位・プロジェクト単位のON/OFF）はどのツールにも欲しい機能です。
そしてこれ一番重要。
出力削減を狙った結果、
入力のCLAUDE.mdが肥大してトータルで損をするケースがHNで複数報告されています。
200行目標は公式ベストプラクティスの数字ですが、
実運用ではもっと刈り込むくらいでちょうど良さそうです。
FAQ
Q. Claude Code Max x20で$200/月なのに、さらにツール入れる価値ある？
A. Max x20は5時間ウィンドウで約220,000トークン。
The Register の報道にあるように「想定より速く枯渇」するケースが実在します。
RTK実測89%・context-mode 94%のレイヤーでトークンが食われているなら、
ツール導入で5時間の作業時間を実質的に延ばせる可能性があります。
課金額を下げる目的より「枠を使い切らない」目的で見ると費用対効果が出しやすいです。
Q. 削減率を足し算して「99%削れます」と書いていいですか？
A. 書くと信頼を失います。
doobidoo氏の6層スタック試算でも合計約58%。
レイヤーが違うツールを組み合わせても、
同じトークンを二重に数えることになるので単純加算は成立しません。
各ツール単位の公表値は併記、
合算は1時間セッションで50〜60%が現実ライン、
と整理するのが安全です。
Q. Cavemanだけ入れればとりあえず効果ありますか？
A. 出力レイヤーは全体の約4%なので、
Cavemanの65%削減は全体では約2.6%の影響にとどまるという計算がDecrypt記事で示されています。
「返答がうるさい」「礼儀的な前置きが鬱陶しい」問題には効きますが、
請求額や枠消費への影響を期待するならRTK・context-mode・Token Saviorのほうが桁が違います。
Q. OSSでない（Elastic License 2.0）context-modeを業務で使っていい？
A. Elastic License 2.0で禁止されているのは「context-mode自体をマネージドサービスとして他者に再販する」ケースだけです。
自社SaaSに組み込んで使う、
社内の開発支援に入れる、
個人プロジェクトで使う、
いずれも許可範囲内。
SaaS同梱も問題ありません。
商用の懸念があるのは「context-modeをラップして別社向けに売る」事業をやるときだけです。
Q. Token Optimizer MCP と token-reducer が「95%+」「90〜98%」と公表しているのは信じていい数字ですか？
A. 両者とも測定条件・ベンチマーク手法がREADMEに記載されていません。
token-reducerはスター13・コミット24で採用実績も薄い段階。
公表値として並べる価値はありますが、
「数字の比較対象」として Caveman 65%（10タスク実測）・RTK 89%（2週間1,000万トークン実測）と同列には並べられない、
と理解しておくのが無難です。
参考リンク
- Anthropic公式: Claude Codeコスト管理 / ベストプラクティス / Compaction / プロンプトキャッシング
- 第三者実測・分析: The Register（クォータ枯渇） / Decrypt（Caveman分析） / zerotopete（RTK実測） / context-mode著者ブログ / Nathan Onn（Caveman実測） / buildtolaunch（$1,600請求の原因） / Pasquale Pillitteri（7 Mistakes） / Hacker News批判スレ
- コミュニティ声: KiloCode Discussion（RTK 89%実測） / doobidoo 6層スタックGist / dev.to 9 Verified Tools
※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。