opencode Tokens Per Second: How to See Them

Part of the reduce AI coding agent token usage pillar, and a companion to the opencode-specific guide.

Does opencode show tokens per second?

No. There is no built-in tokens-per-second readout in opencode as of September 2026, and the feature request asking for one has been open for close to nine months. That is the short answer, and it is worth stating plainly because the search results for this question are full of pages that describe a feature that does not exist. opencode reports tokens and cost after the fact through opencode stats. It does not report a rate while the model is answering. There are three ways to get a rate today: wait for the pull request that adds it, install a community TUI plugin, or compute it yourself from a wall clock and the token count. All three work. Only one of them tells you anything useful about your bill, and it is not the one most people are looking for.

What is the status of the official feature request?

Open, popular, and unmerged. The request is issue #5374, "[FEATURE]: show tokens / second". It was filed on 11 December 2025 and is still open, with 109 reactions and 20 comments at the time of writing. For a single-line feature request in a repository this size, that is a lot of agreement about a small thing. The implementation exists too. Pull request #12721, "feat(tui): add tokens per second to response footer", adds the rate to the TUI response footer. It was opened on 8 February 2026 and was last touched on 30 August 2026, still open. So the state of play is: everybody wants it, someone wrote it, and it has not landed. If you are reading this and your response footer already shows a rate, that PR merged after this page was written. Check the footer before you install anything.

How do you get a tokens-per-second meter today?

Install opencode-tps-meter, a community plugin that puts a live rate and a visual bar into the TUI. It is published on npm as @johannus22/opencode-tps-meter. The latest version is 0.1.2, published on 8 April 2026, and it has not been updated since. Three versions exist in total. A separate fork, ChiR24/opencode-tps-meter, targets both opencode generations as side-by-side binaries. Two things follow from those dates, and both matter more than the feature itself:

Neither is an official plugin. They hook the TUI, they are maintained by individuals, and opencode's plugin surface is not a stability contract. Treat them the way you would any third-party extension that sits in the path of your editor.
0.1.2 has been frozen for five months. That is not automatically a problem for something this small, but a TUI plugin that has not been rebuilt against five months of upstream releases is a plugin you should expect to break on an upgrade, not one you should be surprised by when it does.

If you want the number without adding a dependency, you can get it with a stopwatch. Time one response, read the token count for that response out of opencode stats --days 1, and divide. It is crude, it captures a single sample rather than a live average, and for the comparison most people actually want — is provider A faster than provider B on the same prompt — it is entirely sufficient.

Why does throughput not tell you what a session costs?

Because tokens per second measures how fast tokens arrive, and your invoice measures how many arrived. This is the part that gets skipped, and it is the reason the number disappoints people who install the meter expecting it to help with spend. A model running at 120 tok/s that re-reads the same four files eleven times is more expensive than one running at 40 tok/s that reads them once. The fast one finished sooner and cost three times more. Rate and cost are not merely different numbers, they frequently move in opposite directions: the providers that serve fastest are often the ones you are paying a premium to, and a slower model that needs fewer turns can end the session having spent less. There is a second reason the rate flatters. Throughput is usually quoted on output tokens, because that is the stream you watch arrive. But in agent traffic, input dominates output by roughly an order of magnitude — every file read, every command's stdout, every re-sent conversation turn is inbound. A meter watching the output stream is watching the small side of your bill go past. So the honest framing is: tokens per second answers "which provider answers fastest". If the question underneath was "why is this costing so much", it is the wrong instrument, and the input/output split from opencode stats is the right one. There is a full breakdown of those flags in the opencode token usage guide.

What should you measure instead?

The input/output split first, then the tool calls that produce the input. Run opencode stats --days 7 --tools 20. Two numbers decide everything that follows:

The input/output ratio. For nearly every agent workload input dominates. That settles where effort is worth spending: on what the agent reads, not on what it writes.
The tool ranking. Tool calls are where tokens enter the context. The top three tools in that list are your bill.

What stats cannot do is tell you that 300k of last week's 800k read tokens were the same handful of files fetched over and over. It is retrospective and aggregate. Catching repetition needs a live view of the session, which is a different class of tooling — the general case is covered in how to measure agent token usage.

How to apply this today

Check the response footer first. If PR #12721 has merged since this was written, you already have the number and need no plugin.
If you want a live rate, install @johannus22/opencode-tps-meter and accept that it is unofficial and frozen at 0.1.2.
If you only need a one-off provider comparison, time a single response by hand instead. One number, no dependency.
Then stop looking at the rate. Run opencode stats --days 7 --tools 20 and read the input/output split.
Attack the top tool in that ranking. In practice it is whole-file reads or unfiltered command output — filtering command output is usually the fastest single win.

What goes wrong (anti-patterns)

Optimising for the rate. The failure mode is switching to the provider with the highest tok/s and watching the monthly bill go up. It happens because the meter is visible and continuous while the invoice arrives once a month, so the fast number wins the attention it does not deserve. Reading a rate as a health check. A low tok/s figure means the provider is slow right now. It does not mean the session is going badly, and a high one does not mean it is going well. A session that is thrashing — re-reading, re-planning, re-running the same failing command — can post excellent throughput the entire time. Installing the plugin to answer a cost question. If the reason you searched for this was a surprising invoice, the meter will not help, and the twenty minutes spent installing it are twenty minutes not spent on opencode stats. Treating an unofficial TUI plugin as permanent. It is at 0.1.2, published in April 2026, and unchanged since. Pin your expectations accordingly.

See also:

Reduce AI coding agent token usage — the pillar
How to reduce opencode token usage — the flags, the levers, the costs
How to measure agent token usage — catching repetition a retrospective total hides