Thanks for this PR!

What this does: Adds a live per-session tokens-per-second (TPS) indicator in the sidebar, replacing the old global tpsStat chip in the header. Each streaming session now shows its own TPS value next to the session attention indicator.

The approach looks correct:

• _tpsWindow as a per-session rolling 5-second buffer of raw readings
• _refreshTpsLabel(sid) computing the average and throttling DOM updates to once per second — avoids thrashing during fast streams
• Hiding the spinner/TPS value on hover and when chat menu is open (so the menu button is accessible) is a thoughtful UX fix
• Skipping DOM rebuild while chat menu is open prevents the menu from closing unexpectedly during a streaming poll

The diff is large (692 additions, 922 deletions) and touches metering.py, streaming.py, sessions.js, style.css, ui.js, and index.html — plus 7 test files. This is a significant refactor. A few things for the reviewer to focus on:

1. The ui.js changes are large (-742 / +187). What was removed? The summary doesn't describe ui.js changes beyond the TPS slot.
2. The added plan file (.hermes/plans/2026-06-18_hermes-webui-chat-history-wal.md) appears unrelated to the TPS feature — is that intentional?
3. The first_token_ts change in metering.py — was it previously set after the metering stat was computed? Worth confirming the fix direction is correct.

Overall the core TPS display feature looks well-designed. The large diff warrants careful review before merge.

Sorry for the mess. I want to be upfront about what happened rather than just push a clean commit and move on.

The short version: this is my first real contribution to a repo that moves this fast, and I got sloppy with mixing concerns across multiple sessions without rebasing or splitting things out properly. The TPS feature itself is solid, the rest is a learning curve.

What went wrong:

• The .hermes/plans/2026-06-18_hermes-webui-chat-history-wal.md file was accidentally included, it belongs to a different branch (fix/chat-history-wal-recovery) and has no business in this PR. I've force-pushed to remove it from the history entirely.
• The diff is large because I let this branch accumulate fixes over multiple days rather than rebasing or splitting them into focused PRs. The TPS display (7b59d6a onward) is the core feature, but it's buried under right-click guards, draft preservation, queue drain fixes, and UI test updates that should arguably be separate commits or even separate PRs.
• The ui.js changes are bigger than they need to be. I removed the old global TPS chip and its update loop as part of the TPS feature, but some of the surrounding changes (the setBusy rework, busy-input send actions) are from parallel work that got merged in during the rebase rather than being kept separate.

What I'd do differently:

• Keep the TPS feature in a clean branch and rebase onto master before opening the PR, rather than accumulating fixes on top.
• Split the non-TPS fixes into separate PRs or at least separate commits with clear commit messages.
• Be more careful about what lands in a given branch, the plan file and the WAL work should never have touched this branch at all.

On the first_token_ts question: yes, the fix moves first_token_ts to _mark_start() so it's set immediately when the stream begins, before any reading is recorded. Previously it was set inside _record_reading() which runs after the stat update, so a session that had started but not yet recorded a reading would incorrectly show first_token_ts = 0. This caused get_stats() to exclude it from the active session count. The fix direction is correct.

Recommended path forward: Drop the plan file, then I can either (a) split this into focused PRs, or (b) if you're comfortable with it, merge as-is with a note that subsequent clean-up PRs will follow. The TPS feature itself (7b59d6a through 8c2eb88) is the part that matters for this review.

Thanks for the honest write-up, @JKJameson — this kind of transparency about what happened is genuinely useful for reviewers.

A few thoughts based on what you described:

On the accidental plan file: Good that you force-pushed to remove it from history. For future reference, a quick git log --oneline origin/master..HEAD before opening the PR is a useful check for files that shouldn't be there.

On the diff size: The maintainer will ultimately decide whether to merge as-is or ask for a split. Given that the TPS feature commits are identifiable (7b59d6a onward as you note), it's tractable to review even without splitting — as long as the non-TPS changes are correct and don't introduce regressions. If the maintainer wants a cleaner history, the path forward is probably: close this, open a focused TPS PR from 7b59d6a forward, and file separate PRs for the other fixes.

On the first_token_ts fix: The description makes sense — moving the assignment to _mark_start() so it's set immediately when the stream begins, before any reading is recorded, is the right behavior. A session that has started but not yet recorded a reading should still count as active.

Suggested next step for maintainers: Review the TPS core commits (7b59d6a–8c2eb88) first. If those look good, the question is whether the surrounding changes (setBusy rework, busy-input send actions, right-click guards, draft preservation, queue drain) are clean enough to merge together or warrant their own PRs.

Hold — skipped XSS sanitizer tests must pass before merge

Thanks for the TPS-per-session feature, @JKJameson! The core metering work looks well-structured. A few things need resolution before this can merge:

1. Skipped XSS tests — the PR commits include:

   skip: XSS sanitizer tests not yet on this branch

   TestRendererSanitization (7 tests) and TestRawPreCodePreservation (1 test) are marked @pytest.mark.skip. We cannot merge a PR that skips existing tests. Please rebase onto current master (commit 9f269a4) to pick up the XSS sanitizer that's already there, then confirm all 8 tests pass.

2. _HOUR_SECS / rolling HIGH/LOW history removal — the metering PR removes the 60-minute rolling history for high/low TPS tracking. That's fine if the frontend no longer uses those fields — please confirm the UI doesn't consume high/low from the metering event, or that it gracefully handles them being absent.

3. Draft commit — one commit is titled cleanup: remove filter-branch backup artifacts which suggests stale git history artifacts. Please double-check the branch history is clean.

Once the rebase is done and all tests pass (full pytest tests/ run), we'll pull this right in — the per-session TPS indicator is a great feature!

XSS tests: Rebased onto origin/master

high/low rolling history: Confirmed no frontend consumption. Updated the stale docstring in api/metering.py which still described the removed 60-minute rolling history.

cleanup: removed filter-branch backup artifacts.

Re-reviewed after the 2026-04-30 push. The skipped XSS sanitizer tests are now rebased and passing, the stale 60-min rolling-history docstring in api/metering.py is updated, and filter-branch backup artifacts are cleaned up. CI is green across 3.11 / 3.12 / 3.13.

Adding ready-for-review label — flagging as a candidate for hold removal in the next maintainer pass. Per house policy on UI-surface PRs of this size (449 LOC, 13 files), this will get an independent review pass once the hold is lifted, before merge.

Thanks for the persistence and the transparent write-up about the workflow earlier.