GitHub で「Claude Code のトークンを削る」と名の付くリポジトリを11本、ライセンス本文まで開いて確かめた。うち2本には、仕事で使うなら手を止めたほうがいい条件が付いていた。★が1万9千を超えているものも含まれる。この記事は、その11本が何をするツールで、どの条件で配布されているかの一覧である。
何をどう確かめたか
各リポジトリについて GitHub API で存在・スター数・最終更新・言語を取り、ライセンスは LICENSE ファイルの本文を開いて確認した。数字は2026年7月30日時点。
本文まで開いたのには理由がある。GitHub が返すライセンス欄は、11本のうち3本で `NOASSERTION`（判定不能）になっていた。3本ともルートに LICENSE ファイルは置いてある。自動判定が効かないのは、標準的なライセンス文と一致しないからで、そこに肝心な条件が入っていた。ライセンス欄が空欄や判定不能のリポジトリを「たぶん MIT だろう」で通すと事故る。
スター数の多さと、条件の緩さには関係が無い。この記事で一番伝えたいのはそこだ。
一覧
| リポジトリ | ★ | ライセンス | 役割 |
|---|---|---|---|
| JuliusBrussee/caveman | 94,371 | MIT | 返答の冗長さを削る |
| rtk-ai/rtk | 73,863 | Apache-2.0 | コマンド出力を圧縮 |
| colbymchenry/codegraph | 63,356 | MIT | コードを索引化 |
| mksglu/context-mode | 19,454 | Elastic License 2.0 | ツール出力の隔離と記憶の保持 |
| ryoppippi/ccusage 最初に入れる1本 | 17,572 | MIT | 使用量をローカルで集計 |
| Maciek-roboblog/Claude-Code-Usage-Monitor | 8,543 | MIT | 上限の残りを常時監視 |
| drona23/claude-token-efficient | 5,889 | MIT | CLAUDE.md 1枚で返答を簡潔に |
| alexgreensh/token-optimizer | 1,765 | PolyForm Noncommercial 1.0.0 | 無駄なトークンの監査 |
| JuliusBrussee/cavemem | 656 | MIT | エージェント横断の永続記憶 |
| nadimtuhin/claude-token-optimizer | 538 | MIT | 起動時の読み込みを削る |
| ooples/token-optimizer-mcp | 454 | MIT | MCP経由でキャッシュと差分返し |
削減率の数字は、以下すべて各メンテナが自分の README で主張している値として読んでほしい。筆者が測り直したものではない。自分の環境で測った数字はトークン消費を減らす実践ガイドのほうに置いてある。
コマンド出力を圧縮する
rtk（Apache-2.0）
エージェントが読む bash 出力を、届く前に絞り込む CLI プロキシ。単一の Rust バイナリで依存が無く、100以上のコマンドに対応する。README は「bash 出力の最大90%を削る」と書いている。
# Homebrew
brew install rtk
# Linux / macOS のクイックインストール（~/.local/bin に入る）
curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | shこの分類の道具は、ファイル一覧のような定型出力に強く、一点物の出力には効かない。導入するなら、自分がどのコマンドをよく叩くかを先に見ておくと期待値を外さない。
token-optimizer-mcp（MIT）
ローカルで動く MCP サーバとして、大きなデータをキャッシュし、同じファイルを読み直したときは差分だけを返す。ノイズの多いコマンド出力を絞り、最適化の結果を毎回記録する作りになっている。README は95%以上の削減を掲げる。
MCP サーバとして常駐する形なので、Claude Code 以外（Codex・Cursor）でも同じ効き方をする。逆に言えば、MCP を1本増やすことになる。
context-mode（Elastic License 2.0）
問題設定が具体的で参考になる。README は「Playwright のスナップショットが56KB、GitHub の issue 20件で59KB、アクセスログ1本で45KB。30分で文脈の40%が消える」と書く。MCP ツールの戻り値を隔離し、さらに要約で失われがちなもの（編集中のファイル、進行中のタスク、直前の指示）をセッションを越えて保持する。17のプラットフォームに対応する。
ライセンスが Elastic License 2.0 である点に注意が必要。後述する。
返答そのものを短くする
caveman（MIT）
★9万4千。エージェントの返答から埋草を落とし、原始人のような詰まった言い方で答えさせるスキル。コード・コマンド・エラーはバイト単位でそのまま保つ設計になっている。README は「同じ答えで出力トークン65%減」と主張する。Claude Code のほか30以上のエージェントに対応し、強度も段階で選べる。
この分類の副作用は分かりやすい。短くなった返答はそのまま会話履歴になり、次のターン以降の入力になる。削った履歴の上で続きを考えさせるので、後半の回答品質に響く可能性がある。長い一本の作業より、短い依頼の連続と相性がいい。
claude-token-efficient（MIT）
CLAUDE.md を1枚置くだけで返答を簡潔に保つという、いちばん軽い手当て。コード変更は要らない。
好感を持ったのは、README が自分の弱点を先に書いていることだ。「指示ファイルは毎ターン入力トークンを増やす。短く保つこと。膨らみすぎると節約より高くつく」と明記してある。ベンチマークは Claude でしか取っていないこと、ローカルモデルでの結果は未検証であることも書いてある。この種のツールを見るときは、この手の但し書きがあるかどうかが判断材料になる。
文脈を作り直させない
codegraph（MIT）
コードベースを事前に索引化して知識グラフにし、コード変更で自動同期する。Rust のカーネルで、完全にローカルで動く。Claude Code のほか Codex・Cursor・Gemini・OpenCode などから引ける。
grep で候補ファイルを次々に開く動きを、定義への1回のジャンプに置き換える発想。トレードオフは真実の源が2つになることで、索引と実体がずれると、ずれた索引を信じて自信満々に間違える。
cavemem（MIT）
caveman と同じ作者による、エージェント横断の永続記憶。セッションの境目でフックが動き、観測した内容を caveman 文法で圧縮して保存する（散文部分で約75%減とされる）。要約で記憶が飛ぶ問題に、外部保存で対処する系統だ。
claude-token-optimizer（MIT）
起動時の読み込みを削ることに絞ったツール。README の動機が具体的で、「RedwoodJS のプロジェクトで、コードを書き始める前に11,000トークンを焼いていた。1,783行のドキュメントと古いセッションメモと完了済みタスクの履歴だった」と書いてある。
この数字は、固定費を削る話の分かりやすい実例になっている。何も打っていない時点で消えているものは、測らないと見えない。
測る
ccusage（MIT）
ローカルに残るセッションログを読んで、日次・週次・月次・セッション別のレポートを出す。データを外に送らない。Claude Code だけでなく Codex や OpenCode のログも読める。
# インストール不要で実行できる
npx ccusage@latest
# エージェント別に絞る
npx ccusage@latest claude daily
npx ccusage@latest codex daily11本のうち最初に入れるならこれを推す。理由は単純で、読み取り専用で副作用が無いから。削る前に測るという順番を守れる唯一の分類でもある。
Claude-Code-Usage-Monitor（MIT）
ターミナルに常駐して、上限に当たる前に警告を出す。公式の statusline の rate_limits を読み、機械可読な出力、予測、任意で有効にするローカルの使用量倉庫を備える。プライバシー優先を掲げている。
# uv（推奨）
uv tool install claude-monitor
# pip
pip install claude-monitorサブスクの枠で作業が止まるのが困る人向け。請求額を見たい人には ccusage のほうが向く。
token-optimizer（PolyForm Noncommercial 1.0.0）
フックで背景に常駐し、無駄になっているトークンを監査してダッシュボードに出す。主張が挑発的で、「出力圧縮は文脈の15〜25%しかカバーしない」と書いて、rtk のような圧縮系との違いを説明している。
商用利用は許されていない。後述する。
ライセンスの落とし穴
ここが本題。11本のうち9本は MIT か Apache-2.0 で、商用でも社内でも普通に使える。残る2本は条件が違う。
| ツール | ライセンス | 読者に効いてくる条件 |
|---|---|---|
| context-mode | Elastic License 2.0 | ソースは読めるが、OSI の定義でのオープンソースではない。ELv2 は「ソフトウェアをマネージドサービスとして第三者に提供すること」と「ライセンスキー機能の回避」を禁じる。社内の開発で使うぶんには通常あたるものが無いが、自社サービスに組み込んで顧客に提供する形は禁止側に入りうる |
| token-optimizer | PolyForm Noncommercial 1.0.0 | 非商用の目的しか許可されていない。研究・実験・個人利用は permitted purpose に入るが、受託開発や勤務先の業務で使うのは範囲外になる。加えて配布時は「Required Notice」の行を一緒に渡す義務がある |
どちらも作者の正当な選択で、悪いことではない。問題になるのは、読者が MIT だと思い込んで仕事に入れてしまうことのほうだ。GitHub のライセンス欄が判定不能だったのはこの2本を含む3本で、UI を眺めただけでは条件が見えなかった。
導入前にやることは1つ。リポジトリの LICENSE を開いて1行目を読む。それで足りる。「Elastic」「PolyForm」「Commons Clause」「Business Source」あたりの単語が出たら、その先を読む価値がある。
選び方：筆者の判断
11本を並べたが、全部入れる話ではない。複雑さもコストで、道具を足すほど壊れる場所が増える。順番として推すのはこうだ。
まず ccusage で測る。読み取り専用なので、外して困ることが無い。ここで自分の消費の内訳が出る。
次に、測った結果が指している分類のものだけを1つ入れる。定型コマンドの出力が重いなら圧縮系（rtk）、起動時点の固定費が重いなら読み込みを削る系、コード探索が重いなら索引化（codegraph）。返答短縮系（caveman）は効果が分かりやすい反面、履歴の質に影響するので、入れたあとに回答の質を見張れる状況で試すのがいい。
筆者自身の構成と、その実測値はClaude Codeのトークン消費を減らす実践ガイドに書いた。そちらでは、公式ドキュメントで裏を取った削減策（MCP の遅延読み込み、プロンプトキャッシュ、effort の落とし穴）と、道具を足す前にやるべき手当ての順番を扱っている。ツールを選ぶ前に、そちらを先に読んでもらうほうが得だと思う。
最後に1つ。この記事のスター数とライセンスは2026年7月30日時点の実測値で、ライセンスは変わることがある。仕事に入れる前には、その時点の LICENSE を自分で開いてほしい。
