Repository navigation
[feature]: color the compact status percentages by usage pace #327
Description
Does this change what you see on screen?
Yes
Your OpenCode version
2.0.29
Your plugin version
5.0.2
What's the problem?
The compact status line (tuiCompactStatus, under the message box) is a single muted line:
OpenAI OAuth 5h 100% 3h 26m, 7d 98% 6d 14h 20m | +2
All the information is there, but you have to read every number to tell whether you are about to
hit a limit. The line is rendered as plain strings in text.muted (dist/tui-v2.jsx, the
lines().map(...) in the compact status component), so a window that is about to run out looks the
same as a fresh one.
A fixed threshold ("red below 25% left") doesn't answer the real question either. 40% of a 7-day
window used on day 6 is fine; 40% used on day 1 means it runs out halfway through the week.
What would you like to happen?
Color each window's percentage by pace: compare how much of the quota is used with how much of
the window has elapsed. Everything else (label, reset time, separators) stays muted.
I had exactly this in my previous plugin (opencode-swap, now discontinued in favor of OpenCode 2's
built-in account switching and this plugin). It looked like this:
The logic, when the window length and reset time are known
(bands.ts):
elapsed% = (windowLength - (resetAt - now)) / windowLength * 100- under 5% elapsed: green (too early to judge, a single request would otherwise flash red)
- otherwise
pace = used% / elapsed% * 100:- below 85: green (comfortably under an even spread)
- 85 to 104: warning (on track to use it all)
- 105 and up: error (on track to run out before the reset)
When the window length or reset time is unknown, it falls back to absolute thresholds on used%:
90 and up error, 70 and up warning, 50 and up info, below 50 success.
Colors come from the theme
(footer.tsx):
text.feedback.error/warning/info/success.base. They follow dark and light themes, and no extra
requests are needed: the window length and reset time are already in the data the line is built
from.
Example on a 7-day window two days in (about 29% elapsed): 20% used is green, 25% is warning, 31%
is error.
Other details:
- It should follow
percentDisplayMode: the color depends on the share used, also when the line
shows the share left (5h 100%above is 0% used). - With several windows on one line, each percentage gets its own color, so a healthy 5h window next
to a stretched 7d window shows both states. - It could be opt-in (for example
tuiCompactStatus.colorize) if a monochrome line should remain
the default. The same rule would also suit the sidebar.
If you accept the idea, I am happy to open a PR for it.
Activity
leinardi commentedon Oct 16, 2026
hey @slkiser I just wanted to ask if this is a feature that you may be interested at all, perhaps as optional opt-in, or if it's something that you are against.
slkiser commentedon Oct 16, 2026
It's in a v6 pre-release right now that you can test
So yes (interested and included).
I even found a secret way to get colors in toasts*
leinardi commentedon Oct 16, 2026
oh nice! sorry I didn't get that was already implemented!
slkiser commentedon Oct 16, 2026
No worries, and thanks for the suggestion in the first place
leinardi commentedon Oct 16, 2026
Hey @slkiser , I tried 6.0.0-beta.1! The colors follow the share left (50/20), and pace shows up as "runs out in" and the even-use mark. What I had in mind is the color itself following pace. Since
paceOf()already sorts each row into spare / on track / fast, would you take an opt-incolors.basis: "pace"that maps those to good / warning / low (falling back to the share left when a row has no window or reset), and holds off on "low" untilMIN_ELAPSED_SHAREof the window has passed?If you are fine with this, I would be happy to send a PR 🙂
EDIT
I've created a PR to show you what I've in mind: #332
slkiser commentedon Oct 16, 2026
Thanks for testing the beta, and for #332! The colors follow the share left on purpose, so it's not a bug. They're already configurable: in
/quota_settings→ Colors you can change each color and the 50% / 20% thresholds. An opt-in pace setting would fit well on top of that.Let me release v6 first. After that, please rebase #332 and I'll review it. One note already: early in a window, a nearly used-up limit should still show red, not yellow.
leinardi commentedon Oct 16, 2026
Thanks! Makes sense that the share-left colors are deliberate, and I'll rebase #332 once v6 is out. I've pushed a fix: in the first tenth of a window (
MIN_ELAPSED_SHARE), a fast pace no longer has a color of its own, and the row follows the share left instead. A nearly used-up limit early in its window is now red (belowcolors.lowBelow), the same as with "left". Pace only takes over once there's enough of the window behind it to mean something.