How OpenTokenMini works
Coding agents report every call over OTLP, the OpenTelemetry protocol most harnesses already speak. A collector stores those records where you choose, and dashboards, analysis and an MCP server for agents read from it.
- Harnesses: Claude Code, Codex, Antigravity, OpenCode and other open harnesses. A session includes its subagents. Setup per harness: harnesses.
- Collector: on the dev machine, as a private team deployment, or for the whole organization. What one machine collects can sync periodically to the team or organization instance. One instance serving several teams needs permissions per team (identity).
- What is sent: metadata by default (tokens, cost, time, errors). Prompts and code only if you turn them on (transcripts).
- Read side: dashboards for people, the analysis, and an MCP server so agents can query the same data.
Analysis method
From the whole harness down to single commits. Each level adds one data source, joined to sessions by user, time and repo.
These levels are reference defaults, not a fixed pipeline. Each team or user changes them to their preference through the orchestration agents: which levels run, what they group by, which data sources they join.
- Per harness: spend, time and errors by harness and model. Telemetry only.
- Per session: where tokens and time go inside a session and its subagents: context, cache, tool calls, MCP servers, retries.
- Per commit: what each session changed in the codebase, and whether it merged (version control).
- Against runtime and infrastructure: whether a change made services slower, broke them or changed their cost (observability, CI).
Optional decision models label each session's intent and quality so the analysis can group by what people were trying to do (decision models). Full method: analysis method. Suggested changes and how they are measured: recommendations.