Tokscale review in brief. Tokscale is an MIT-licensed, Rust-based command-line tool that reads local session history from dozens of AI coding agents and shows token usage and estimated cost in one terminal dashboard. A bounded pilot makes sense for an engineering lead, operations manager, or technical founder whose team runs several agents and cannot explain its AI spend. Treat the figures as estimates. Reconcile them against provider invoices, and test large histories and Windows machines before wider rollout.

What problem tokscale solves

The buyer problem is specific: a team runs more than one AI coding agent, Codex CLI on one machine, Claude Code on another, Gemini CLI, Copilot, or Cursor elsewhere, and the vendor views do not add up. Nobody can answer the questions budgeting depends on: what agent usage cost this month, and which model, project, or session drove it. Tokscale targets that gap. Per the repository README, it reads the session files each agent leaves locally, including Claude Code directories under ~/.claude, Codex CLI sessions under ~/.codex, Copilot CLI OpenTelemetry exports, a cached Cursor API export, and several dozen similar stores. It then aggregates input, output, cache read/write, and reasoning tokens in a native Rust core and applies current pricing pulled from LiteLLM with a one-hour disk cache and fallbacks.

The output surfaces, again per the README, are an interactive terminal UI, web visualization, JSON export for scripting, and an optional public leaderboard that users opt into with a submit command. Attribution is the part that matters for management decisions: usage can be grouped by model, client and model, workspace or repository, or session, and JSON rows carry a sessionId so cost can be joined back to a specific agent session.

It is also worth stating what this is not. Cost is a calculated estimate based on pricing tables and model-name matching, not a billing record. The README’s own per-client table shows fidelity varies: Warp contributes aggregate requests and spend only, Freebuff usage is estimated from transcripts, and LM Studio local inference is priced at $0. Token counts are only as good as what each agent version stores.

Who should evaluate it

Good fit

• Teams already running two or more of the supported agents whose monthly AI spend is currently a guess.
• Engineering leads or ops managers who need project-level attribution, which repo, workspace, or agent session consumed what, before deciding which agent or plan to standardize on.
• Technical teams comfortable with a CLI that scans local files and with treating results as estimates reconciled monthly against vendor usage exports.
• Teams on machines with Node.js or Bun available (the CLI also runs through Deno; a source build needs the Rust toolchain, per the README).
• Anyone who wants JSON output to feed scripts or an internal dashboard rather than another portal to click.

Who should wait

• Teams whose finance process needs invoice-exact numbers today; the tool is not there yet.
• Windows-first organizations, until behavior is verified on their own hardware; the Windows record is the weakest part of this snapshot.
• Machines with very large session histories and limited memory, given open out-of-memory reports.
• Single-agent teams where the vendor’s own usage reporting already answers the question.
• Environments where scanning local transcripts or uploading usage data conflicts with policy; the privacy questions need an explicit decision first.

What to verify before relying on the numbers

Standalone answer: you can adopt tokscale for trend visibility and attribution after a short pilot, but you should not treat its cost figures as invoices until you reconcile them against provider exports for a full billing cycle on your actual agent versions.

1. Coverage on your exact agent versions. The README lists several dozen clients, and the release history is full of parser fixes for storage-format changes, such as Copilot Chat v3 events, OpenCode session_v2 metadata, Cursor usage-events keys, and Claude cross-file merges. Run tokscale against one machine for one or two weeks and compare totals with each vendor’s own usage export. If numbers diverge, check the agent version and the tokscale release before anything else.
2. Cost accuracy. Pricing is imported from LiteLLM and matched by model name; ambiguous or missing names are a known failure class. Open issue #1035 shows submit aborting when local sessions contain models with no pricing entry, including some OpenRouter routes and unresolved Antigravity models. Issue #862 documents a long-context tiering discrepancy in which per-bucket marginal pricing undercounted a provider’s request-level long-context billing; the reporter reproduced the provider’s records exactly under request-level tiering and measured roughly an $11 one-day difference for one affected model. v4.15.0 fixed a similar xAI long-context case, but issue #862 remained open at this snapshot. Reconciliation against invoices is not optional if these numbers leave the engineering team.
3. Memory on large histories. Issue #1209, open at the snapshot, reports out-of-memory on long submit runs against large local history, including on recent versions. Test with your largest history before scheduling scans or automated submission on low-memory or shared machines, and prefer filtered local JSON exports when the public submission is not essential.
4. Windows behavior. Maintainer-authored issue #1014 catalogues 33 pre-existing Windows test failures across six root-cause groups, including a config directory that does not follow a redirected home, Crush registry discovery returning nothing (flagged as a likely real bug), and a variant-resolution issue that could affect provider attribution. The v4.12.0 release notes describe making the windows-latest test leg a hard gate, but the tracking issue was still open at the snapshot. Pilot Windows machines individually before rollout.
5. Data handling and uploads. Tokscale reads session files that can contain code and conversation content. Some clients need an API export or cookie flow (Cursor) or account-level sync (Trae), and the task-attributed report feature is described as LLM-powered with several listed backends, so review what it sends before enabling it. The README invites users to run submit to create a public profile, and autosubmit exists; the evidence I reviewed does not detail retention or deletion of submitted data. Decide company policy first; local JSON export does not require the leaderboard. One further integrity caveat on the public side: maintainer-authored issue #960 describes how rescanning the same local history under a different timezone can permanently inflate stored leaderboard and profile totals because a regression guard prevents stored values from decreasing. A correction design was proposed but was still open at the snapshot. Treat public profile numbers as unaudited.

