codeburnとは｜41のAIコーディングツールのコストをローカル集計、対応数と通信を自分で数えた

AIコーディングツールを2つ3つと併用しはじめると、AIコーディング コストの合計が誰にも分からなくなる。Claude Codeの/usageはClaude Codeの分しか見せないし、Cursorの請求画面はCursorの分しか見せない。

codeburnは、この「合計が見えない」を、各ツールが自分でディスクに書いている履歴ファイルを読むという方法で解こうとするOSSだ。GitHubのstarは9,785、Homebrew coreにも収録されている。掲げる看板は2つ——「41ツール対応」と「無料・ローカル完結」である。

どちらも都合よく引用されやすい主張だが、幸いどちらも数えられる／測れる。本記事ではコード側の登録簿を数え、手元の環境で実際に何個埋まるかを確かめ、そして通信を傍受して「ローカル完結」を検証した。

AIコーディングツール全体の選び方や併用の考え方はVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026にまとめてある。本記事はその「使った分のコストをどう把握するか」という一点を、実測に絞って掘り下げる。

codeburnとは——各ツールが残した履歴を読んで合算する

codeburnの発想はシンプルで、新しくログを取らない。Claude CodeもCursorもCodexも、セッションの履歴を自分のホームディレクトリ配下に書いている。codeburnはそれを後から読んで集計するだけだ。だからツール側に何も仕込む必要がなく、過去に遡って集計できる。

2026年9月1日時点の実測値は以下のとおり。

★9,785という数字より、Homebrewの1,293インストール/30日のほうが実態に近い指標だと考えている。starは「あとで見る」のブックマーク代わりに押されることが多いが、インストール数は実際に手元へ入れた人の数だからだ。なおopen_issues_countをそのまま「Issue 33件」と書くとGitHub APIの仕様上PRが混ざるので、上表では27と6に分けている。

codeburn 使い方の最短経路——npxとHomebrewの両方を確認した

配布経路は2つある。両方とも実在を確認済みで、本記事の実測はnpx経由とローカルインストールの両方で行った。

# 1) 何もインストールせずに試す（本記事はこれで実測した）
npx codeburn

# 2) Homebrew core に収録されているので tap の追加は不要
brew install codeburn

# 3) 導入後の健康診断。どのツールを探しに行き、何件見つかったかが1画面で出る
codeburn doctor

brew install codeburnについては、Homebrew coreの公式APIで tap: homebrew/core・stable: 0.9.23・license: MIT・依存はnodeのみであることを確認した（ユーザーの環境を変更するためbrew install自体は実行していない）。①の記事で扱ったような個人tapではなく本体に収録されている点は、審査を通っているという意味で信頼性の材料になる。

実行要件はpackage.jsonのenginesで>=22.13.0と宣言されている。本記事の実測環境はNode 22.13.1で、ちょうど下限ぴったりだが問題なく動作した。宣言があるので、古いNodeではnpmが警告を出してくれる。

よく使うコマンドは次の4つに集約される。

このうち最初に打つべきは doctor だと考えている。理由は次節で述べる。

集計以外に載っている機能——予算・最適化・MCP

--helpを読むと、codeburnは単なるレポート表示にとどまらない機能を抱えている。実測環境では集計系しか動かしていないので挙動は未検証だが、何が用意されているかは把握しておく価値がある。

特にmodel-flat-rateとmodel-aliasのヘルプ文には、「定額課金のモデルにmodel-aliasを使うな。他モデルの従量単価に写像して支出を捏造することになる」という趣旨の注意書きが明示されている。コスト計算ツールとして、数字を作ってしまう操作に自分から釘を刺している点は好感が持てる。

「41ツール対応」を数える——面によって数字が違う

READMEは「across 41 tools and agents」と書く。この数はコード側と一致するのか。src/providers/index.tsの登録簿を数えた。

登録は2種類に分かれている。常時読み込む配列と、失敗しても落ちないよう遅延読み込みする名前リストだ。

30＋11＝41でREADMEと完全に一致した。 さらにCLI自身もdoctor実行時に「CodeBurn doctor 41 providers」と表示するので、コード・README・実行時表示の3つは揃っている。

食い違うのはGitHubリポジトリの説明文（description）だけで、こちらは「across 37 tools and agents」のまま止まっていた。READMEを更新したときに説明文の更新が漏れた形である。リポジトリの「顔」として最初に読まれるのは説明文なので、数字を引用するときはREADMEとコードのどちらかを見たほうがよい。

余談だが、この41本の中にはdsh——DeepSeek Harness——も含まれている。エージェント・ハーネス側の新顔にも早い段階で対応しており、対応表の更新は活発だと言える。

「対応」と「計測できた」は別——手元では41分の2しか埋まらない

ここが本記事でいちばん伝えたい点だ。41という数字は「読みに行ける対象の数」であって、「あなたの画面に出る数」ではない。

