v0.12.9 — the speed readout tells the truth

The bug

The live tok/s number on the status line counted streamed deltas and treated each as one token. Its own docstring stated the assumption — "chunks≈tokens on local runtimes" — which is true without speculative decoding and false with it: vLLM MTP emits every accepted draft token in a single delta.

Measured on qwen3.8-27b + qwen3_5_mtp: 214 tokens delivered in 63 deltas over 9.08s. Real rate 23.6 tok/s, displayed 6.9.

So enabling MTP made the model ~3.4x faster and the meter ~3.4x slower. That reads exactly like a performance regression, which is the worst possible failure for a number people use to judge their setup.

The fix

• The live rate is scaled by a tokens-per-delta ratio learned from the exact usage count of each finished stream.
• That ratio is persisted on the model's existing speed-ledger entry, so a new session's first turn is honest — otherwise every session's opening turn, the one you form your impression from, reads low.
• When the ratio has never been measured, the live rate is suppressed rather than assuming 1.0. No number beats a wrong number. The blind window is the first stream ever for a model, not one per session.
• The ratio is only learned from a sample that survived every existing rejection gate, so a run dropped as degenerate still leaves the ledger untouched.

End-of-stream verified rates were always correct and are unchanged — they use the exact token count from usage. Only the in-flight estimate was wrong.

Also fixed: record_tps replaced its whole ledger entry rather than updating it, discarding sibling fields.

If you run llama.cpp or vLLM without speculative decoding, nothing changes — one token per delta, ratio 1.0.

Pre-1.0: interfaces and config schema may still change. Full detail in CHANGELOG.md.