Sidebar: show each thread's remaining prompt-cache window

[roulendz]

I keep a dozen threads open across projects and I can never tell which ones have
gone cold. I find out by sending a message and watching the whole conversation
get re-read at full price.

The sidebar row already shows how long since a thread last did anything. It just
doesn't say what that costs me.

So I put a small chip in each row, left of the status label. It counts down the
prompt-cache window: 47m, amber under fifteen minutes, red under five, then
cold. Blank if the row has no timestamp to count from. Hover gives last activity
and the clock time it goes cold, in a card styled like the composer's
context-window popover.

Two things I'd fix before this was real. I built it by patching the shipped
bundle, so my version parses the row text. Inside the app it would read
session.status and the same timestamp resolveWorkingStartedAt already uses.

And the window isn't always an hour. It's an hour on a Claude subscription, five
minutes on an API key, and it drops to five minutes on a subscription too once
you start spending usage credits, unless ENABLE_PROMPT_CACHING_1H is set. A
clock also can't tell when the cached prefix stops matching, which is what
switching model, changing effort, /compact or an update actually do. So the
number is a hint, not a promise, and the copy should say so.

[Vantrongs]

Some research that may help turn this into a feature, checked on 2026-09-27 against T3 main (de251fc), Claude Code 2.1.283 and Codex 0.157.1.

For Claude, the TTL can be read instead of guessed. Every API response breaks cache writes down by TTL: usage.cache_creation.ephemeral_1h_input_tokens / ephemeral_5m_input_tokens. T3 already receives these in the raw events; ClaudeAdapter reads only cache_creation_input_tokens today. That covers the cases you listed (1 h on a subscription, 5 min on an API key or in overage) without T3 re-implementing Claude Code's rules, which also has a separate TTL for subagents, workflows and helper requests (subagentPromptCacheTtl, 5 min unless ENABLE_PROMPT_CACHING_1H=1).

Codex needs different wording. Codex sends only prompt_cache_key (the root session id, shared with its subagents) and no retention option. For GPT-5.6+ and gpt-6-astra, OpenAI documents a lifetime of at least 30 minutes after the latest write or reuse, possibly longer. So for Codex the chip can say "warm" and then "may be cold", not count down to a known deadline. Codex reports cachedInputTokens / cacheWriteInputTokens in thread/tokenUsage/updated, which T3 already maps. Two traps: last is one response, not the whole turn, and right after compaction Codex emits a synthetic estimate with zero cache counters, which is not a cold start.

Rank by what a cold start costs, not by the clock. A cold 20K-token thread is cheap; a cold 400K one is not. At API prices, next request with a warm vs a cold cache:

Thread, 400K context	Warm	Cold
Claude Opus 5.5, 1-hour cache	~$0.08	~$3.20
Claude Fable 5.1, 1-hour cache	~$0.10	~$8.00
Codex gpt-6-astra on an API key (above the 272K tier, where input and cache rates double for the whole request)	~$0.80	~$10.00
Codex gpt-6-astra on a ChatGPT plan (credits)	~10	~100

On a ChatGPT plan, Codex is billed in credits, and OpenAI's rate cards list no 272K multiplier and no cache-write charge for Codex. T3 already has what it needs to compute this: the rate table with its tiers (*_above_272k_tokens, *_above_1hr), the context size (usedTokens) and the Codex sign-in type (account.type). So the chip's colour could follow the cost, or the share of the context window, rather than minutes, and stay quiet once a compaction has shrunk the context.

Compaction. The cheapest action here is compacting before the cache expires; I opened a separate issue with measurements for that: #13988.

Where it would pay off most:

• A composer notice when the cache is likely cold and the cold start is expensive ("the next message re-reads ~400K tokens"), with "send anyway" and "compact first". It could also offer to continue in a fresh thread (Continue a structured handoff in a fresh thread #8754), although feat(web): continue conversations in new threads #8452 was closed as not a priority.
• An optional alert before expiry (in-app, system or mobile push), only above a cost threshold. It is pointless for a 5-minute cache.
• Calibration: the next turn's cache counters show whether it really was cold, so the chip can correct itself.

[n0ah37]

I built a version of this for the composer's context meter: n0ah37#3. The popover shows the time left on Claude's prompt cache, taken from the last usage report plus the lifetime Claude reported. It only updates while the popover is open. If you approve the direction, I'll open it against this repo.

[pBoelck]

I opened #19469 for the same problem before I found this thread, sorry for the duplicate. Linking them so the discussion stays in one place.

There are now two prototypes, and both read the TTL from cache_creation as described above and carry the last TTL forward when a response only reads the cache:

• feat(web): count down the prompt cache in the context meter n0ah37/t3code#3 adds a countdown row to the context meter popover. It ticks while the popover is open.
• My branch adds an always visible chip next to the send button (Cache 46m, yellow shortly before expiry, Cache cold after), behind its own opt-in setting, so it also works with the context window indicator turned off. Screenshot: Show when Claude's prompt cache expires in the composer #19469 (comment)

The main open question for maintainers seems to be where it should live: inside the context meter popover, as a separate composer chip, or per thread in the sidebar as proposed here. One more thing to account for: ixtli reports that Claude Code can compact an idle session at about 90% of a 1h cache window behind a remote flag. If that happens, a client side countdown would no longer match the cache.

Happy to close #19469 in favour of this thread if that's easier to track.