Tokscale is worth a trial if your team runs several AI coding agents and you cannot currently answer which project, model, or session is burning the budget. It reads local agent session data, prices it, and reports cost by day, model, session, and workspace. The condition: treat its numbers as estimates until you reconcile them against provider invoices, because pricing gaps are still open in its issue tracker.

tokscale at a glance

the buyer problem: AI coding agent cost tracking with no attribution

Once more than one developer on a team uses more than one AI coding agent, token spend stops being traceable. Each vendor reports its own usage in its own dashboard, keyed to its own account, and none of them knows which repository, sprint, or client engagement the tokens belonged to. Founders and operations managers end up holding several small bills, with no per-project attribution and no defensible way to answer whether a month-over-month increase came from more work or from a retry loop nobody noticed.

That is the decision this review addresses: whether to adopt tokscale as the collection and attribution layer for that problem, or to wait and build something narrower. The reader is the person who owns engineering tooling and AI spend at a small company, usually a founder, an engineering manager, or an operations lead with development responsibility. The stage is evaluation, before any team-wide rollout.

what tokscale actually does

The repository describes the project as “a high-performance CLI tool and visualization dashboard for tracking token usage and costs across multiple AI coding agents,” and the maintainers’ README lists a long roster of supported clients. The repository description also claims “trillions of tokens tracked” on a global leaderboard; that is a maintainer statement, and nothing in the evidence reviewed here verifies it.

input: local session stores, not vendor APIs