What the maintenance record shows

Measured signals from the snapshot: the repository was created December 1, 2025, was last pushed September 5, 2026, and carried 5,299 stars, 441 forks, and 75 open issues. In the four weeks before this review it shipped five releases: v4.12.0 on August 8, v4.13.0 on August 10, v4.14.0 on August 26, v4.15.0 on August 29, and v4.15.1 on September 3. The v4.15.1 notes alone list new Unsloth Studio parsing plus fixes across DeepSeek Harness, Copilot, OpenCode, Cursor, Senpi, Command Code, Windows credential handling, pricing for retired provider models, and clearer CLI error reporting, with several new contributors.

That cadence is a genuine maintenance signal, and it cuts both ways. The maintainers respond quickly to parser regressions and keep adding clients. The other side is that a weekly release cadence makes the tool a moving target: every agent upgrade can change storage layout, and the changelog shows that churn directly. Teams that standardize on tokscale need someone to own upgrades and regression checks, or the dashboard quietly goes stale.

Where custom development starts

The tool is local and per-developer. Nothing in the evidence suggests a managed multi-user backend, scheduled collection across machines, cost-center mapping, or alerting. If the real requirement is engineering spend per team or per product each month, the deliverable is a pipeline: scheduled filtered JSON exports from developer machines or a runner with access to their session stores, normalization of workspace labels to your projects, reconciliation against provider invoices, and a read-only report your finance or operations team can open. That layer is custom work on top of a solid open-source core. Setting it up is AI-agent deployment and integration work, and the reporting half is an integration problem: moving usage data into the system your business actually uses. When that gap is what you are facing, custom software development services are the practical route rather than another round of manual exports.

Maintenance is part of the same decision. New agents appear, agent storage formats change, pricing tables and model aliases drift, and the open issues show edge cases that only surface on real data. A company depending on these numbers is signing up for version pinning, upgrade testing, and fallback to vendor exports when a scanner regresses.

How to evaluate it against alternatives

Your baseline is each vendor’s own usage reporting for the agents you actually run. Compare tokscale totals against those exports for the same date range; every difference should be explainable by model naming, pricing cache, or parser coverage. Adjacent tools exist; tokscale added a ccusage import format in v4.14.0, which suggests users move between trackers and value portable data. If your team routes agent API traffic through a gateway or proxy that already records usage, ask whether a local file scanner adds enough attribution to justify the extra moving parts. Questions that decide the pilot: which agents and versions do we run, and are they on the supported list? Do we need per-developer visibility or team-wide allocation? Who reconciles estimated cost against invoices monthly? Do any of our models trigger unpriced or alias-mismatch warnings? Is any developer on Windows? Is public leaderboard submission acceptable under company policy?

Verdict

Based on this source and documentation review, tokscale is a credible candidate for a small engineering team with several AI coding agents and a real cost-attribution problem, and it is active enough to track a fast-changing agent ecosystem. The condition is trust: cost is estimated, memory and Windows behavior still carry open edge cases, and the release cadence makes an upgrade owner necessary. The practical recommendation is a one- to two-week pilot on the machines your team actually uses, with output compared against vendor usage data, before any wider rollout. Do not wire raw numbers into finance or client billing until reconciliation closes consistently across a billing cycle. It is a monitoring tool maturing into an observability layer, not yet a billing system.

What I can do next

If you are at the point where that pilot decision matters, I can help with the parts that decide it: configure tokscale against the agents and versions you actually run, reconcile a bounded window of output against one provider invoice or usage export, and document which figures you can trust and which need a manual check. I would need read access to one representative machine’s session history (or sanitized exports), the list of agents and versions in use, and that billing export. If the pilot earns a place in your workflow, the follow-on, which covers scheduled exports, project mapping, alerts, or a team dashboard, is the integration layer I can build on top of the tool’s JSON output. Contact me with your agent setup to scope that pilot.

Sources

• junhoyeo/tokscale — repository and README
• Tokscale v4.15.1 release notes
• Issue #1209 — excessive memory usage
• Issue #1014 — Windows test suite failures
• Issue #862 — long-context pricing discrepancy
• Issue #1035 — submit fails on unpriced models
• Issue #960 — timezone re-splits inflate stored usage