Where does the bug appear (feature/product)?
Grok Bot
Describe the Bug
At 2026-09-24 06:03 UTC, grok-bot-default usage rows change in two
ways at the same moment:
- Almost every row starts reporting an explicit cache-write column
(previously almost all input was “without cache write”). - Cache no longer survives a gap longer than about five minutes.
Same traffic before and after that timestamp:
- Gap 5–60 minutes: before 06:03 UTC most turns still hit cache;
after 06:03 UTC almost every turn is a cold rewrite (cache read 0,
full context written again). - Gap under ~5 minutes: hit rate is almost unchanged.
- After 06:03 UTC a repeated row shape appears: cache read exactly
565 tokens, then a large cache write. Only a 565-token prefix is
reused.
This is not the usual “each turn re-reads the conversation.” That
already appears as cache read. After 06:03 UTC a quiet 15–60
minute gap (routine, poll, or idle chat) becomes an uncached
rewrite of the whole context.
The timestamp is the morning after the 2026-09-23 Cursor x post that cache
reuse had improved and that those harness changes were being
applied to Grok Bot.
This increases the quota usage for the same input/output tokens by roughly 12x.
Steps to Reproduce
- Use a grok-bot-default session that continues across gaps of
5–60 minutes (scheduled routine or a chat left idle). - Export All Events for grok-bot-default.
- Split rows at 2026-09-24 06:03 UTC.
- For each side, compute cold-start rate by gap since the previous
grok-bot-default row (cache read = 0, or uncached ≈ full prompt).
Expected Behavior
A 5–60 minute gap still reads the existing prefix, as it did before
06:03 UTC.
Operating System
MacOS
Version Information
Version: 0.61.0
Built: 2026-09-26T21:54:55.069Z
Release Track: stable
OS: darwin
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor