October 20, 2026 · Engineering · 3 min read

Counting usage for a tool that does not log tokens: Bumeter and Kiro

#kiro#estimation#architecture

Claude Code writes the exact token counts of every API call into its logs. Kiro does not. Supporting it in Bumeter meant answering an awkward question: how do you show where a tool's usage goes when the tool never tells you? The answer was to measure what Kiro does record, ask it for the rest, and never present an estimate as a fact.

What Kiro leaves on disk

Kiro CLI keeps each session as two files in ~/.kiro/sessions/cli/:

• <id>.json: metadata for every turn, rewritten from scratch after each one;
• <id>.jsonl: the questions, answers and tool calls.

The first difference from Claude Code is mechanical. Claude Code appends lines, so Bumeter reads only what is new since the last offset. Kiro rewrites the whole file, so its adapter declares itself a whole-file source and Bumeter parses the file again when it changes. The rest of the pipeline (the database, the queries, the screens) does not know or care.

Context from a percentage

For each turn, Kiro records how full the context window was, as a percentage, and how big the model's window is. Multiplying the two gives the context the turn carried:

context ≈ context_usage_percentage / 100 × context_window_tokens

If a turn does not say how big the window is, Bumeter assumes 1,000,000 tokens. That makes context a reasonable estimate, but it is not a token count from an API response, and it does not split input from output or cached from uncached.

Credits are real

Kiro bills in credits, and each turn's metadata lists what it was metered. Those numbers are exact, and they are what Bumeter uses for Kiro's cost: credits per turn, per session and per day.

The monthly limit is harder: it is not in the session files. Bumeter gets it two ways:

1. From Kiro itself. At startup and then every 15 minutes, Bumeter runs kiro-cli chat --no-interactive "/usage". That command runs locally, does not call a model and does not create a session. Bumeter first checks you are logged in, gives it 20 seconds, strips the terminal colour codes from its output and reads credits used, the limit, the plan and the reset date.
2. From you. If kiro-cli is not installed or not logged in, you can enter your monthly credits and reset day in Settings.

When both exist, a fresh /usage reading wins. If the reading gets old, the tray says how old ("updated 2 h ago") instead of showing it as current.

With a limit known, Kiro gets the same treatment as Claude's windows: a row in the tray, a percentage ring, and a forecast of when the credits run out at your average pace this month (none in the first two days, when the average is still noise). The forecast post explains the maths.

Saying "estimated" out loud

The most important part of the Kiro adapter is one field. Every tool describes itself to the rest of Bumeter with a SourceInfo, and Kiro's says real_tokens: false. That flag follows the numbers everywhere:

• The app marks Kiro's token figures as estimates.
• bum report says it in the breakdown: Kiro 8.4M (14%, estimated).
• The JSON output carries "estimated": true for Kiro, so a script or an agent can tell too.

The same SourceInfo says what a tool supports: Kiro has credits and transcripts, but no 5-hour windows and no context breakdown. The interface reads those flags, so it never shows an empty Claude-style panel for Kiro, and nothing in the UI has a tool's name written into it.

What this taught us

It would have been easy to multiply percentages by window sizes, call the result "tokens" and put it in the same chart as Claude Code's. The chart would look complete, and it would quietly mix measured numbers with guesses. Bumeter's rule is that every number is either measured or labelled as an estimate, and the label travels with it from the adapter to the screen. When a new tool is added, the first thing to decide is not how to parse it but which of its numbers are real.