Tokscale does not ask each vendor for an API export. Per the README, it reads the local session, transcript, and usage stores that agent CLIs and IDEs already write on the developer’s machine. Documented examples include Codex CLI under ~/.codex/sessions/, Claude Code under ~/.claude/projects/ and ~/.claude/transcripts/, and Gemini CLI under $GEMINI_CLI_HOME/tmp/*/chats/*.json with a ~/.gemini fallback. Dozens of other clients are listed with their paths, including OpenCode, GitHub Copilot CLI, Amp, Droid, Goose, Zed, Kiro, and LM Studio.

That design is what makes cross-tool reporting possible without vendor cooperation, and it is also the main source of fragility: when a client changes its storage format or its home directory, the parser has to change with it.

cost: third-party pricing data, cached locally

The README states that costs are calculated from LiteLLM pricing data with a one-hour disk cache, an OpenRouter fallback, and additional handling for Cursor model pricing, including tiered pricing and cache-token discounts. Cost here is therefore an inferred number assembled from a third-party dataset and local token counts, not an invoice.

output: terminal views, JSON, and an optional public leaderboard

The default mode is an interactive terminal UI with ten views (overview, usage, models, daily, hourly, monthly, sessions, projects, stats, agents). For automation, the same commands emit JSON, and grouping can be set per model, per client and model, per workspace and model, or per session and model. That is the difference between a vague monthly total and “this project cost this much last week.” The README also documents a submit command that publishes usage to a social leaderboard and public profile.

what changed in v4.17.0

Release v4.17.0 was published on 2026-09-15, three days after v4.16.0. The release page carries no downloadable assets, so distribution follows the README’s quick start through the npm package:

npx tokscale@latest
bunx tokscale@latest
deno x npm:tokscale@latest

Per the release notes, v4.17.0 is a maintenance release dominated by parser and pricing corrections rather than new capability:

• DeepSeek Harness: read versioned session.v<N>.jsonl transcripts (PR #1328, the first contribution from @satan9394).
• Antigravity CLI: date turns from the steps table timestamps (PR #1327) and read logged ports from the head of per-session logs (PR #1339).
• Codex CLI: group agent usage by thread kind instead of random nicknames (PR #1330).
• Pricing: prefer the standard service tier among an author’s OpenRouter endpoints (PR #1336) and let OpenRouter participate across version-separator spellings (PR #1338).
• Cline: resolve model identity from per-message modelInfo (PR #1340); WorkBuddy: scan 5.5 sessions under ~/.workbuddy-ai (PR #1337).
• TUI: admit Projects tab columns progressively by width budget (PR #1332).

The practical reading: if you already run tokscale, v4.17.0 is worth taking for the Codex and pricing fixes. If you are evaluating it, the change list is evidence about where maintenance effort goes, not a reason to adopt it.

where the numbers can still mislead you

Three items in the open issue tracker bear directly on whether the reported cost is safe to act on. Each was written by its reporter, and the versions they cite are older than v4.17.0, so current behavior on v4.17.0 is unknown without running it, which this review did not do.

unpriced models and a failed submission

Issue #1035 (opened 2026-08-04, still open at this review date, assigned to the maintainer) reports that tokscale submit aborts with “pricing is unavailable for submitted token usage” when local sessions contain models with no pricing entry. The reporter’s examples were a Friendli-hosted model, a free OpenRouter route, and Antigravity sessions with an unresolved model id, on tokscale 4.9.0 under Linux. Releases since then do contain changes in this area: v4.15.1 added “retain unpriced tokens with incomplete cost,” and v4.16.0 added “cap unpriced warning rows and report the aggregate total.” The issue itself has not been closed, so whether v4.17.0 skips unpriced models, submits them with incomplete cost, or still aborts is not something this review can state.

long-context pricing tiers

Issue #862 (opened 2026-07-12, open) reports that for models priced with fields like *_above_272k_tokens, the cost calculation evaluates the context threshold separately per token bucket (input, output, cache read, cache write) and applies above-threshold rates marginally, while the reporter’s copy of upstream billing selects one tier from the request’s total prompt context and applies it to the entire request. The reporter measured an $11.27 undercount across one day of one model using their own billing export, and said the behavior was present in v4.4.1 and appeared to remain. Two later release notes point to per-model fixes rather than a general one: v4.15.0 included “apply xAI long-context rates request-wide,” and v4.16.0 included “apply full-request 272k pricing to gpt-6-astra.” The general issue remains open.

time zones and cross-day sessions

Two open reports cover date bucketing. Issue #993 (open) describes Hermes gateway sessions that span midnight having all of their tokens attributed to the session’s started_at date, so a today view undercounts while the all-time total stays correct. Issue #960, written by the repository owner, describes a deeper problem in the leaderboard pipeline: usage is bucketed by local calendar day, and a rescan under a different time zone can permanently inflate stored daily totals because a regression guard defends the older values. The issue lays out a three-layer fix and names which historical data is unrecoverable. If you intend to use daily or weekly figures for budgeting, this is the class of problem to test against your own data before trusting a trend line.

deployment, platform, and data-handling questions

The README’s quick start is a single command, and the native Rust module is described as required for CLI operation and pre-built for the npm install path. The README also states that the core does parallel file scanning and SIMD JSON parsing and claims roughly 10x faster processing than an unspecified baseline; no benchmark is attached to the evidence reviewed here, so treat the multiplier as a maintainer claim.

Three things need checking before this runs across a team’s laptops:

1. Where the data lives. The tool reads agent session and transcript stores on developer machines, and those stores can contain conversation content as well as token counts. Confirm what tokscale reads versus what it persists, then decide whether a scanning tool with access to that data is acceptable in your environment.
2. What leaves the machine. The submit path publishes usage to a social leaderboard and public profile per the README, and the payload described in issue #960 is aggregated per-device, per-day, per-client usage data. Enabling it is a publication decision, not a local reporting decision, and the evidence reviewed here does not document the full payload. Verify it before enabling submission on managed devices.
3. Network dependence. Cost calculation depends on fetching pricing data with a one-hour disk cache and fallbacks, so a machine without network access has a different accuracy profile. Whether a stale cache changes your reports is worth testing directly.

Platform support is uneven in ways a fleet owner should notice. Issue #1014, opened by the repository owner, tracks 33 pre-existing Windows test failures across seven root-cause groups, with the Windows CI leg left as continue-on-error. The issue states that one group, crush registry discovery returning nothing on Windows, is likely a real bug, and that another, misattributed providers for cc-mirror variants, would produce wrong pricing. It also documents a config-directory case where %APPDATA%\tokscale is used even when a test redirects HOME, and notes that TZ is ignored by chrono on Windows. A Linux or macOS-first pilot is easier to defend than a Windows-wide rollout today.

maintenance signals

The project is active: five releases between 2026-08-26 and 2026-09-15, 5,500 stars and 446 forks in the 2026-09-21 snapshot, and release notes that credit a broad set of outside contributors alongside the owner. The open issue count was 67 at the same snapshot.

Read the contents of those releases, though, and the maintenance load becomes visible. v4.14.0 alone lists dozens of parser, cache, and pricing corrections across Claude Code, Copilot, Antigravity, Droid, Senpi, OpenCode, and others. That is the shape of a tool tracking an ecosystem that moves underneath it, and it means upgrades are not purely optional: a client-side format change can silently reduce your reported usage until you take the parser fix. If your usage numbers feed a budget or a chargeback, budget for the person who owns this tool.

who should consider it, and who should not

a reasonable fit

• Teams already running several agent CLIs or IDE agents, where no single vendor dashboard covers the whole picture.
• Engineering leads who need per-project, per-workspace, or per-session cost attribution and are comfortable consuming JSON.
• Organizations willing to run a local CLI, reconcile its output against provider invoices before trusting it, and keep pace with releases.

a poor fit

• Teams whose need is already covered by a single vendor’s usage dashboard and billing export.
• Anyone who needs authoritative cost figures for billing a customer without reconciliation, given the open pricing issues.
• Environments where scanning local session stores that may contain conversation content is unacceptable, or where publishing usage to a public leaderboard is out of the question.
• Windows-only fleets expecting parity with macOS and Linux today, given the open Windows test failures.

alternatives and questions to ask before you commit

Alternatives worth weighing: per-vendor dashboards and usage APIs (accurate for one vendor, silent about the rest), OpenTelemetry-based collection where a client supports it (the README notes Copilot CLI usage events can be read without OTEL), the ccusage format, which v4.14.0 added as an import format, and a small internal collector if your client list is short and stable. Building your own is defensible when you use one or two agents; it stops being cheap when you need per-session attribution across twenty.

Questions that decide the trial:

• Which clients does my team actually use, at which versions, and are those parsers currently healthy?
• Does the reported total reconcile with one month of provider invoices, line by line, for our top two models?
• What exactly does the submit payload contain, and can submission be disabled for everyone on managed devices?
• Do daily and weekly figures survive a time-zone change on a scanning machine?
• Who owns upgrades when a client changes its storage layout?

A two-week pilot against real invoices answers most of this. The Google Trends entries in the review evidence (gemini and codex, GB) indicate general search demand around those agent names; they say nothing about this project’s quality and played no part in the recommendation.

verdict

Tokscale addresses a real problem: attributing AI coding agent cost across tools. It has an MIT license, an active maintainer, a broad client list, and JSON output that fits automation. It is not an accounting system yet. Pricing is derived rather than authoritative, the long-context tier and unpriced-model issues are still open, and date bucketing has known failure modes. Adopt it as a visibility and attribution layer, reconcile before you budget, and plan for maintenance, because the release history shows the parsers run in a constant race with the tools they read.

sources

• junhoyeo/tokscale repository
• Tokscale v4.17.0 release notes
• Tokscale v4.16.0 release notes
• Tokscale v4.15.0 release notes
• Issue #1035: submit fails when pricing is unavailable
• Issue #862: long-context pricing uses per-bucket marginal tiers
• Issue #960: time-zone re-splits permanently inflate stored usage
• Issue #993: Hermes cross-day sessions bucketed onto started_at
• Issue #1014: Windows suite pre-existing failures
• Issue #1165: request to support the Copilot Chat plugin in Android Studio

how I would approach this with you

If the problem is that your team cannot attribute AI agent spend, the work is usually smaller than a platform project: instrument what you already run, validate the output against invoices, then put the result where a decision-maker can see it. This sits in the AI agent integration and data-flow work I do through XP812’s software development services. To scope it I would need your client inventory with versions, one month of provider invoices, and one machine’s session layout per client. From there I can tell you which parts a tool like tokscale covers, which parts need custom work, and where its numbers should not be trusted. I will not promise a saving before I have seen that data. You can start the conversation here.