TokenTelemetry

TokenTelemetry is a free, open-source, 100% local observability dashboard designed for AI coding agents. It provides a unified view of token usage, LLM costs, tool calls, session traces, and reasoning steps by reading the log files that agents already write to your machine.

Key characteristics:

• Local-first: All data stays in ~/.tokentelemetry/ on your machine. Logs, prompts, and costs never leave your machine.
• Zero-config: Requires no SDK, no API keys, and no code changes. It works by watching existing agent log files.
• Privacy: Does not modify agent logs. Outbound traffic is limited to optional hourly GitHub version checks and anonymous product telemetry (feature usage only, never code or prompts).

Supported agents include Claude Code, Codex, Gemini CLI, Cursor, Copilot, Qwen, OpenCode, Vibe, Antigravity, Grok Build, Cline, SmallCode, Pi, Muse Code, Prime Agent, DeepSeek Harness, Qoder, ZCode, Kimi Code, and Hermes Agent.

The dashboard provides several specialized views for monitoring AI agent activity:

• Dashboard: Live KPI strip (sessions, tokens, projects, cost) with 15-second auto-refresh, agent/model distribution charts, and recent activity.
• Analytics: Date-range filters, per-agent/model breakdowns, token area charts, cache-efficiency metrics, and a Delegation & Ecosystem section (subagent spend, skills, MCP servers).
• Traces: Replayable session traces including events, messages, tool calls, artifacts, and plan-mode output.
• Summarization: One-click LLM-generated narratives or structured briefs (What / Tools / Why / Next) for sessions.
• Projects: Per-working-directory cards featuring a 365-day heatmap, streaks, tool usage, and configuration overlays.
• Hermes Agent: A dedicated /hermes hub for monitoring gateway health, 38 source platforms, scheduled jobs, latency, skills, and memory.
• Desktop App: A native window version of the dashboard available via a local Electron shell.

The Hermes Agent dashboard is located at /hermes within TokenTelemetry. It is designed for autonomous agent frameworks (like Nous Research's Hermes) that operate across various platforms (CLI, Telegram, Discord, Slack, etc.) rather than just coding tasks.

Core Metrics

• Gateway Health: Status and uptime.
• Source Breakdown: Monitoring across 38 platforms (e.g., CLI, Telegram, Discord, Slack, Feishu, DingTalk, cron, webhook).
• Performance: Per-API-call latency and cache-hit percentages (parsed from agent.log).
• Cost Monitoring: Detection of cost anomalies and reasoning-token waste.
• Subagent Tracking: Inline delegate_task cards showing child session summaries, tokens, duration, and tool traces.

Dashboard Sub-pages

1. Skills: Tracks 90 loaded skills, platform conditions, and invocation counts.
2. Tools: Tool registry with call counts and success rates.
3. Profiles: Active agent profiles and configurations.
4. Soul: Agent persona/soul configuration.
5. Memory: Progress tracking for MEMORY.md and USER.md including character limits and edit history.
6. Gateway: Connection health, latency trends, and error rates by provider.
7. Schedules: Cron job registry, run history, and next-run countdowns.

Qoder does not record token counts (e.g., input_tokens and output_tokens are always 0 in the usage object). Instead, it uses a credits system.

To calculate spend, use the credits field in the assistant record's usage object.

Key fields in the usage object:

• credits: The actual amount charged.
• original_credits: Typically $2\times$ the credits value (likely the list price).
• context_usage_ratio: A fraction of an unknown denominator; token counts cannot be reconstructed from this value.

Important: When calculating total session costs, ensure you include both Root sessions and Subagent transcripts, as delegation (subagents) can account for a significant portion (e.g., ~49%) of total spend.

{
  "input_tokens": 0,
  "output_tokens": 0,
  "cache_read_input_tokens": 0,
  "cache_creation_input_tokens": 0,
  "server_tool_use": {
    "web_search_requests": 0,
    "web_fetch_requests": 0
  },
  "service_tier": "standard",
  "inference_geo": "",
  "iterations": [],
  "speed": "standard",
  "credits": 1.5205821428571429,
  "original_credits": 3.0411642857142858,
  "billable": true,
  "request_id": "<uuid>",
  "context_usage_ratio": 0.026787
}

Traces are organized into five functional tabs for different auditing needs:

1. Events: A chronological timeline of the session (start, turns, tool calls, results, end). Events are color-coded:
   • Amber: Reasoning / thinking blocks.
   • Sky blue: Tool calls and results.
   • Emerald: Assistant responses.
   • Default: User turns and system events.
2. Messages: The raw conversation history (user messages, system prompts, and assistant responses) as seen by the model.
3. Tools: A grouped view of every tool call. Shows tool name (e.g., Bash, Edit, Read, WebSearch), arguments, results, timing, and success/failure status.
4. Artifacts: Captured outputs such as published pages, screenshots, browser recording thumbnails, and documents (e.g., task.md, plan.md).
5. Plans: Structured plan-mode output (e.g., Claude Code's /plan command) shown as formatted text with timestamps.