codeburn doctorを実行すると、41プロバイダそれぞれについて「どのパスを探しに行き、何件見つかったか」が出る。実測環境での結果は次のとおりだった。

doctorの出力は次の形をしている（実測環境のもの。パスは環境ごとに変わる）。

$ npx codeburn doctor
CodeBurn doctor   41 providers   2026-08-31 23:18:05 UTC

  Provider     Sessions  Parsed  Verdict
  Claude             61   8/8+   OK (61 sessions)
  Cursor             20   8/8+   OK (20 sessions)
  Codex               0      -   NOTHING FOUND (~/.codex/sessions does not exist; tool likely not installed)
  Copilot             0      -   NOTHING FOUND (...workspaceStorage exists but holds no sessions; no history yet)
  Vercel AI Gateway   -      -   NETWORK (not configured; no API key)

Codexの行とCopilotの行で理由が違うことに注目してほしい。前者は探索先のディレクトリ自体が無い、後者はディレクトリはあるが履歴が空である。

つまり41分の2である。これはcodeburnの欠陥ではない——インストールしていないツールの履歴が存在しないのは当たり前だ。しかし「41ツール対応」という看板だけを見て導入すると、doctorの画面がNOTHING FOUNDで埋まって面食らうことになる。

doctorの出力が親切なのは、空振りの理由まで書いてあることだ。「そのパスが存在しない（未インストールと思われる）」のか、「パスは存在するがセッションが無い（履歴がまだ無い）」のかを区別して表示する。実測でもCopilotとCursor Agentは前者ではなく後者——ディレクトリはあるが履歴が空——として報告された。数字が0のときに「ツールが壊れている」のか「単に使っていない」のかを切り分けられる。

導入前に見積もりたいなら、自分が使っているツールがこの41本に入っているかを先に確認するのが早い。入っていなければ、そのツールの分は永久に0のままである。

「ローカル完結」を通信の傍受で確かめる

もう1つの看板が「free, local tool」だ。コスト集計ツールは開発履歴という機微なデータを読む。プロジェクト名もファイルパスも含まれるので、これが外に出ないかどうかは導入可否を分ける。

「通信していないこと」は、lsofでLISTENしているソケットを数えても示せない。短命な送信は取りこぼすからだ。そこでNodeの通信経路そのものを包んだ。net.Socket.prototype.connect / tls.connect / dns.lookup / http(s).request / fetch を差し替え、呼ばれたら記録する仕掛けを--requireで先に読み込ませる。

先に陽性対照を取る。 実際に外部へ接続する数行のスクリプトを同じ仕掛けで走らせ、検出されることを確認した。

陽性対照が4件を捉える仕掛けで、statusとdoctorは0件だった。仕掛けが動いていないから0なのではない、と言い切れる。

1点だけ補足がいる。傍受のログにはfetchが1件だけ現れるが、その宛先はdata:application/octet-stream;base64,...というデータURIである。これはバンドルに埋め込まれたバイナリをその場で読み込んでいるだけで、ネットワークへは出ない。件数だけを数えて「通信1件」と書くと誤りになるため、スキーム（data:／file:）で分類してから数える必要がある。

なお、codeburnには通信するサブコマンドも用意されている。share（自分の端末間で使用量を共有）・devices（端末のペアリング）・sync（OTLPエンドポイントへ送信）・mcp（MCPサーバとして起動）だ。これらは明示的に実行したときだけ動くもので、statusやdoctorのような日常の集計経路には現れなかった。doctorの出力でもVercel AI GatewayだけがNETWORKと明示され、他と区別されている。

ccusage・agentsviewとの違い——守備範囲で選ぶ

同じ「AIコーディングのコストを見る」道具はほかにもある。競合というより守備範囲が違うので、使っているツールの構成で選ぶのが正しい。

Claude Codeしか使っていないなら、無理にcodeburnへ移る理由は薄い。 ccusageは日本語の解説記事も揃っており、その一点に絞られている分わかりやすい。codeburnが効くのは、Claude CodeとCursorとCodexが並走していて、どれにいくら払っているのか誰も答えられないという状況だ。実測環境がまさに2ツール併用で、合算が1行で出るのは確かに便利だった。

履歴を「検索したい」のであれば別の道具になる。ローカル完結で履歴を可視化する系統はagentsview徹底解説｜AIコーディングエージェントの履歴・コストをローカル可視化するOSSで扱っている。ツール単体の料金体系そのものを知りたい場合はcursor 料金（Cursor pricing）2026｜Hobby・Pro・Pro+・Ultraの違いと選び方やGitHub Copilotの使い方｜導入・サインインからAgent Mode・料金体系まで2026年最新版のほうが直接的だ。

なおClaude Code単体の消費を公式機能だけで確認したい場合は、/usageや/contextといった組み込みの窓口が何を見せて何を見せないかを整理したClaude Code 使用量 確認の6手段｜/usage で見えるもの・見えないものを実測で切り分けるが対応する。あちらは「公式機能で何が見えるか」、本記事は「サードパーティで横断して見る」という住み分けである。

