coding agent を日常的に使うと、難しいのは「完了できるか」だけではない。どれだけ context を消費したのか、いくらかかったのか、どの tool を呼んだのか、どの時点から遠回りし始めたのかが見えにくい。Claude Code、Codex、Gemini CLI、Cursor、Copilot にはそれぞれ log や計測方法があるが、1 session の cost を知るために JSONL、cache directory、client UI を行き来したい人は少ない。

今日メモしておきたい VasiHemanth/tokentelemetry は、このかなり実務寄りの痛点を扱う project だ。新しい agent runtime ではなく、100% local の observability dashboard である。手元の agent がすでに書いている log を読み、token usage、LLM cost、tool calls、session traces、reasoning steps、plan capture、per-project analytics を同じ local page に集める。

2026-07-14 時点で GitHub repository page、README、Releases page、Tags page、commit history、LICENSE から確認できる公開情報では、VasiHemanth/tokentelemetry は 229 stars、30 forks。言語比率は Python 46.7%、TypeScript 44.5% で、GitHub の language list でも Python が先頭に出ている。license は MIT。最初の公開 commit は 3806fc1b、時刻は 2026-04-24 06:34:51 UTC。default branch main の現在の最新 commit は 8e074298、commit time は 2026-07-13 15:21:23 UTC。GitHub Releases page と Tags page は、現時点で release / tag がないことを示している。

プロジェクト概要

項目内容
リポジトリVasiHemanth/tokentelemetry
位置づけlocal AI coding / autonomous agent observability dashboard
Stars229
Forks30
主な言語Python 46.7%、TypeScript 44.5%
ライセンスMIT
最初の公開 commit3806fc1b、2026-04-24 06:34:51 UTC
最新 main commit8e074298、2026-07-13 15:21:23 UTC
Latest GitHub release公開 release なし
最新 tag公開 tag なし
主な入口curl -fsSL https://tokentelemetry.com/install.sh | bash、./start.sh、node bin/cli.js
キーワードlocal-first、token usage、cost tracking、session trace、tool calls、Codex、Claude Code、Hermes Agent

agent の bill と挙動を black box にしない

TokenTelemetry の README は、問題をかなり直接的に書いている。agent は強力だが token を速く消費する。だから、ある refactor が何 token 使ったのか、どの model が効率的なのか、agent が実際にどの tool を呼んだのか、plan に沿って動いたのかを知る必要がある。

この種の問題は、これまで「あとで請求書を見る」扱いになりがちだった。API bill が出てから、あるいは明らかに session が暴走してから、log を戻って確認する。しかし coding agent が日常の開発に入ると、それでは遅い。大きな refactor、repository 横断 search、失敗した test の再実行が数回続くだけで、気づかないうちに context と API cost をかなり消費する。

TokenTelemetry の入口は read-only だ。application code に SDK を入れる必要はなく、agent traffic を cloud proxy に流す必要もない。Claude Code、Codex CLI、Gemini CLI、Cursor、GitHub Copilot、OpenCode、Qwen、Vibe、Antigravity、Grok Build、Hermes Agent などの local session logs を読み、手元の dashboard で統合 view を作る。

この方向が実用的なのは、agent observability がまず developer machine に近いところから始まるべきだと割り切っている点だ。多くの team が最初に欲しいのは大がかりな APM ではなく、どの project が token を燃やしているか、どの agent session が異常に長いか、失敗した workflow が実際にどの tool を呼んだかを答える画面だ。

local-first だが、完全な no-network ではない

README は no signup、no cloud、logs never leave your machine を強く打ち出している。agent log には prompt、file path、command output、project name、場合によっては code snippet も入るため、この姿勢は重要だ。これらを default で外部 service に送る tool は、company environment では導入しにくい。

ただし、完全に network behavior がないわけではない。README の privacy section は比較的明確で、dashboard は定期的に GitHub へ update check を行う。また、default on で opt-out 可能な anonymous product usage telemetry があり、page view、feature usage、OS / CPU arch、近似 country、検出された agent 名などを送る。ただし code、prompt、model output、path、project name、token counts、costs は送らないと説明されている。

この点は採用判断に入れたい。TokenTelemetry の core data plane は local だが、team が outbound signal に厳しいなら、まず Settings で usage telemetry を切るか、isolated environment で network behavior を確認した方がよい。

