# Token Monitor: A Local-First Dashboard for AI Coding Tool Usage Across 32+ Tools

> Token Monitor is a desktop widget that reads local data from Claude Code, Codex, Cursor, and dozens of other AI coding tools to show token usage, limits, and session details, with multi-device sync. It trades deep per-tool accuracy for breadth, and its value depends on how well it parses each tool's local files.

**Javis603/token-monitor** — Local-first desktop widget for tracking token usage, costs, and limits across 31+ AI coding tools—including Claude Code, Codex, Cursor, OpenCode, and OpenClaw—with multi-device sync.

- Repository: https://github.com/Javis603/token-monitor
- Website: http://javis-ai.com/token-monitor/
- Stars: 3,245 · Forks: 309
- Language: JavaScript
- License: MIT
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/javis603-token-monitor

## What Token Monitor Solves and Who Needs It

Token Monitor addresses a real pain point: developers using multiple AI coding tools have no single place to see how many tokens they consume, what their limits are, and what sessions look like. Each tool stores its own data in different formats and locations. Claude Code writes to ~/.claude/projects/, Codex uses ~/.codex/, and Cursor keeps an account-level usage export in ~/.config/tokscale/cursor-cache/. Without a unified view, you have to check each tool's dashboard or dig through local files. Token Monitor is for engineers who jump between tools like Claude Code, Codex, Cursor, OpenCode, and OpenClaw, and who want a local-first widget that aggregates this data without sending it to a cloud service. The README positions it as 'One live dashboard for every AI coding tool, synced across every machine.' That promise is ambitious, and the project's value hinges on its ability to parse many different local formats correctly.

## How It Works: Local Data Parsing, Not API Calls

The core mechanism is reading local data files and databases. For each supported tool, Token Monitor knows a default data path. For example, it reads Claude Code from ~/.claude/projects/ and ~/.claude/transcripts/, Codex from ~/.codex/ sessions and archived_sessions, and OpenCode from ~/.local/share/opencode/ where it finds opencode*.db and storage/message/. It also supports environment variable overrides like $CODEX_HOME, $GROK_HOME, and $HERMES_HOME, matching what Tokscale does. For some tools, it reads SQLite databases directly, like Hermes Agent's ~/.hermes/state.db and Zed's threads.db. For others, it uses API keys, such as OpenRouter, Minimax, Volcengine, and Trae CN, which query account limits and balances. The widget then presents token usage, AI tool limits, and session details in a dashboard. The README shows that you can click any tool to expand input/output and cache-hit detail, and open a single session to break each prompt into tokens and tools used. This is a local-first approach: no central server is mentioned, and multi-device sync is claimed, but the mechanism for sync is not detailed in the provided material.

## Getting It Running: Commands and Configuration

The README does not include installation commands, but it does describe configuration. You enable tools in Settings, and some tools are opt-in. For example, Qoder CN's token usage is read from a local SQLite database, and you must enable it in Settings → tools; it is off by default. The database path is auto-detected per platform, but you can override it with the environment variable TOKEN_MONITOR_QODER_CN_DB_PATH. For Cursor, you can add accounts manually in Settings, and the widget detects accounts signed in through the Cursor desktop app. For third-party APIs, you can set up New API / Sub2API-compatible account presets, a New API API-key preset, and a custom balance endpoint. The custom endpoint must map numeric JSON fields from a single GET balance endpoint; OpenAI or Anthropic compatibility alone is not enough. The project has releases like v0.49.0, so you would download the widget from the releases page. No npm install or CLI command is documented in the material, so the primary distribution is likely a packaged desktop app.

## Limitations: Estimated Counts and Fragile Adapters

Token Monitor has clear limitations. For Command Code, transcripts do not contain actual token counts or per-message model metadata. Token usage is estimated from transcript text, and model attribution and derived cost may reflect the currently configured model rather than the model historically used. That means cost numbers for Command Code can be misleading. The Cursor cache comes from an account-level usage export, so newly finished sessions can take a few minutes to reach Cursor's dashboard, and usage updates on sync rather than instantly. The Qoder CN adapter reads a local SQLite database, and the README warns that it may break if Qoder changes its database schema. It also requires a sqlite3 CLI on PATH or a Node runtime with unflagged node:sqlite (Node ≥ 23.4). If reading fails, the widget logs the error and retains an existing complete snapshot instead of replacing it with zero usage. This is a sensible failure mode, but it means you might see stale data. These are honest trade-offs: breadth across 32+ tools comes at the cost of precision for some of them.