自分で確かめる——対応数と通信を数える手順

本記事の2つの実測は、どちらも手元で再現できる。公称値を鵜呑みにせず自分で数えるための手順として置いておく。

1. 対応プロバイダを数える。 リポジトリを浅くcloneして登録簿を読むだけでよい。

git clone --depth 1 https://github.com/getagentseal/codeburn.git /tmp/cb
cd /tmp/cb

# 常時読み込みの配列と、遅延読み込みの名前リストをそれぞれ数える
python3 - <<'PY'
import re
s = open('src/providers/index.ts', encoding='utf-8').read()
core = re.search(r'const coreProviders: Provider\[\] = \[(.*?)\]', s, re.S).group(1)
lazy = re.search(r"const lazyProviderNames = \[(.*?)\]", s, re.S).group(1)
core = [x.strip() for x in core.split(',') if x.strip()]
lazy = [x.strip().strip("'\"") for x in lazy.split(',') if x.strip()]
print('core:', len(core), 'lazy:', len(lazy), 'total:', len(core) + len(lazy))
PY
# => core: 30 lazy: 11 total: 41

2. 通信を傍受する。 Nodeの通信経路を差し替える小さなファイルを作り、--requireで先に読ませる。先に陽性対照を通すのが要点で、これを省くと「0件」が「仕掛けが動いていない」と区別できない。

cat > /tmp/egress.cjs <<'JS'
const net = require('net'); const hits = [];
const orig = net.Socket.prototype.connect;
net.Socket.prototype.connect = function (...a) {
  const o = typeof a[0] === 'object' ? a[0] : { port: a[0], host: a[1] };
  const host = String(o.host || o.path || '');
  // data: や localhost は外部通信ではないので分けて数える
  if (!/^(127\.|::1|localhost)/.test(host) && host) hits.push(host + ':' + o.port);
  return orig.apply(this, a);
};
process.on('exit', () => console.error('REMOTE attempts = ' + hits.length));
JS

# 陽性対照：実際に外へ出るスクリプト。1件以上出れば仕掛けは生きている
node --require /tmp/egress.cjs -e "require('https').get('https://example.com',r=>r.resume())"
# => REMOTE attempts = 1

# 本番：集計コマンドを同じ仕掛けで走らせる
npm install codeburn && node --require /tmp/egress.cjs node_modules/codeburn/dist/cli.js doctor >/dev/null
# => REMOTE attempts = 0

この2つを回せば、「41」も「ローカル完結」も他人の記事を信じずに確認できる。バージョンが上がれば数字は動くので、引用するときは自分が確かめた日付を添えるのが安全だ。

まとめ——検証できたことと、できなかったこと

検証できたこと

・「41ツール対応」はコードと一致した。登録簿は常時30＋遅延11＝41で、READMEおよびCLIのdoctor表示と揃う
・GitHubリポジトリの説明文だけ「37」で古い。面によって数字が違うので、引用元はREADMEかコードを選ぶ
・「対応」と「計測できた」は別。実測環境で埋まったのは41分の2（Claude 61・Cursor 20セッション）で、38は未インストール
・集計コマンドは外部へ接続しなかった。status・doctorともに0件。陽性対照が4件を検出する同じ仕掛けでの0件である
・fetchの1件はdata:URIでネットワークではない。スキームで分類しないと誤判定する
・Homebrew coreに収録され、直近30日で1,293インストール。starより実態に近い指標として使える

検証できなかったこと

・41ツールのうち39個は手元に無いため未検証である。パース精度・コスト計算の正しさを確認できたのはClaudeとCursorの2つだけで、残りは「探しに行くパスが妥当そうに見える」以上のことは言えない
・コスト金額の正確さは検証していない。本記事が確かめたのは対応数と通信の有無であって、算出された金額が請求書と一致するかは突き合わせていない
・brew install codeburnは実行していない。Homebrew coreのAPIで式・バージョン・ライセンス・依存を確認したにとどまる
・通信の検証はstatusとdoctorの2コマンドのみ。report（TUI）やweb（ダッシュボード）は対象外で、share/syncなど通信前提のサブコマンドは当然この結論の外にある

導入判断は単純だ。AIコーディングツールを1つしか使っていないなら、そのツール純正の画面で足りる。2つ以上を併用していて合計額が誰にも分からないなら、npx codeburn doctorを1回叩いて、自分の環境で何個埋まるかを見るところから始めればよい。

参照ソース

・getagentseal/codeburn — GitHubリポジトリ（README・src/providers/index.ts・package.json を参照。2026-09-01時点）
・codeburn — Homebrew Formulae（homebrew/core収録・バージョン・インストール数の確認）
・codeburn — npm（配布版0.9.23の取得元）