Tracking Claude Code in-TTL previous_message_not_found prompt-cache losses across the machines that report them: every data point below was parsed locally in a volunteer's browser and submitted as approved aggregate numbers only. One machine is one row — a second submission from the same machine updates its row instead of adding another.
The short history, including the part that argues against the headline.
Since spring 2026, some Claude Code users have seen their usage allowance drain abnormally fast, to the point where a 5-hour limit window was exhausted in tens of minutes. A GitHub report from May (#63282) was closed automatically without a response.
In August, attention turned to a diagnostic the server itself writes into local session logs: message.diagnostics.cache_miss_reason. That field made losses measurable from server-stamped records instead of gut feeling.
An honest counterpoint belongs here: most raw hits are not a bug. In the operator's own data, 78% of raw previous_message_not_found records were legitimate expiries after long idle periods. This site excludes those and counts only losses inside the cache TTL.
Controlled observations followed: four sessions on the same machine lost their cache within the same single minute, and one cache entry vanished 24 seconds after it was created. The same signature has been confirmed on three independent accounts.
Whether this is a handful of broken environments or a widespread problem can only be answered with structured data from many machines. Collecting that is what this site is for. Discussion continues in anthropics/claude-code#87966.
Point the check at your own logs and this is the shape of what comes back. Every number in the framed block below is a synthetic sample generated by assets/demo.js: not an observation, not anyone's submission, not the maintainer's own machine.
Why the sample is synthetic: the submission schema carries daily aggregates only and has no hour-level field, on purpose, so that submitting cannot reveal when you work. No real submission can back an hour-level heatmap, so none is used here.
Run this on your own logs → Parsing happens in your browser; log files never leave your machine, and nothing is submitted until you press the share button.
In-TTL losses as a share of that day's requests, one line per reporting machine. Vertical alignment across machines points at server-side events; a step down that holds across machines points at a fix being deployed. Every day on this axis is a UTC day, the same cut for every submission — which is what makes lining two machines up on the same date mean anything.
The same submissions, grouped by one self-reported environment field. The sample size is printed on every row, and a group below the floor shows its counts without a rate.
Pick which self-reported field the submissions are grouped by. The table below regroups on the one you pick; the loss rate is recomputed per group, and the sample size is printed on every row.
Not one number in this frame is an observation. It is a fixed, invented illustration of the comparison this section will draw, standing in while the real sample is below the floor. Real data on this page always carries the green Real submissions badge: the fleet chart, the submission list, and this comparison table once it has enough rows to be one.
| Value (example) | Submissions (n) | Requests | In-TTL losses | Loss rate |
|---|
| Value | Submissions (n) | Requests | In-TTL losses | Loss rate |
|---|
| Nickname | Client | Plan | Sessions | Requests | In-TTL | Loss rate |
|---|
Aggregate totals per submission. No timestamps, no session IDs, no file paths; the schema cannot carry them. Nicknames are stored masked, so the row you submitted is marked from this browser's own record instead. Click a column header to sort: it reorders the rows on screen and changes nothing else on the page.
What counts as a loss, and why you can verify every step yourself.
Only if you ask it to. By default a diagnosis exists just in the open tab and is gone when you close it. On the check page you can press “Save to this browser” and confirm the prompt; that writes the totals, the daily rows and the hour-by-hour counts into that browser's local storage.
What a save is, and is not: it stays inside that browser on that computer, it is never sent to a server, and “Clear saved results” deletes it immediately and completely. It exists so a later run can start the day after your last submission instead of re-sending a period you already shared. Log file paths, session IDs, requestIds and conversation text are not written to it, the same fields the submission schema excludes. On a shared or public computer, do not save.
The code that runs is exactly the repo's files; there is no build step, so you can compare the browser's view-source against the repo line by line. This is the whole thing: