Repository navigation
tui: token rate uses the final metadata burst instead of model-call duration #46883
Description
Description
The V2 TUI can report implausibly high token throughput when a provider delivers generated usage in an atomic final event.
packages/tui/src/routes/session/rows.ts calculates turn throughput as total output tokens divided by the sum of assistant.time.streamed - assistant.time.created. This excludes the interval before the assistant record/first streamed event.
For an encrypted-thinking Bedrock response, the model worked for 71.051 seconds and returned 4,096 output tokens atomically. The assistant timing span was only 29 ms, so the footer displayed:
1m 11s · 141241.4 tok/s
The number is exactly 4096 / 0.029, even though the full call rate was about 57.6 tokens/s. The duration and throughput therefore use incompatible time spans.
Expected: use a model-call/output-generation span that includes time spent producing an atomic response, or suppress TPS when incremental generation timing is unavailable.
Actual: metadata-only/atomic streams can produce meaningless six-digit TPS values.
Plugins
No response
OpenCode version
opencode2 v0.0.0-dev-18900; current V2 source af332a2 remains affected.
Steps to reproduce
- Construct a user message at time 0.
- Construct its assistant response with time.created = 71022, time.streamed = 71051, time.completed = 71051, and tokens.output = 4096.
- Render the session footer with session.tps enabled.
- Observe 1m 11s · 141241.4 tok/s.
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the detailed report and the exact numbers, they made this easy to check.
I reproduced it with a simulated model that stays silent for 5 s, then returns its whole answer in one chunk with 4096 output tokens. Your build (
v0.0.0-dev-18900) wasn't available to install, so I used 2.0.6, the last release from before the fix:5.0s · 585142.9 tok/s, the same broken calculation you describe.dev(629d9e2): the same run shows5.0s · 816.4 tok/sand5.1s · 815.6 tok/s. The rate now uses the whole model-call time.It looks like this was fixed by 2a132d6 ("fix(tui): include provider latency in TPS", released in v2.0.7). That change records the start of the step before the provider request is sent, instead of when the first streamed event arrives. The commit you cited (
af332a2363, from 2026-09-02) is older than that fix.Updating to the current release should fix it. The bot will close this issue in 1 day unless you reply that it still happens on a newer version.
opencodejr commentedon Oct 29, 2026
Closing this as completed, since there's been no reply in the last day. We were waiting to hear whether you still see this on a recent release.
To recap: I reproduced the inflated rate on 2.0.6 (
5.0s · 585142.9 tok/swhen the model sends its whole response at the end). On 2.2.0 and the latestdev(629d9e2), the same run gives about 816 tok/s, which is the rate over the full model call. The fix is 2a132d6 ("fix(tui): include provider latency in TPS"), first released in v2.0.7, so updating to the current release should be enough.If it still happens on a newer version, please comment here or open a new issue with your version and provider/model. Thanks again for the clear report!