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, every reporting machine pooled into one line. A rising line means the fleet is losing a larger share of what it sends, not that more people are submitting: the denominator is that same day's requests. A step down that holds 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 summing machines on the same date mean anything. A day carried by one machine is one machine's rate, so how many reported each day is drawn too: once the count varies from day to day it appears as a faint column behind each date, and while every day has the same number the legend prints that number instead.
One line each was the previous design. It is readable at one submission and unreadable at fifty, and it cost every visitor a download of every submitter's entire daily history. The per-machine numbers did not go away: each row in Submissions links the file its own totals are the sum of.
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.
The last column links each row's own daily rows. That file is what the row's totals are the sum of, so the arithmetic on this page is checkable one row at a time: the index (these rows), the fleet series (the chart above), and one detail file per machine. This page downloads the first two and never the third — opening one is your choice, not the page's. The same goes for the fingerprint map: public, linked here, and not fetched.
| Daily detail |
|---|
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: