[Bug] Status line prompt_cache.expires_at stuck at ~5m after 2.1.300 keepalive

Bug Description
Status line prompt_cache.expires_at stuck at ~5 min since 2.1.300 (cache keepalive), plus a question on keepalive cost What happened Since 2.1.300 my status line cache countdown shows 4–5 min forever, even while the session sits idle. My main-thread cache used to show ~1h (Max/Pro subscriber, 1h TTL). I captured the prompt_cache object every 5 s for 4 idle minutes: - requests stays at 28, misses 0, ttl "5m" - expires_at - now goes 301 → 276 s, then jumps back to 301 exactly every 30 s Cause, as far as I can tell from the 2.1.300 binary 1. The TTL detection now prefers "5m": if a response has any ephemeral_5m_input_tokens, the request is recorded as "5m", even when most of the prefix was written at 1h. In 2.1.299 it preferred "1h". 2. The new keepalive (POST /v1/messages/cache_touch every 30 s for up to 60 min of inactivity) calls touch(), which moves lastActivityAt forward. expires_at therefore always reads now + ≤5 min. So the cache is kept warm for ~1h, but the status line field can no longer say when it will actually expire. It always says ~5 min. Neither change is in the 2.1.300 changelog. Requests - Expose the real expiry to status line scripts, e.g. prompt_cache.keepalive_until (end of the 60-min window), or set expires_at to that value while keepalive is active, plus a keepalive_active flag. - Document the keepalive in the changelog and docs. - Please clarify whether cache_touch calls count against subscription usage limits (5h / 7d) or are billed as cache reads. A ~100k-token session gets 2 touches per minute for an hour, so this matters. Version: 2.1.300, macOS

Environment Info

• Platform: darwin
• Terminal: Orca
• Version: 2.1.300
• Feedback ID: ab4e6eb1-3687-4cba-9aa6-ff15aaf1626e