Check your own data

Everything runs locally in your browser: your log files never leave this machine. Nothing is uploaded, and there is nothing to sign up for.

Desktop browser required. The logs live on the machine where Claude Code runs (~/.claude/projects); mobile browsers cannot access them.

Saving is optional, and off unless you ask for it. After the diagnosis you can press “Save to this browser” to keep the result in this browser's own storage, so the next run can pick up where this one ended. It never goes to a server, and one button deletes it. On a shared or public computer, do not save: the result would stay behind for whoever uses this browser profile next. Just scanning leaves nothing behind.

Before you run it: what this page does, and what it does not

Your log files never leave this machine. Reading, scoring and charting all happen inside this tab. Nothing is kept when you close it unless you press “Save to this browser” in step 2 — and that save is written to this browser's local storage on this computer, is never sent to a server, and can be deleted at any time with one button. Running a check makes zero network requests: open F12 → Network and watch it yourself.
Nothing is sent unless you press the button in step 3. Even then, all that leaves is the aggregate numbers shown to you first (daily counts and totals), an optional nickname, and up to 16 one-way hashes that let the observatory recognise this machine as the same submitter next time. Conversation text, file paths, session IDs and timestamps are not part of the submission schema at all.
Why the hashes exist, and what they are. The observatory adds every row together, so a person who submits twice used to be counted twice. There is no login here, so the page derives a stable pseudonym for this machine from the request IDs already inside your logs: it takes a fixed sample of them, hashes each one with SHA-256, and sends only the digests. The request IDs themselves never leave, nothing can be turned back into them, and the observatory hashes the digests a second time before storing them, so nobody reading the public dataset holds anything they could send back. The full list is shown in the JSON preview in step 3 before you send it.
There is no build step. The code your browser runs is the same file that sits in the repo, so you can diff view-source against GitHub line by line.
No login, no account. The page only reads log files; it never talks to your Anthropic account or the API.

How this site is put together (file map)

assets/parse.js — the scoring engine. Every number on this page comes from it. It follows the same rules as the CLI scripts/check_cache_loss.py, and an automated test compares the two outputs.
assets/charts.js — drawing only (charts and heatmap). It does no scoring.
assets/store.js — the optional local save. It touches only this browser's own storage on this computer, never the network, and only after you press the save button and confirm. The single exception is the link token described in step 3, which is stored only when a submission could not be fingerprinted.
assets/identity.js — the fingerprint. It reads request IDs out of the logs you loaded, samples at most 16 of them (fewer on a short scan, where the picks overlap and collapse) and hashes them here. It has no network access and writes nothing.
functions/api/submit.js — the only code that runs on a server. It is called only when you press submit, validates the schema, and commits to the public repo.
data/submissions.json — the public dataset. One submission is one commit, so the whole history is auditable by anyone.
wrangler.toml — even the server configuration lives in the repo: there is no hidden backend.

Full scoring rules and trust model · Browse the source

1 · Load your session logs

Three steps, no install.

Find your Claude Code log folder: ~/.claude/projects (Windows: C:\Users\<you>\.claude\projects).
Drop that folder below, or pick it with the button. Multiple .jsonl files work too.
Read the results. Parsing happens in this tab only. Closing it discards everything, unless you choose “Save to this browser” in step 2.

Drag & drop the folder (or .jsonl files) here

No folder access? Paste the CLI script's JSON output instead

On the machine with the logs, run python scripts/check_cache_loss.py --json (the script ships in this repo) and paste everything it prints below. The pasted JSON contains aggregates only: totals plus daily counts.

Note: the --json flag is an addition in this repo's copy of the script; the judgment rules are unchanged v2.1.

2 · Your results

TTL-strict judgment v2.1: only losses inside the cache TTL are counted; legitimate expiries are excluded.

Requests scanned

–

In-TTL losses

–

inside 30 min (main) / 5 min (subagent)

Iron losses

–

idle gap under 5 minutes

Re-billed tokens

–

cache writes charged again

Loss rate

–

in-TTL losses / requests

losses (left axis) loss rate % (right axis) clean day

Day × hour heatmap: losses against actual usage

Background blue-grey = request volume that hour (darker = heavier use). Red with a number = in-TTL losses. This separates "zero because idle" from "zero despite heavy use". Click a red cell for per-event detail (time, idle gap, tokens) in a popover next to the cell; it stays in your browser.

idle (no requests) grey shading = requests that hour (darker = more) red = losses (number in the cell = count; click for per-event detail)

How losses are judged (TTL-strict, v2.1)

Candidate: a record the server itself stamped with message.diagnostics.cache_miss_reason = previous_message_not_found. Nothing is inferred.
In-TTL loss: the idle gap to the previous request in the same session file is under 30 minutes (main session) or 5 minutes (subagent). Longer gaps are legitimate TTL expiries and are not counted.
Iron loss: idle gap under 5 minutes, meaning no published TTL could have expired the cache.
Dedup: one event per requestId; a later record of the same request may only back-fill a missing reason.
Cost: the re-billed cost of a loss is that request's cache_creation_input_tokens.

Keep this result in this browser (optional)

Nothing is saved automatically. Pressing the button writes the totals, the daily rows, the hour-by-hour counts and this machine's fingerprint hashes into this browser's own storage on this computer. It is never sent to a server, and “Clear saved results” deletes it immediately. It also lets the next run start the day after your last submission instead of repeating a period you already sent. Every period named in this card is a UTC period, matching the submission card rather than the charts above. Do not save on a shared or public computer.

Nothing is saved in this browser yet.

3 · Share your aggregate (optional)

Exactly the JSON shown below is sent: period, totals, daily counts and the one-way fingerprint hashes that keep your machine to a single row. Never your logs, file paths, session contents or per-event details. Narrowing the shared period recomputes the totals for that window. The days in this card are UTC days, unlike the screens above, which are in your own timezone: submissions from many countries are summed day by day, and cutting each one by its own local date would scramble the fleet's daily totals. The dates in the picker below are therefore the UTC dates that will be sent.

Nickname (optional, max 20 chars)

Plan

Client

Concurrent sessions

Exact JSON that will be sent

POST /api/submit · written to the public dataset as a bot commit, into your machine's existing row when there is one · max 3 submissions per hour

Community-run tool — not affiliated with Anthropic. Engine: assets/parse.js (judgment rules v2.1, identical to scripts/check_cache_loss.py). Evidence thread: anthropics/claude-code#87966