Token Meter：コーディングエージェント用のリアルタイムのコストメーター

Claude Codeでリファクタリングを開始し、コーヒーを淹れに行ったとしましょう。10分後もまだ処理は続いていますが、この処理にかかる費用が1ドルなのか100ドルなのか見当もつきません。

このギャップを解消するために開発したのがToken Meterです。このツールは、エージェントがディスクに書き出した既存のトレースファイルを読み込み、モデルの公開されている料金表に基づいて金額を算出して表示します。そのため、請求書が届いたりマネージャーから連絡が来たりする前にコストを把握できます。ツールはメニューバーに常駐します。利用にはAPIキーもアカウントも不要で、データが外部に送信されることもありません。

自分自身の業務で3カ月間使用したところ、コードの品質を落とすことなく、1週間のエージェントコストを約3分の1削減できました。コスト削減の大部分は、このツールによって明らかになった3つの習慣、つまり、無駄なセッションを終了すること、定型作業をより安価なモデルに振り分けること、不要なツールを無効にすることによる効果です。(まさしく「少ないことは、豊かなこと」というわけです。)

ブラウザベースのダッシュボードに加えて、OSごとのネイティブ機能を利用できます。macOSではメニューバーアプリ、Linuxではシステムトレイのアプリ、Windowsでは通知領域の拡張機能(ベータ版)です。セッションごとや月ごとの予算を設定すると、予算が追跡され、使用状況に応じてアラートで通知されます。チームでトークン使用量の制限を設定している場合は、使用可能な残量を正確に把握し、それに基づいて計画を立てることもできます。

コーディングエージェント：Claude、Codex、Cursor、OpenCode、Kiro、Pi

プラットフォーム：macOS、Linux、Windows (ベータ版)

導入方法

macOS/Linux：

git clone https://github.com/splunk/token-meter.git 
./token-meter/scripts/install 

インストーラーによって、ローカルサーバーとネイティブ機能の実行が開始され、自動起動が設定されます。http://127.0.0.1:8722を開き、通常の手順でエージェントを実行して、リストからセッションを選択します。このサーバーはPythonの標準ライブラリのみを使用し、127.0.0.1にのみバインドされ、管理者権限を要求することはありません。

Windows：現在ベータ版で、リポジトリのREADMEに独自のブートストラップコマンドが記載されています。

Token Meterの使い方

先ほどのリファクタリングの例に戻ります。Token Meterでは、トレースが開始された時点からセッションが捕捉されます。

10分後、メニューバーには約6ドルと表示されています。コンテキスト使用率は約60%で、出力は毎秒約50トークンです。コストは上昇していますが、処理も進んでいるため、実行を続けることにします。

5分後、コストが12ドルになりました。コンテキストは上限に近づき、出力速度は極端に低下しています。ダッシュボードを確認してみます。セッションは各ターンで自身の履歴を読み込み直しており、そこでコストの大半を消費しています。これが示しているのは、新しいセッションを開始するか、コンパクションを実行すべきタイミングだということです。コンパクションを実行したところ、応答はより速く完了し、コストは下がりました。

再起動を避けたのは、エージェントの作業コンテキストが失われ、事前準備(プライミング)のやり直しに数分かかってしまうためです。再起動する価値があるのは、処理速度や品質が明らかに低下したときのみです。場合によっては、消費するトークン代よりも自身の時間のほうが大切なので、コストが高いセッションでもそのまま完了させることもあります。重要なのは、実行後に状況を知るのではなく、実行中にコストの推移を見ながらその判断ができることです。

効率の表示では、トレードオフの関係にある要因を時系列で簡単に比較できます。1つのスコアの背後にすべてが隠されてしまうのではなく、モデルと推論エフォートごとに、1ドルあたりの出力、推論比率、コンテキスト負荷、1回の実行あたりの出力を確認できます。これらの数値を総合的に把握することで、最も多くのことがわかります。

• コンテキスト負荷が上がっているのに、1ドルあたりの出力が下がっている場合は、コンテキストの負担が過度に増大している可能性があります。
• 推論比率が高いのに、1回の実行あたりの出力が低い場合は、過剰思考に陥っているか、使用が過度に断片的である可能性があります。
• 1ドルあたりの出力が安定し、コンテキスト負荷が下がり、結果が許容範囲内のままコストが下がっている場合は、効率が向上したと判断してよいでしょう。

これに対して手を打つには、支出が多いモデルを1つ選び、比較可能な作業を対象にベースラインを確立します。次に、モデル、推論エフォート、スキル、プロンプト構造、コンテキストサイズ、タスク分解などの変動要因を一度に1つずつ変更し、似た条件で複数回実行して観察することで、その変更の効果が実際にあったかどうかを判断します。

使ってみて、最も頻繁にアクセスしたのはメニューバーでした。誰もがダッシュボードを中心に作業するだろうと思っていました。しかし、ダッシュボードは実行の調査に使用するものであり、そもそも調査を行う意味があるかどうかはメニューバーで判断しているのです。特に、3つのエージェントが同時に稼働していて、そのうちどれを監視すべきかを判断するときに役立ちます。

ライブ実行表示では、実行に関する複数の数値を確認できます。以下の数値が表示されます。

• 出力速度(1秒あたりのトークン数)
• モデルからの応答待ち時間
• 新規の入力と生成された出力の間の比率
• 各ツールの呼び出しと、返ってきた量

