feat(widgets): allow speed widget windows up to an hour - #769

What

The rolling window on the Input, Output and Total Speed widgets now goes up to 3600 seconds (an hour) instead of 120. The editor keeps a typed 600 or 3600. Anything longer saves as 3600, the same way values above 120 used to save as 120. 0 still means the whole-session average.

Why

The 120-second cap came in with the speed widgets in #141, and no reason was recorded for it. Nothing in the calculation needs it:

• Every render reads the whole transcript, whatever the window. The window only chooses which of the collected responses count.
• The window ends at the transcript's last entry. It counts only the time from each prompt or tool result to its response, so idle time between turns doesn't thin it out.
• A window longer than the session gives the same figure as the session average.

So the cap only rules out windows someone might want, such as the last 10 minutes or the last hour of a long session. Those smooth out the swings of a two-minute window without going all the way back to the start of the session.

Measured with two made-up transcripts, 40 minutes and 2 hours long. Each has one 20-second response a minute at 60 output t/s, then 30 t/s for the last 10 minutes and 15 t/s for the last 2. The line has five Output Speed widgets with windows of 0, 120, 600, 3600 and 36000 seconds:

The built CLI prints the same under Bun 1.4.2 and Node 26.10.0. On main, every window above 120 reads as 120. On this branch, 600 covers the last 10 minutes, and on the 40-minute session 3600 matches the session average.

Render time doesn't depend on the window. Over a 100,000-line (11.9 MB) transcript, the built CLI took 180-189 ms under Bun and 391-412 ms under Node, for windows of 0, 120 and 3600 alike (7 runs each).

Why an hour rather than no limit: once a window is longer than the session, it gives the session average, and 0 already gives that. A limit loses nothing, and it stops a typo such as 36000 from quietly meaning the whole session. In the 2-hour row, 36000 reads as the last hour (54.5) and not as the session average (57.3).

How

• MAX_SPEED_WINDOW_SECONDS goes from 120 to 3600. Every clamp reads it: saving from the editor, reading a widget's saved window, and the list of windows the render asks the transcript scan for. The scan (normalizeSpeedWindows in jsonl-metrics.ts) has no upper limit of its own. windowedSpeedMetrics is keyed by the clamped value on both the request side and the lookup side, so nothing else changes.
• The window editor already accepts any number of digits and clamps on Enter. So 3600 can be typed, and a longer value saves as 3600. Its prompt reads the constant and now shows (0-3600).
• The three widget descriptions and the speed widgets' entry in docs/USAGE.md now say 0-3600.
• Saved windows read the same as before, because the editor never saved more than 120. A value above 120 written into settings.json by hand used to read as 120; it now takes effect, up to 3600.
• Left as is:
  • The editor row label stays in seconds ((600s window), (3600s window)). The editor takes seconds and the label repeats the number typed. Switching to minutes for round values would show 10m for a typed 600 next to 90s for a typed 90.
  • The README's v2.2.0 release notes still say 0-120, because they describe that release.

Demo

In the line editor: select Output Speed, press w, clear the 0, type 600, press Enter and save with ctrl+s. Before, the row then shows (120s window); after, it shows (600s window). The TUI preview only has sample values, the same for every window, so each GIF then quits the TUI and pipes a payload through the CLI with the saved settings.

The transcript in that payload is synthetic, written for the demo. It covers 25 minutes in five turns, with idle gaps between them. Every response runs at 30 output t/s, except the three in the last turn, which run at 80 t/s within the transcript's final 70 seconds. That gives three different figures: 35.0 t/s for the session average, 40.0 t/s for the last 600 seconds and 80.0 t/s for the last 120 seconds. The before GIFs end on 80.0 t/s, the 120-second figure, because the 600 was saved as 120. The after GIFs end on 40.0 t/s, the 600-second figure. Rendered directly with windows of 0, 120 and 600 seconds, main reads 35.0, 80.0 and 80.0, and this branch reads 35.0, 80.0 and 40.0.

Powerline

Before:

After:

Plain

Before:

After:

Testing

• On main as of [low] perf(claude-status): hold a lock while the status page fetch is in flight #635 and [medium] perf(git-review): key the PR cache through the cached runGit #639 (62a371b): merges cleanly, bun run lint is clean, and bun test gives 3711 pass, 0 fail. The built CLI under Bun 1.4.4 and Node 26.13.0 matches main in plain and Powerline mode with the baseline configs, and the TUI opens and exits cleanly.
• bun test: 3176 pass, 0 fail (179 files). main has 3168 pass (178 files).
• 8 new tests and 4 changed ones. 10 of them fail on main:
  • the 4 changed tests, which expected 120;
  • 6 new tests: a one-hour window is stored, rendered and labelled; the editor prompt shows 0-3600; the editor saves 600 and 3600; the editor clamps 3601 to 3600.
• The other 2 new tests pass on main. They check that a saved 120-second window reads and saves unchanged.
• The new editor test file passed 15 runs in a row.
• bun run lint is clean.
• Under vitest on Node 26.10.0, the three changed test files pass: 35 tests. Run against main's code, the same 10 fail.
• The built CLI renders the same under Bun 1.4.2 and Node 26.10.0, in plain and Powerline mode. With an Output Speed widget that has no window set, it also renders the same as main. The TUI opens and exits cleanly under both. Windowed renders are in the table above.