TokenTelemetry — See exactly what your Claude Code, codex, gemini cli and 6 more coding agents sessions cost, think, and do (100% local, open source)

[VasiHemanth]

Hey cc-switch community!

If you're switching between Claude models to optimize performance and cost, you probably ask yourself: "How much did that session actually cost me?" or "What was Claude actually doing under the hood?"

I built TokenTelemetry to answer exactly that — a 100% local, open-source observability tool for AI coding agents.

What it does

• Tracks token usage, cost, reasoning traces, and subagent activity in real-time
• Works with Claude Code, Codex, Gemini CLI, Cursor, Copilot, and 5 more — zero config
• Reads directly from local agent log files (no proxies, no cloud, no signup)
• One dashboard to see every agent, every session, every model

Why it pairs well with cc-switch

cc-switch lets you swap between Claude models on the fly. TokenTelemetry lets you see the impact of those switches — compare token burn and cost across claude-opus-4-7 vs claude-sonnet vs other models session by session. Great for understanding which model gives you the best value for a given task.

Install (macOS/Linux)

curl -fsSL https://raw.githubusercontent.com/VasiHemanth/tokentelemetry/main/install.sh | bash

MIT licensed · runs offline · requires Node 18+, Python 3.9+

GitHub: https://github.com/VasiHemanth/tokentelemetry
Website: https://tokentelemetry.com

Would love feedback from power users here — especially if you notice anything specific to multi-model sessions that would be useful to track. Happy to discuss!

[ofekron]

I maintain Better Agent, a local workspace that supervises native Claude, Codex, and Gemini coding sessions. The multi-model telemetry distinction I would find most useful is separating logical work from provider sessions and model segments.

A single task may start in Claude, delegate a bounded slice to Codex, retry after a crash, then get reviewed by Gemini. A per-session cost table is accurate but can hide the workflow economics. I would track at least:

• logical_task_id and parent/delegated task lineage;
• provider-native session ID plus attempt/fork ID;
• model/config segments within a session, with exact switch timestamps;
• prompt, cached, reasoning, and output tokens per segment where the provider exposes them;
• approval/waiting time separately from model and tool execution time;
• terminal outcome: accepted change, rejected attempt, test failure, interruption, or recovery replay.

That enables more useful questions than “which model was cheapest?”: cost per accepted task, duplicate spend across retries, review cost relative to implementation cost, and whether switching models actually reduced time-to-verified-result. I would also keep native provider fields alongside normalized fields—otherwise a common schema can erase why two token totals are not directly comparable.

It is source-available and free for non-commercial use; commercial use requires separate permission.

AI-assistance disclosure: this comment was drafted by Codex under the maintainer’s authorization and reviewed in Better Agent.