## Alternatives: Tokscale and Per-Tool Dashboards

The README mentions that Token Monitor follows the same environment overrides Tokscale does, which suggests Tokscale is a related or competing tool. Tokscale appears to be another token tracking solution, but the material does not describe its approach in detail. A more concrete alternative is to use each tool's built-in dashboard. For example, Cursor has an account-level usage export that Token Monitor reads, so you could just check Cursor's dashboard directly. Similarly, Claude Code and Codex have their own usage views. The difference is that per-tool dashboards give you accurate, tool-specific data but require you to switch between them. Token Monitor aggregates everything into one widget, but it relies on parsing local files, which can be fragile. Another approach is to use an API-based aggregator, but the README only mentions API keys for limit checks, not for token usage of most tools. So the real alternative is either accept the fragmentation of per-tool dashboards or trust Token Monitor's local parsing. The trade-off is convenience versus accuracy.

## Maintenance and Upgrade Cost

The project is actively developed, with three releases in August 2026: v0.49.0, v0.48.0, and v0.47.0. That frequency means fixes and new tool support arrive regularly, but it also means you need to update often. Each release may change data parsing logic, and the README warns that adapters can break if tools change their local schemas. For example, the Qoder CN adapter depends on the database schema, and the Cursor cache depends on Cursor's export format. You should budget time for testing after each update, especially if you rely on a tool that is not mainstream. The license is MIT, which is permissive and allows commercial use and modification without restrictions beyond preserving the license notice. No contribution guidelines or maintenance guarantees are mentioned, so the project's longevity depends on the maintainer's activity. The homepage is javis-ai.com, but the material does not clarify whether there is a paid tier or support model.

## Who Should Adopt It and What to Verify First

Token Monitor is a good fit for developers who use several AI coding tools and want a single local widget for token usage and limits. It is especially useful if you are on Claude Code, Codex, and Cursor, because those have solid support with session details. It is a wrong choice if you need exact token counts for tools like Command Code, where estimates are used. Before adopting, check the supported tools table to confirm your tools are listed. Then verify the data paths: if you have customized your home directory or set environment variables like $CODEX_HOME, make sure Token Monitor respects them. The README says it follows Tokscale's overrides, but test with your actual setup. Also, check the release notes for v0.49.0 to see what changed recently, as the widget is evolving quickly. If you use Qoder CN, confirm you can enable the opt-in adapter and that sqlite3 is available. The project's value is real, but it is not a set-and-forget tool; it requires initial configuration and periodic verification.

## Conclusion

Adopt Token Monitor if you use several AI coding tools and want a single local dashboard for token usage and limits, and if you accept that some tools (like Command Code) have estimated rather than exact counts. Skip it if you need precise per-model cost attribution for every tool, or if you rely on a tool whose local data format is undocumented and could change. Before adopting, verify that each tool you use is listed in the supported tools table, check the data paths it reads, and test whether the widget correctly parses your existing sessions. The project is under active development with frequent releases, so budget time for updates and potential adapter breakage.

## FAQ

### What does Token Monitor track?

Token usage, account limit checks and session details for AI coding tools, read from the files those tools already write locally, with breakdowns by tool, device, model, session or project.

### Which tools give session-level detail in Token Monitor?

Four of the rows in its supported table: Claude Code, Codex, OpenCode and the DeepSeek harness. Most rows report token counts and limit checks but not session detail.

### Does Token Monitor need to send my data anywhere?

Not in single-device mode, where the widget reads files directly and no server is involved. Sync mode is optional and runs through a hub you host yourself, whose example address is a subdomain on a hosted worker platform.

### What are the limits of Token Monitor's tracking?

Several, and they are documented. One editor integration ignores its own chat interface, one excludes training tokens, one tool's logs are read on Linux and remote sessions only, and one desktop agent meters its usage server-side, so a default setup reports no tokens for it.

### How does Token Monitor collect usage data?

It vendors its data layer with a script that runs before every launch command, then reads each tool's own files: project and transcript directories, SQLite databases, line-delimited session logs, and editor storage directories.

## Sources

- [Official documentation](http://javis-ai.com/token-monitor/)
- [Official README](https://github.com/Javis603/token-monitor#readme)
- [Project repository](https://github.com/Javis603/token-monitor)
- [Release notes](https://github.com/Javis603/token-monitor/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/javis603-token-monitor