出力速度はわかりやすい指標です。コストが上昇し続けているにもかかわらず出力速度が低下している場合は、通常、モデルが新たな処理を実行しているのではなく、膨大なコンテキストを処理していることを示します。ダッシュボードには、実行状況を表示する以外にも、生のイベントのタイムライン、使用状況の統計を表示するツールタブ、導出されたシグナルを表示するインサイトタブ、予算状況を表示するアラートタブがあります。このように、1カ所でセッションを分析し、どこでトークンが消費されているかを把握できます。

Token Meterで支出を削減

予算管理

自分はいつも、セッションごとの予算と月ごとの予算を設定しています。Token Meterは、実行が上限を超えたときやコストが急増したときに通知を発し、それ以外のときはメニューバーで静かに動いています。この設定は現実の作業環境に合っています。処理状況を絶えず気にするのではなく、問題が起きたときに知らせてもらうことで、本来の仕事に集中できます。アラートやセッションの遅延が発生して状況の確認が必要になったときは、リアルタイムのグラフをすぐにチェックできます。

モデルルーティング

エージェントが日常的に実行するタスクの多くは、より安価で高速なモデルで十分に処理できます。そのため、高価なモデルの使用を避けることで簡単にコストを削減できます。まずは同じタスクを2つのモデルで実行し、コストと出力速度の差をモデル間で比較します。数値の裏付けが得られたら、より小規模なモデルにタスクを振り分けます。

スキル管理

一度も使用されない1つのスキルパックが、リクエストが処理されるたびに数千トークンの負荷を密かに追加している場合があります。ツール表示では、各機能が、実際の使用頻度や結果の量に基づいてランキングされるため、こうした無駄な負荷を簡単に特定できます。役目を果たしていない機能は無効にしましょう。エージェントに持たせるツールは多い方がよいと考えていたとしても、この表示を見れば考え方が変わるでしょう。

MCPインサイト

自分で詳細を探るよりも、質問して答えを得たい場合には、読み取り専用のMCPサーバーを使って、現在作業中のエージェントから離れることなく、このデータをClaudeやCodexに直接取り込み、使用状況に関するインサイトを取得できます。設定画面でClaudeやCodexと接続してから、コーディングエージェントを再起動すると、以下のMCPツールを利用できるようになります。

• usage：当日、過去7日間、過去14日間という範囲で、支出、モデル構成、ツール結果の量、日ごとの変化を確認できます。
• sessions：ランタイム、モデル、状態、時間のフィルターを使い、現在進行中、完了済み、または過去のセッションを検索できます。
• trace：特定のセッションについて、実行、イベント、ツールのアクティビティ、コンテキストの増加、再試行、失敗、カバレッジ、警告を調査できます。
• stats：エージェント、モデル、日付、セッション、ツールごとに、トークン量、推定コスト、タイミング、コンテキスト、実行回数、ツールのアクティビティを比較できます。

このツールで他にできること

数週間後、以下の疑問については自分で推測するのを止めました。

• この1週間でこのプロジェクトにどのくらい使ったか？
• 各モデルは実際にどのくらいの速度でトークンを生成しているか？
• いま実行中のセッションで、コンテキストウィンドウはどれくらいの大きさになっているか？
• 先週1週間で何に時間とトークンが消費されたか？
• 高いコストがかかったログはどれか？(タイトル、プロジェクト、モデル、プロバイダー、または時間に基づいてサーチおよびフィルタリングしてから、コストまたはトークン量で並べ替えます。)
• 過去数日間で、再試行のループや繰り返されるエラーなど、フラストレーションを示す兆候がセッション内でどれくらいの頻度で発生したか？

サブスクリプションを利用している場合

Claude MaxやCursorの有料プランを利用している場合は、追加のトークンコストはほぼゼロなので、費用についてそれほど気にする必要はありません。問題はクォータです。Token Meterはプロバイダーが提示する制限値を読み込みます。そのため、指標として役立つのは、タスクの実行中に上限に達するまでに残された余裕と、セッションごとの比較です。金額の数値も、実際の請求額ではなくても、相対的な指標として利用できます。

Token Meterがしないこと

Token Meterは、公開されている価格表に基づいてコストを算出するため、金額はAPIの利用量に基づく推定額であり、請求書の金額を再構築しているわけではありません。次に何をすべきかを決めるうえで必要なのは、相対的に解釈することです。つまり、セッション間の比較、モデル間の比較、現在の傾向と5分前の比較などです。正確な金額は重要ではありません。

また、Token Meterでは処理が良かったかどうかは評価できません。コストが低い回答でもテストに不合格であれば、高くつきます。時間のかかるセッションでも本番環境の問題が目立たずに解消しているのであれば、割安となります。品質は、ご自身の評価とレビューに基づいて判断してください。Token Meterはコストを測定するものであり、その評価はユーザーに委ねられます。

拡張性を踏まえた設計

Token Meterはもともと、macOSでのClaudeとCodexの使用状況を把握するMac用ユーティリティとして開発されましたが、その後、他の開発者からの貢献によって急速に成長しました。コントリビューションガイドをご覧のうえ、必要な機能の拡張にご協力ください。

今すぐお試しください！

git clone https://github.com/splunk/token-meter.git 
./token-meter/scripts/install 

Token Meterに関するよくある質問