Skip to content

token-bar 0.3.0: a fast status, and warnings for desktop users - #9

Merged
56steve merged 1 commit into
mainfrom
development
Nov 6, 2026
Merged

56steve merged 1 commit into
mainfrom
development

Conversation

@56steve

@56steve 56steve commented Nov 6, 2026

Copy link
Copy Markdown
Owner

What's new

/token-bar:token is fast. On a busy machine every run re-read and re-parsed the whole last week of session logs. On a real 6 GB ~/.claude/projects folder (1.84 GB, 209 files modified in the last 7 days) that took about 21 seconds.

  • Lines that can't hold usage are skipped before they are parsed.
  • The scan remembers how far it got in each log file in ~/.claude/token-bar/scan_cache.json. Logs only grow at the end, so later runs read only what was added.
  • Result: about 0.1 s for repeat runs, about 9 s for the first run. Delete the cache file to start fresh.
  • Checked against the original scan on real logs, using only requests old enough to be stable (the logs grow live): identical requests and tokens, from a cold start and from the cache.
  • Edge cases covered by tests: a half-written last line waits, a file that got shorter is read again, deleted files stop counting, a damaged or too-short cache is ignored, a streamed request keeps its largest count, and a stray invalid byte no longer drops a request.

Heads-up warnings for desktop users. The 80% / 90% warning used live numbers only, so the desktop app never got it. It now uses the synced estimate when there are no fresh live numbers, and says so ("Weekly usage is around 82% (estimate)"). It never warns from a calibration that was not synced, because a false alarm is worse than none. Live numbers still win when fresh. About 0.12 s per message on real data.

hook-check. The hook notes when it runs, and token_bar.py hook-check says when, so we can tell whether hooks fire in the desktop app. This is not yet confirmed.

Checks

  • 130 plugin tests and 22 Codex tests pass; ruff is clean.
  • Version bumped to 0.3.0.

…3.0)

On a busy machine every run re-read and re-parsed the whole last week of
session logs: 1.84 GB, about 21 seconds for /token-bar:token. Now lines
that can't hold usage are skipped before parsing, and the scan remembers
how far it got in each log file (logs only grow at the end) so later runs
read only what was added: about 0.1 seconds, with the first run about 9.
Checked against the original scan on real logs: identical requests and
tokens. A last line still being written waits for next time, a file that
got shorter is read again, and a damaged or too-short cache is ignored.

The 80% and 90% heads-up used live numbers only, so the desktop app never
got it. It now uses the synced estimate when there are no fresh live
numbers, says so ('around 82% (estimate)'), and never warns from a
calibration that was not synced. The hook also notes when it runs, and a
new hook-check command says when, so we can tell whether hooks fire in the
desktop app. Tests, README and skill updated, version 0.3.0.
@56steve
56steve merged commit 5d3fbbb into main Nov 6, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant