[FEATURE] Show cached token count and break-even estimate in /model switch dialog

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Currently, when you switch models mid-session with /model, the warning that pops up is helpful, but vague. The message in question:

Switch model?
Your next response will be slower and use more tokens

This conversation is cached for the current model. 
Switching to Sonnet 4.6 means the full history gets re-read on your next message.

1. Yes, switch to Sonnet 4.6
2. No, go back

That's it. How many tokens are currently cached? What is the impact on cost or usage percentage? Is this going to be a major hit, or is this a minor issue? The dialog provides no context at all, so the user cannot make an informed choice. This is especially difficult considering some prior issues also highlight low visibility into cache hit/miss in a session. However, this feature request is much tighter in scope: it only asks to surface relevant numbers alongside the model-switch prompt.

I suspect this is a common point of hesitation. As it stands, the warning and confirmation are appreciated, but offer no actionable advice. It's likely this only increases in frequency as Anthropic releases more models (e.g. Fable and Opus swaps).

Proposed Solution

For convenience, the simplest change that would noticeably improve the flow is to simply display the current cached token count, rather than force the user to guess, or waste time flipping over to /usage just to type /model all over again. Just adding to one pre-existing line would save some time:

This conversation is cached for the current model (currently cached: [#] tokens)

A more helpful version would include a rough estimate of the tradeoff or break-even point. If you switch to a less powerful, cheaper model, you are essentially paying a one-time tax in the hope that it will eventually result in usage savings overall. Make that explicit, and use prior session or historical usage data to estimate the number of turns until break-even:

You'll come out ahead after roughly N-M more turns with the new model (actual usage will vary)

Of course, this estimate might not be perfect due to natural variation, differing verbosity of the models, changing mixes of input and output tokens, and future cache reads. However, I suspect even a general order-of-magnitude preview, or a plausible range, would still improve on the current situation. Nearly doubling session length just to break even is a very different ballpark than a small handful of simpler lower-reasoning edits proving their worth in just a few turns. More sophisticated approaches are possible and even welcome, but a simple rule of thumb ought to be enough.

Alternative Solutions

It is possible to consult /usage for token counts, including cache hits, but there are two problems. First, this is disruptive to the workflow: locating the information alongside the decision is much better than forcing a user to cancel the prompt, check the data, and then return to the decision.

Second, the mental math when forecasting yourself is unreliable and assumption-prone. For example, you can figure out based on API prices that Sonnet 4.6 is about 40% cheaper than Opus 4.8, but how fast can it catch up? Can you predict how output or input-heavy your next few turns are going to be? How big is the offset relative to how much longer the session will last? Deliberately developing intuition is possible but adds friction, and because models and Claude Code itself change rapidly, such intuition goes stale quickly.

It is also possible to spawn a subagent, but that is largely a different workflow paradigm and may not be suitable for all situations, and furthermore comes with its own usage estimation challenges.

Optionally, if using /model to upgrade instead, the same language could also estimate approximately how much more expensive per-turn the session will be after the one-time cost hit.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

I'm well into a design-heavy session with Opus 4.8 and have resolved some tricky questions about the architecture and approach. I suspect the rest of the work will largely be mechanical in nature. Knowing this, I consider switching to Sonnet 4.6 but am confronted with a dialog that reminds me this is not free. I have essentially three options:

• Verify I'm at a good checkpoint and that enough context persists to start up a fresh session
• Spawn specific subagents with their own provided context for the bulk of the tasks
• Go ahead and switch to Sonnet, eating the cost and crossing my fingers that I come out ahead

With an estimate, I can reason a bit: "It says in another 4-6 prompts the lower model will be worth the swap; I think it will just be another round or two of edits and I'll stay on the bigger model" or "Actually, looking at my progress, I think that even though the edits are fairly simple, there will be a fair number of them and I'd like to have more back-and-forth while doing so; the switch makes lots of sense here". This is easier for new users, plus the increased agency and control reduce frustration regarding usage limits.

Without an estimate, I might back out, check /usage, do some break-even math in my head, and then compare with a rough estimate of how much work is left to do. This still requires some level of hope, not to mention a somewhat detailed understanding of the price structure and impact on my session limits. In practice, however, I might just burn the expensive model on trivial work, since it's at least predictable, or start a new session, since the behavior is easier to grasp and direct (albeit with a risk of silently dropped key context). While a question like this is never going to be easy and experience always helps, I believe more information is better, even if imperfect, and gives the user something to quickly build intuition on.

Additional Context

_No response_