add token count at status bar in real-time

[Artenx]

Displaying the real-time token count of the current conversation in the TUI status bar, this helps users check if they are approaching the model context limit.

[Hmbown]

@Marten2016 let me see what I can do about this with the deepseek api - thank you!

[LIYUE1918]

#1756

[LIYUE1918]

#1753

[richardchen874-sys]

This would be a very useful feature for DeepSeek TUI users.
@Artenx

Real-time token count is not only a UI improvement — it helps users understand when a conversation is getting close to the context limit, and it also makes long-session cost easier to reason about.

A few details could make it more helpful:

• current input/context token estimate
• remaining context window
• estimated output token budget
• warning when the session is close to the limit
• optional per-turn token usage after the API response
• maybe a compact “session total” for longer coding/chat workflows

For DeepSeek TUI, this could reduce confusion between “the model is worse now” and “the context is overloaded.” It would also help experienced independent developers manage long conversations more deliberately instead of only noticing the problem after responses start degrading or failing.

[MaeuRodrig]

what do you think about using OpenCode as config/interface reference?

[richardchen874-sys]

OpenCode is a reasonable reference if the goal is to make model/provider config explicit instead of hiding it behind one global setting.

I’d probably borrow the shape, not the whole interface: provider, model, base_url, api_key source, timeout, max tokens, and maybe a per-project override. For a status-bar token counter, the important part is that the UI can show which model/provider the count belongs to, otherwise the number becomes hard to interpret across local and remote endpoints.

Are you thinking of OpenCode mainly as a config-file reference, or as a broader provider-switching UX reference?

[MaeuRodrig]

I usually don't switch provider, so no.
I mean config-file reference to switch between them and decrease the maintenance effort.
The goal would be have the "same" config to get the same result.
I prefer .toml over .json for config file.

[richardchen874-sys]

That makes sense. If the goal is maintenance reduction rather than frequent provider switching, TOML is a good fit because it stays readable once model/provider settings grow.

I’d keep the config shape boring: provider, model, base_url, api_key env var, timeout, max tokens, and maybe tokenizer/counting mode. The important part is that two providers can express the same intent without forcing the rest of CodeWhale to know vendor-specific details.

For the status bar, I’d still show which config profile produced the token count, otherwise the number can become confusing when users compare local and remote endpoints.