Codex / Claude Code ユーザーに効きやすいところ

Codex や Claude Code を普段使っていると、本当に面倒なのは「log がない」ことではなく、log が分散し、低レベルすぎることだ。1 session には plan、tool calls、失敗した command、retry、cache hit、subtask、複数ラウンドの model output が混ざる。developer は通常、最後の diff や回答だけを見る。

TokenTelemetry はその過程を、scan しやすい軸に変える。per-session cost、per-project heatmap、tool usage breakdown、agent leaderboard、model analytics、budget alerts、session waterfall、plan capture などだ。agent UI を置き換えるものではなく、agent が作業した後に比較可能で追跡可能な run ledger を残す tool に近い。

特に tool call analytics と session trace は見たい。coding agent の失敗は、model が何も理解できないから起きるとは限らない。tool choice、context refresh、test command、file location のどこかでずれることが多い。どの step で何を呼び、失敗率がどうで、どの project が長い session を作りがちかを見られる方が、総 token 数だけより価値がある。

Hermes Agent 対応で coding agent だけに閉じていない

README は最近 Hermes Agent dashboard も強調している。Hermes Agent は単なる CLI coding agent ではなく、Telegram、Discord、Slack、Feishu、cron、webhook などの入口から動くことがある。TokenTelemetry は /hermes view を用意し、$HERMES_HOME または ~/.hermes/ を読み、source platform、API call latency、cache hit、subagent cards、skills、memory、cron health、gateway health、cost anomaly detection を見せる。

これは project の狙いが「Claude Code の chart tool」だけではないことを示している。複数入口の agent の実行履歴を local console にまとめる方向だ。agent を scheduled job、chat entrypoint、internal tool に入れ始めている team には、単なる token counter よりこちらの方が使いやすいはずだ。

もちろん複雑さも増える。対応 agent が増えるほど、log format の変更、version compatibility、path discovery、pricing table sync が maintenance pressure になる。repository の commit は活発だが、project 自体はまだ若い。まずは観察と診断の tool として使い、唯一の会計 source にはしない方がよい。

向いている場面

第一の場面は、複数の coding agent を同時に使っていて、project ごとの token burn、cost、tool call の差を知りたい場合だ。

第二の場面は、agent 利用に budget alert を付けたいが、budget system に workflow を直接止めさせたくない場合だ。TokenTelemetry の budgets and alerts は observational で、閾値に近づいたことを知らせるが agent を blocking しない。

第三の場面は、ある agent session を後から復盤したい場合だ。plan 通りに動いたか、どの tool を呼んだか、どの command が失敗したか、なぜ長い loop になったかを見たい。

第四の場面は、local または semi-local な autonomous agent だ。Hermes Agent 対応を見ると、単発 CLI conversation ではなく、より長い lifecycle の agent も対象にしている。

注意したいところ

第一に、project には正式な GitHub release や tag がない。install path は簡単だが、production team なら commit を pin するか、少なくとも upgrade 前に UPDATE.json、changelog、実際の diff を確認した方がよい。

第二に、複数 agent の local log directory を読むため、permission surface は普通の dashboard より敏感だ。read-only と説明されていても、自分の machine でどの directory にアクセスし、どの cache を保存するか、team の security requirement に合うかを確認したい。

第三に、README にある「複数 agent / pricing model / reasoning trace」系の機能は魅力的だが、agent ごとの log quality と stability は同じではない。実際の効果は、自分が使っている client ごとに検証する必要がある。

第四に、anonymous usage telemetry は opt-out できるが、default off ではない。company environment 向けに紹介するなら、この点は明記しておきたい。

まとめ

TokenTelemetry が捉えているのは、AI coding workflow でだんだん具体化している問題だ。agent に code を出してもらうだけでなく、どう働いたのか、いくら使ったのか、どこで遠回りしたのか、どの project が context を燃やしやすいのかを知る必要がある。

Codex、Claude Code、Cursor、Gemini CLI、Copilot を日常 tool として使っているのに、token cost や session behavior をほぼ感覚で判断しているなら、VasiHemanth/tokentelemetry は試す価値がある。まだ若く、正式 release もない。だが local-first、read-only、cross-agent observability という方向は、AI development toolchain でますます必要になる層だと思う。