Silver Token tracker

[ftaboadac]

Token Tracker

A small local CLI that reads usage logs from local AI coding tools (Claude Code, Codex CLI, Gemini CLI) and prints a clean terminal visual of token counts and costs per model.

In response to https://x.com/Conanbatt/status/2051314628547002762

What it does

A developer runs one command and immediately sees their token usage and cost broken down by model and source:

​ npx -y @ftaboadac/silver-token-tracker run ​

No installation of background services, no configuration, no network calls. Just reads logs that are already on disk.

How it works

Each supported tool (Claude Code, Codex CLI, Gemini CLI) writes session logs to known local paths. The CLI parses those logs, deduplicates streaming chunks, aggregates tokens per model, and calculates cost using current API pricing. Output goes to stdout — either as a styled table (run) or raw JSON (--json).

Supported sources

• Claude Code — ~/.claude/projects/**/*.jsonl (default 30-day retention)
• Codex CLI — ~/.codex/sessions/YYYY/MM/DD/rollup-*.jsonl (no built-in retention limit)
• Gemini CLI — ~/.gemini/tmp/*/chats/session-*.{json,jsonl}

Cursor was investigated but is not supported: Cursor 3.1+ stopped writing real token counts to local SQLite (only request IDs remain). Estimating from content length was rejected because it would mix imprecise figures with accurate Claude Code numbers. Full explanation in the parser source comments.

Scope decisions per review feedback

This started as a larger proposal (backend, dashboard, MCP server, team aggregation). Based on feedback from the project owner, it was simplified to a pure local CLI:

• No backend, no Vercel app, no Blob store
• No dashboard, no auth, no env vars
• No MCP server (the developer is already in a terminal — the CLI is the simpler path)
• No team aggregation (project owner indicated this will be handled separately on app.silver.dev)

The result is a tool that's trivial to install, has nothing to maintain, and can be deprecated cleanly when the official Silver version ships.

Distribution

Published to npm as @ftaboadac/silver-token-tracker under the author's personal scope as a reference implementation. The maintainers of silver-dev-org will publish the official version under the Silver repo with attribution per the project owner's plan.

Tested

Verified end-to-end on macOS with real Claude Code logs. The CLI detects available sources, skips missing ones gracefully, deduplicates correctly, and renders the visual cleanly. bun tsc passes from the repo root.

[vercel]

@ftaboadac is attempting to deploy a commit to the conanbatt's projects Team on Vercel.

A member of the Team first needs to authorize it.

[conanbatt]

Epa, a verrr

[conanbatt]

Thanks a lot for this prototype/proposal.

Questions: are these logs backward looking? Can you actually read claude / OAI logs from the last 30 days?

If so, can we just skip running software at all and just read existing logs?

[ftaboadac]

Thanks a lot for this prototype/proposal.

Questions: are these logs backward looking? Can you actually read claude / OAI logs from the last 30 days?

If so, can we just skip running software at all and just read existing logs?

Yes, the logs are backward-looking. Claude Code keeps session JSONLs for 30 days by default (there is a cleanupPeriodDays setting), so a fresh deployment immediately backfills up to 30 days of history on the first run rather than starting empty — most teams will see "their last month" appear as soon as anyone runs the collector. Codex CLI keeps date-organized rollup-*.jsonl files in ~/.codex/sessions/YYYY/MM/DD/ for as long as they exist on disk (no built-in pruning that I'm aware of), so often longer than 30 days

The collector itself is "just read existing logs" — silver-tracker sync --dry-run parses the local JSONLs and prints the result, no backend involved

The reason the rest exists (Vercel app, Blob store, dashboard, SUBMIT_TOKEN) is purely aggregation. The logs sit on each developer's laptop, so to get a team-wide view something has to take N local reads and combine them. The choices are something like (a) "every dev pastes their number in Slack" or (b) "the collector POSTs to a shared place and a dashboard reads it." This PR is option (b), with the minimum surface I could get away with: one POST endpoint, one blob per user, one password-protected page.

If we drop the dashboard/backend, what remains is exactly what the dry-run already does, which should be fine deployment for "I just want to know my own usage." The deployment story is only worth its overhead if you actually want the team view

[conanbatt]

I don't think team views aggregation views are a valid use case in Open Silver. I also think asking people to have running software is onerous and distrustful, so I would make something much simpler right now for comfort and maintenance.

1. Reduce to a client that runs reading the local files. (what you mention is the "dry-run" version) and outputs to the console.

2. Rename silver-tracker to silver-token-tracker

3. The usage instructions are running the commands (npm i silver-token-tracker && silver-token-tracker run).
   The output of run is a terminal output visual of the data.

For the Silver team

1. Once we add support for tracking this information in app.silver.dev we will modify this output to include a magic link to record it on the silver platform, but the silver team will take that on.

2. We will publish the package (with proper attribution) under the silver repo before releasing to the community.

[ftaboadac]

I don't think team views aggregation views are a valid use case in Open Silver. I also think asking people to have running software is onerous and distrustful, so I would make something much simpler right now for comfort and maintenance.

1. Reduce to a client that runs reading the local files. (what you mention is the "dry-run" version) and outputs to the console.
2. Rename silver-tracker to silver-token-tracker
3. The usage instructions are running the commands (npm i silver-token-tracker && silver-token-tracker run).
   The output of run is a terminal output visual of the data.

For the Silver team

1. Once we add support for tracking this information in app.silver.dev we will modify this output to include a magic link to record it on the silver platform, but the silver team will take that on.
2. We will publish the package (with proper attribution) under the silver repo before releasing to the community.

Got it! Will go ahead and implement the updates

[ftaboadac]

@conanbatt Pushed a major simplification:

The tool is now a pure local CLI — silver-token-tracker run reads logs from Claude Code, Codex CLI, and Gemini CLI on the developer's machine and prints a styled terminal table with token counts and estimated cost per model. Also supports --json for piping and --help for usages

Published as @ftaboadac/silver-token-tracker (scoped) as a reference implementation. README clarifies it's not the canonical path and that the official package will be published by silver-dev-org with attribution.

PR description above rewritten to reflect the new scope. Happy to iterate on anything!