feat(tui): add tokens per second to response footer

[JohnC0de]

Fixes#5374
Closes#6096

Adds a tok/s (TPS) counter to assistant message footers. Shows up right after duration, like: 18.3s · 131 tok/s

Why

I've been switching between providers a lot lately and wanted a quick way to see which models are actually fast vs which just feel fast. Kimi K2.5 clocks ~130 tok/s. Having the number right there makes the difference obvious without needing external tooling.

Screenshot

Kimi K2.5 Free hitting 198 tok/s on a real response

Prior art

#5497 by @edlsh tackled this back in December. It's been sitting for 2+ months now with merge conflicts and CI failures, and a few people in the comments are asking for it to land. Rather than try to rebase that PR, I reimplemented it cleanly on current dev with a different structure: TPS logic lives in core/tokens/ instead of tui/util/ so the SDK and other consumers can use it later without pulling in TUI code.

How it works

processor.ts records a firstToken timestamp when the first output-delta arrives during streaming. TPS is then calculated as generatedTokens / ((completed - firstToken) / 1000), where generatedTokens includes both output and reasoning tokens. Responses shorter than 250ms, tool calls, and errored responses are filtered out.

What I left out

Average/aggregate TPS across a session. Both issues mention it but it felt like scope creep for a first pass. The per-message timestamps are all persisted, so adding a session-level summary later is straightforward.

Testing

34 unit tests cover calculation, edge cases, and filtering. All CI checks pass: typecheck, unit, e2e (linux), pr-standards.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

PR #5497 - "feat: display tokens per second for assistant messages"
#5497

Why it's related: This PR appears to be addressing the exact same feature - displaying tokens per second for assistant messages. It likely covers similar functionality for tracking and displaying TPS metrics in the UI.

[JohnC0de]

@adamdotdevin@rekram1-node — the bot flagged this as a duplicate of #5497, so wanted to give some context.

I reviewed #5497 before starting. It has merge conflicts against dev and failing CI, and @edlsh hasn't been active on it since December. A few people in the comments there are asking for it to land. Rather than try to rebase someone else's branch, I reimplemented it cleanly on current dev with a different structure: TPS calculation lives in core/tokens/ instead of tui/util/ so the SDK and non-TUI consumers can reuse it.

Quick review guide if it helps:

• tps.ts (83 lines) — the whole calculation. Pure functions, no side effects
• processor.ts — only change is recording time.firstToken when the first output-delta arrives
• session/index.tsx — swaps the old inline calculation for getMessageTPS() + formatTPS()
• The rest (message-v2.ts, types.gen.ts, openapi.json) is schema + SDK regen for the new firstToken field

Happy to adjust anything.

[KohliNaman]

i was just looking for this, checked it out on macos, works flawlessly.... Thanks a ton!

[Daltonganger]

Any update on this?

[Daltonganger]

@rekram1-node I investigated the 3 failing checks on this PR.

Root cause:

• e2e (windows) fails because Bun.which("rg") can resolve to an invalid POSIX-style path on Windows.
• e2e (linux) fails because Bun.which("rg") can return a path that exists but is not spawnable (ENOENT at runtime).
• test (linux) is a gate job and fails because upstream e2e jobs fail.

Proposed minimal fix (single-file change): packages/opencode/src/file/ripgrep.ts

• Ignore POSIX rg paths on Windows.
• Probe rg --version before trusting a resolved binary path; fallback to bundled/downloaded rg when unusable.

I can paste the exact patch here if useful.

[Daltonganger]

@rekram1-node I opened a follow-up PR that includes all changes from this PR plus a minimal ripgrep path fix for the failing checks:
#13892

Cross-reference:

• Original PR: feat(tui): add tokens per second to response footer #12721
• Follow-up PR: feat(tui): display TPS metric + minimal ripgrep path fix #13892

[JosXa]

Ship it! 🚀

[FurryWolfX]

I need it

[andrewdunndev]

Nice implementation. The tps.ts utility with the sliding window approach is solid, and the screenshot shows exactly the UX people are asking for.

One thing I noticed while building something similar: the TPS calculation can produce jittery values during the first few tokens of a response (small denominator, large variance). A minimum window before displaying (e.g., wait until at least 10 output tokens before showing tok/s) smooths this out without adding latency to the display.

Also worth noting that @thdxr has #14493 open for the same feature. Might be worth coordinating to avoid duplicate effort.

[Daltonganger]

When is this imported? @rekram1-node

[com30n]

any updates on this?

[bartlettroscoe]

FYI: I wrote a FastAPI proxy for this purpose. It is independent of any coding agent. We will be open-sourcing it soon.

[mirobertod]

Hi, any update on this? Thanks