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.

Your result is kept in this browser, automatically. When a scan finishes, its totals, daily rows, hour-by-hour counts and this machine's fingerprint hashes are written to this browser's own storage on this computer, so the next run can pick up where this one ended. It never goes to a server, one button deletes it, and one checkbox in step 2 stops it. On a shared or public computer, turn it off in step 2 before you scan: otherwise the result stays behind for whoever uses this browser profile next.

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, and the log files themselves are never stored anywhere — they are read and released. What is kept, automatically, is the scored result: totals, daily rows, hourly counts and this machine's fingerprint hashes, written to this browser's local storage on this computer. Never to a server, deletable with one button, and switchable off with one checkbox in step 2. 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. One submission is still one commit; it now writes the four files below together in that one commit.
data/submissions.json — the index: one row per submitting machine, totals only.
data/daily.json — the fleet series: one row per calendar day, summed across every machine.
data/identity.json — the hashed fingerprint of each submitting machine, and the hash of any link token, keyed by submission id. It is as public as every other file here and this link opens it; it simply is not downloaded by the observatory page, which is why it was moved out of the index. What is stored is a second hash of what your browser sent, so copying a value out of it lets nobody change a row.
data/subs/<id>.json — your submission's own daily rows, linked from your row in the submission list. An index row's totals are exactly the sum of this file.
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. The scored result is then kept in this browser so the next run can continue from it — step 2 holds the switch and the delete button.

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

Billing-shape judgment v3: what was charged decides, not what the diagnostic said. Only rebuilds inside the cache TTL count; legitimate expiries and declared prompt changes are excluded.

Requests scanned

–

Confirmed losses

–

cache_read 0 inside the TTL — the whole cache was gone

Probable losses

–

prefix read back, 100k+ tokens re-created, no change declared

Iron losses

–

a counted loss with idle 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 (billing shape, v3)

What decides: the billing fields of each request — cache_read_input_tokens and cache_creation_input_tokens. They are the bill itself, so they cannot be missing or misdescribed. The server's cache_miss_reason annotation describes the state of the diagnostic, not of the cache (Anthropic support, 2026-08: previous_message_not_found means "could not compare"), so no reason name is ever required to count a loss.
Confirmed loss: idle gap to the previous request in the same session file under 30 minutes (main) / 5 minutes (subagent), cache_read is 0, and cache was written. The whole cache was gone minutes after use.
Probable loss: same gap window, the stable prefix was read back, but 100,000+ tokens were re-created with no declared prompt change. Fleet-median writes are ~1,500 tokens and the 99th percentile is ~84,000, so this shape sits outside normal behaviour.
Excused rebuild (never counted): either shape where the reason declares the prompt really changed (messages/model/system/tools_changed) — re-creating it is correct behaviour. An unknown reason name never excuses: judgment keeps working if the server invents a new one, and the census below surfaces the name.
Iron loss: a counted loss with idle gap under 5 minutes, meaning no published TTL could have expired the cache.
v2.1 series: the old reason-based count (previous_message_not_found + gap under TTL) is still computed and shown for continuity. It tracked real degradation for months; it just is not the headline any more.
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.
Account switching is invisible to this check. Prompt caches are scoped to the organization and never shared across accounts, so the first big rewrite after logging into a different account is legitimate re-caching, not a loss. But session logs carry no account identifier, so this page cannot tell the two apart. If you rotate accounts, read confirmed and probable as upper bounds. One telltale from a rotating machine (2026-08-29): a miss whose immediately preceding message is your own "continue where we left off" phrase, typed right after a re-login — on that machine 18% of counted losses matched this pattern.

What this browser keeps

Every finished scan is written to this browser's own storage on this computer: the totals, the daily rows, the hour-by-hour counts and this machine's fingerprint hashes. Never to a server. It is what lets the next run start the day after your last submission instead of repeating a period you already sent, and what lets this page compare two runs. Only the last 8 results are kept. Every period named in this card is a UTC period, matching the submission card rather than the charts above. Unchecking the box below stops future saves and leaves what is already here; the delete button removes everything and switches saving off. On a shared or public computer, uncheck it: whoever uses this browser profile next can read what is stored.

Keep each finished scan in this browser

Nothing is saved in this browser yet.

3 · Share your aggregate (optional)

Exactly the JSON shown below is sent: period, totals, daily counts, the names of the cache-miss reasons and client versions your logs carried (the names only, never how many of each), 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

Also publish the hour-by-hour counts (24 UTC columns)

When checked, this submission's requests and losses are published per hour of the day, which means the hours you tend to work become visible in a public repository. Off by default. Resubmitting the same window later with this unchecked removes that window's hours.

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