The test timed its replies over a wait shortened from John's (first
content at 1.3 s, the end at 4 s). The held call is told held when its
flow (~245 ms for the 236 ms burst) is under a quarter of its window
from its first text (usage.HeldShare); a 2.5 s window put that bound at
~620 ms, so a single pause of ~400 ms that split the burst crossed it.
macOS CI under -race read flow 856 ms, ms 4517 (517 ms late) and
176 tok/s: one ~520 ms pause mid-burst.
Reproduced by injecting the pause (not rerunning): a 520 ms sleep in
the fake before the 25th write of the chat held call read 182 tok/s,
flow 773, ms 4405, as CI did. The classifier is right about such a
stream; the fixture sat too near its threshold. The wait is now first
content at 0.5 s and the end at 7 s: a 6.3 s window bounds flow at
~1.6 s, and the steady 50 tok/s reply stays within its 20% with a pause
as long.
Run:
- injected 1 s pause in the chat held call, held answer, steady, and
in all nine replies: ok each; a 2 s pause still fails the held call
(flow 2621), so the bound is where the comment says.
- break by hand: HeldShare check off -> the three held calls read
84 tok/s, red; ThinkPace check off -> the three held answers read
~2,237 tok/s, red.
- go test -race -count=10 -run '^TestKimiHeldBurst' ./internal/gateway/ ok.
- gofmt -l clean; go vet darwin/linux/windows ./internal/gateway/ ok.
yetone
9e35eef336