feat: real-time output speed (tok/s) indicator — expose statusline/usage-delta to plugins #48067

Summary

There is no way to see a live output speed (tok/s) while a model streams in the TUI, and no supported API for a third-party plugin to add one.

What I checked (opencode 1.18.29, Linux)

1. opencode.json / tui.json / env vars expose no token-rate display option.
2. @opencode-ai/plugin/tui type surface advertises a full TUI plugin API (TuiSlotMap with home_footer, session_prompt_right, sidebar_footer, app_bottom, etc., plus api.slots.register / api.event.on), but the runtime does not deliver it: an auto-discovered plugin file exporting tui is invoked with the server PluginInput (client, project, worktree, directory, serverUrl, $), and api.slots / api.event / api.theme etc. are undefined. Only a client with tui/event/pty namespaces is available.
3. The one rendering-ish control that does exist — client.tui.showToast — neither resolves nor draws when called from a plugin (server- or tui-export). The promise never settles and no toast appears on screen. appendPrompt etc. are in the same control family.

Suggested implementation

For streaming tokens/s we need two pieces:

• Exact per-delta token counts in the stream. Today message.part.updated only carries the cumulative part.text; real tokens.output only arrives on message.updated at the end. Providers stream usage, and most estimate tokens/s by dividing characters — please surface a per-part or per-message.part.delta token delta (even approximate) with a timestamp so any consumer can compute an accurate instantaneous rate.
• A statusline surface for plugins (or a built-in). Either:
  • expose the already-built slots/TuiSlotPlugin host surface to third-party plugins (fix the tui export input so it receives the documented TuiPluginApi), and document authoring (.tsx + Solid), or
  • ship a built-in optional live tok/s indicator in the message footer / header (the prompt bar already shows a context-token meter), toggled e.g. from the command palette.

Also worth fixing: client.tui.showToast should resolve and render for plugin callers, not hang forever.

Workaround (reference implementation)

Since a persistent in-TUI meter isn't reachable, I built a stop-gap for headless/scripted usage that reconstructs the stream from opencode run --format json and prints a live ⇣ N tok/s line plus an exact final average (calibrated on provider usage):

opencode run --format json "explain X" | oc-meter

oc-meter (TypeScript/Bun) is intentionally small and mirrors the estimation/calibration math the statusline would need. Happy to adapt it into a PR once a slot or event delta exists.