Kelviq has released tare — an open-source skill (MIT license) for Claude Code that reads local session logs and calculates actual token usage per API request, with breakdowns by project, model, file, MCP server, skill, and subagent. The key methodology is accounting for "amplified tokens" — the cost of re-sending read files in the context of each subsequent message. Everything is calculated locally, without network requests, so a Claude Max user who suddenly hits a limit finally gets not a mysterious number, but a specific culprit.

image
image

What happened

Kelviq published tare — an open-source skill for Claude Code under the MIT license. The skill parses local Claude Code session logs and calculates actual token usage per API request, compiling attribution into an HTML report with charts. Available commands: /tare report [days] for a full report, /tare usage — a panel similar to the built-in /usage but with attribution by culprit, /tare window — fill level of the 5-hour limit window, /tare week — weekly summary, and /tare share [days] — an anonymized .md summary without prompts, paths, or identifiers. Installation is a single command: npx skills add kelviq/tare -g -y --copy --agent claude-code. Requires macOS or Linux and Python 3.9+; processing is fully local with no network requests.

Context

Claude Max subscription usage hits 5-hour and weekly limits, and they're consumed not only by the human's own messages. Background scripts, MCP servers, and hundreds of short parallel automation sessions are nearly invisible: the built-in /usage panel shows only the overall remaining balance. Kelviq's blog cites a case where 1,555 hidden sessions with 9,022 requests were recorded in one day versus 93 requests from the human — the main load was created by automation, not the author. The second reason for sudden spending lies in the context window mechanics: a file read at the start of a long session is re-sent in the context of each subsequent message, so short sessions are cheap while long ones explode in price. Naive log parsing distorts the picture: according to the author's estimate, due to duplicate responses in logs, it overstates usage by up to 86%.

Why this matters for the industry

For the industry, tare is interesting not as a counter but as a template for a new class of tools: an agent analyzes its own logs directly on the user's machine, which the authors call self-forensics. This is a ready-made product matrix for similar audit skills for Codex, Cursor, and other agents — the materials themselves already suggest asking the agent to port the approach. Correct attribution of context cost gives builders the first step in agent unit economics: it's visible that long sessions become more expensive due to context re-sending, which directly affects memory and RAG design. The logic of the material is that a category of AI agent spending observability (agent FinOps) is emerging: while external parsers like tare fill the gap, vendors may eventually build native context cost attribution into agent frameworks themselves, and anonymized .md summaries could become a format for exchanging spending profiles between teams.

Why this matters for users

If you work in Claude Code on macOS or Linux, the benefit is immediately available: after one-command installation, just ask in English "where did my tokens go this week" — instead of a wall of numbers, you'll get a specific limit culprit: a specific MCP server, skill, or file that's re-sent in the context of dozens of messages. /tare window will show how full the current 5-hour window is, and /tare usage will replicate the familiar /usage panel, but with attribution. Privacy here is verifiable, not declarative: the code is open under MIT, everything is calculated locally without network requests, SECURITY.md describes how to verify with a single grep command that the scripts don't make external calls, and /tare share outputs an anonymized .md summary that's safe to publish. If you're using Codex or another agent, the skill won't work yet — you'll have to wait for a port or ask the agent to make one.

What's still unknown / limitations

The methodological base is still authorial: the claim of 86% overstatement in naive counting was made "on test data" without describing how duplicates are detected or what was taken as the baseline — this is a vendor estimate that no one has independently reproduced yet. The case with 1,555 hidden sessions is a vivid but single illustration from one vendor, not population statistics. Phrases about "the first practical observability layer" and "a new class of products" are market generalizations: from an engineering standpoint, this is a solid log parser with a well-thought-out attribution scheme, without benchmarks or independent measurements. Predictions about ports for Codex and Cursor and native attribution within agent frameworks are interpretations based on the material's logic, not declared company plans.

Sources

Author

Look at AI, editorial team