내 데이터 진단하기

전부 브라우저 안에서 로컬로 실행된다. 로그 파일은 이 기기를 떠나지 않는다. 업로드도, 가입도 없다.

데스크톱 브라우저 필요. 로그는 Claude Code가 실행되는 기기(~/.claude/projects)에 있다. 모바일 브라우저에서는 접근할 수 없다.

진단 결과는 이 브라우저에 자동으로 저장된다. 스캔이 끝나면 총계·일별 집계·시간대별 요청 수·이 기계의 지문 해시가 이 컴퓨터의 브라우저 저장 공간에 기록되고, 그래서 다음 진단이 이번에 끝난 지점부터 이어진다. 서버로는 가지 않고, 버튼 하나로 지우고, 2번 카드의 체크박스 하나로 끈다. 공용·공유 컴퓨터라면 스캔 전에 2번 카드에서 꺼 둘 것. 그러지 않으면 이 브라우저 프로필을 다음에 쓰는 사람에게 결과가 그대로 남는다.

돌리기 전에: 이 페이지가 무엇을 하고, 무엇을 하지 않나

로그 파일은 이 기기를 떠나지 않는다. 읽기·판정·그래프가 전부 이 탭 안에서 끝나고, 로그 파일 자체는 어디에도 저장되지 않는다. 읽고 놓아준다. 대신 판정 결과는 자동으로 남는다. 총계·일별 집계·시간대별 요청 수·이 기계의 지문 해시가 이 컴퓨터의 브라우저 저장 공간에 기록된다. 서버로는 전송되지 않고, 버튼 하나로 지우고, 2번 카드의 체크박스 하나로 끈다. 진단만 돌리면 네트워크 요청이 0건이다. F12 → Network 탭을 열어둔 채 실행해 직접 확인할 수 있다.
전송은 3번 카드의 버튼을 눌러야만 일어난다. 그때 나가는 것도 화면에 미리 보여준 집계 숫자(일별 건수·합계), 직접 입력한 닉네임, 그리고 관측소가 이 기계를 같은 제출자로 알아보게 하는 단방향 해시 최대 16개뿐이다. 대화 내용·파일 경로·세션 ID·시각은 제출 스키마에 아예 없다.
그 해시가 왜 있고, 무엇인가. 관측소는 모든 행을 더한다. 그래서 한 사람이 두 번 제출하면 두 번 세어졌다. 여기엔 로그인이 없으므로, 이 페이지는 로그 안에 이미 들어 있는 request ID로 이 기계의 고정 익명 식별자를 만든다. 정해진 규칙으로 일부를 고르고 각각을 SHA-256으로 해시해서, 다이제스트만 보낸다. request ID 자체는 나가지 않고 해시에서 되돌릴 수도 없으며, 관측소는 받은 다이제스트를 한 번 더 해시해서 저장한다. 그래서 공개 데이터를 읽는 사람이 손에 쥐는 값으로는 아무것도 되돌려 보낼 수 없다. 보낼 목록 전체는 3번 카드의 JSON 미리보기에 그대로 나온다.
빌드 스텝이 없다. 브라우저가 실행하는 코드가 repo에 올라간 파일 그대로다. view-source와 GitHub를 한 줄씩 대조할 수 있다.
로그인도 계정도 없다. Anthropic 계정이나 API와는 어떤 통신도 하지 않고, 로그 파일을 읽기만 한다.

이 사이트가 어떻게 구성돼 있나 (파일 지도)

assets/parse.js: 유실 판정 엔진. 이 페이지의 모든 숫자가 여기서 나온다. CLI scripts/check_cache_loss.py와 같은 규칙이며, 두 결과가 같은지 자동 테스트로 대조한다.
assets/charts.js: 그래프·히트맵 그리기 전용. 판정 계산은 하지 않는다.
assets/store.js: 선택적 로컬 저장. 이 컴퓨터의 브라우저 저장 공간만 건드리고 네트워크는 쓰지 않으며, 저장 버튼을 누르고 확인했을 때만 동작한다. 예외는 3번 카드에서 설명하는 연결 토큰 하나뿐이고, 지문을 만들 수 없었던 제출에서만 저장된다.
assets/identity.js: 기계 지문. 불러온 로그에서 request ID를 읽어 최대 16개를 골라 이 자리에서 해시한다. 스캔이 짧으면 고른 자리가 겹쳐 그보다 적다. 네트워크를 쓰지 않고 아무것도 저장하지 않는다.
functions/api/submit.js: 서버에서 도는 유일한 코드. 제출 버튼을 눌렀을 때만 호출되고, 스키마 검증 후 공개 repo에 커밋한다. 제출 1건이 커밋 1건인 건 그대로이고, 아래 네 파일을 그 한 커밋에 함께 쓴다.
data/submissions.json: 색인. 제출한 기계 1대가 1행이고 합계만 담는다.
data/daily.json: 전체 일자별 시계열. 달력 하루가 1행이고 모든 기계를 합산한 값이다.
data/identity.json: 제출한 기계의 해시된 지문과 연결 토큰 해시를 제출 id별로 담는다. 여기 다른 파일과 똑같이 공개돼 있고 이 링크로 바로 열린다. 다만 관측소 페이지가 내려받지 않을 뿐이고, 색인에서 빼낸 이유가 바로 그것이다. 저장되는 값은 브라우저가 보낸 값을 한 번 더 해시한 것이라, 여기서 값을 복사해도 누구도 행을 바꿀 수 없다.
data/subs/<id>.json: 내 제출의 일자별 원본. 제출 목록의 내 행에서 링크된다. 색인 행의 합계는 이 파일의 합과 정확히 같다.
wrangler.toml: 서버 설정도 repo에 공개. 숨겨진 백엔드가 없다는 뜻이다.

판정 규칙·신뢰 모델 자세히 · 소스 전체 보기

1 · 세션 로그 불러오기

설치 없이 3단계.

Claude Code 로그 폴더를 찾는다: ~/.claude/projects (Windows: C:\Users\<사용자명>\.claude\projects).
그 폴더를 아래에 끌어다 놓거나, 버튼으로 선택한다. 여러 개의 .jsonl 파일도 된다.
결과를 읽는다. 파싱은 이 탭 안에서만 일어난다. 판정 결과는 다음 진단이 이어질 수 있도록 이 브라우저에 저장된다. 끄는 스위치와 삭제 버튼은 2번 카드에 있다.

폴더(또는 .jsonl 파일)를 여기에 드래그 앤 드롭

또는

폴더 접근이 안 되면? CLI 스크립트의 JSON 출력 붙여넣기

로그가 있는 기기에서 python scripts/check_cache_loss.py --json(이 repo에 포함된 스크립트)을 실행하고, 출력 전체를 아래에 붙여넣는다. 붙여넣는 JSON에는 집계만 담긴다: 총계와 일별 카운트.

참고: --json 플래그는 이 repo 사본에 추가된 것이고, 판정 규칙은 v2.1 그대로다.

2 · 내 결과

청구 모양 판정 v3: 진단이 뭐라고 말했는가가 아니라 실제로 청구된 것이 판정한다. TTL 안쪽의 재생성만 집계하고, 정당한 만료와 선언된 프롬프트 변경은 제외한다.

스캔한 요청

–

확정 유실

–

TTL 안쪽에서 cache_read 0. 캐시 전체가 사라짐

유력 유실

–

프리픽스는 읽혔는데 10만+ 토큰 재생성, 변경 선언 없음

iron 유실

–

집계된 유실 중 유휴 5분 미만

재과금 토큰

–

다시 과금된 캐시 생성 토큰

유실률

–

in-TTL 유실 / 요청

유실 건수 (좌축) 유실률 % (우축) 무결한 날

일 × 1시간 히트맵: 사용량 대비 유실

바탕 회청색 = 그 시간의 요청량(진할수록 많이 사용). 빨강 숫자 = in-TTL 유실 건수. 이렇게 보면 "안 써서 0"과 "많이 썼는데도 0"이 구분된다. 빨간 셀을 클릭하면 건별 상세(시각·유휴 간격·토큰)가 셀 옆 팝오버로 열린다. 이 상세도 브라우저 밖으로 나가지 않는다.

미사용(요청 0) 회색 음영 = 그 시간대 요청량(진할수록 많음) 적색 = 유실 건수(셀 안 숫자, 클릭하면 건별 상세)

유실 판정 기준 (청구 모양, v3)

무엇이 판정하나: 각 요청의 청구 필드 cache_read_input_tokens와 cache_creation_input_tokens. 청구 그 자체라 누락도 오표기도 없다. 서버의 cache_miss_reason 주석은 캐시가 아니라 진단 기능의 상태를 말한다(Anthropic 지원 답변, 2026-08: previous_message_not_found는 "비교하지 못했다"는 뜻). 그래서 유실을 세는 데 어떤 사유 이름도 필요하지 않다.
확정 유실: 같은 세션 파일에서 직전 요청과의 유휴 간격이 30분 미만(메인) / 5분 미만(서브에이전트)이고, cache_read가 0인데 캐시를 새로 썼다. 몇 분 전에 쓰던 캐시 전체가 사라진 것이다.
유력 유실: 같은 간격 조건에서 프리픽스는 읽혔는데, 선언된 변경 없이 10만 토큰 이상을 재생성했다. 전체 요청의 쓰기 중앙값은 약 1,500토큰, 99퍼센타일이 약 84,000토큰이라 이 모양은 정상 분포 밖이다.
설명된 재생성 (집계 안 함): 위 모양인데 사유가 프롬프트가 실제로 바뀌었다고 선언한 경우(messages/model/system/tools_changed). 재생성이 올바른 동작이다. 모르는 사유 이름은 면책이 아니다. 서버가 새 이름을 만들어도 판정은 계속 동작하고, 그 이름은 아래 인구조사에 뜬다.
iron 유실: 집계된 유실 중 유휴 간격 5분 미만. 공표된 어떤 TTL로도 캐시가 만료됐을 수 없다.
v2.1 계열: 옛 사유 기반 집계(previous_message_not_found + TTL 안쪽 간격)도 계속 계산해 함께 보여준다. 몇 달간 실제 악화를 추적한 시계열이고, 헤드라인 자리만 내려온 것이다.
중복 제거: requestId당 1건. 같은 요청의 후속 레코드는 빠진 사유를 보강하는 데만 쓴다.
비용: 유실 1건의 재과금 비용 = 그 요청의 cache_creation_input_tokens.
계정 전환은 이 진단이 볼 수 없다. 프롬프트 캐시는 조직(계정) 단위로 격리되어 계정 간 절대 공유되지 않으므로, 다른 계정으로 로그인한 직후의 첫 대규모 재작성은 유실이 아니라 정당한 재캐싱이다. 그런데 세션 로그에는 계정 식별자가 없어 이 페이지는 둘을 구분하지 못한다. 계정을 돌려 쓰는 사용자라면 확정·유력 유실을 상한으로 읽을 것. 단서 하나(로테이션 기계 실측, 2026-08-29): 재로그인 직후 본인이 친 "이어서" 같은 재개 발화 바로 다음에 찍힌 미스가 그것이다 — 그 기계에선 집계된 유실의 18%가 이 패턴이었다.

이 브라우저가 보관하는 것

스캔이 끝날 때마다 총계·일별 집계·시간대별 요청 수·이 기계의 지문 해시가 이 컴퓨터의 브라우저 저장 공간에 기록된다. 서버로는 가지 않는다. 이게 있어서 다음 진단이 마지막 제출 다음 날부터 시작되고, 두 번의 진단을 비교할 수 있다. 최근 8건까지만 남는다. 이 카드에 적히는 기간은 모두 UTC 기준으로, 위 그래프가 아니라 제출 카드와 같은 기준이다. 아래 체크박스를 끄면 앞으로 저장하지 않고 이미 있는 건 그대로 둔다. 삭제 버튼은 전부 지우고 저장도 같이 끈다. 공용·공유 컴퓨터에서는 꺼 둘 것. 이 브라우저 프로필을 다음에 쓰는 사람이 저장된 내용을 읽을 수 있다.

끝난 스캔을 이 브라우저에 보관

이 브라우저에 저장된 기록이 없다.

3 · 관측소에 집계 공유하기 (선택)

전송되는 것은 아래 JSON 전문 그대로다. 기간·총계·일별 카운트, 로그에 있던 캐시 미스 사유값과 클라이언트 버전의 이름(이름만 보내고 각각 몇 건인지는 보내지 않는다), 그리고 이 기계를 한 행으로 유지하는 단방향 지문 해시뿐. 로그·파일 경로·세션 내용·건별 상세는 절대 전송되지 않는다. 공유 기간을 좁히면 총계도 그 기간으로 다시 계산된다. 이 카드의 날짜는 위 화면과 달리 UTC 기준이다. 여러 나라의 제출을 날짜별로 더하는 자리라, 각자의 현지 날짜로 자르면 전체 일별 합계가 어긋나기 때문이다. 아래 기간 선택도 실제로 전송될 UTC 날짜를 보여 준다.

닉네임 (선택, 최대 20자)

플랜

클라이언트

동시 세션

시간대별(UTC 24칸)도 함께 공개

켜면 이 제출 기간의 요청·유실 수가 시간대별 24칸으로 공개 데이터셋에 남는다. 주로 몇 시에 작업하는지가 공개 저장소에 보이게 된다는 뜻이다. 기본은 끔. 나중에 같은 기간을 끈 채 다시 제출하면 그 기간의 시간대 데이터는 제거된다.

전송될 JSON 전문 보기

POST /api/submit · 공개 데이터셋에 봇 커밋으로 기록되고, 이 기계의 행이 이미 있으면 그 행에 합쳐진다 · 시간당 최대 3회

커뮤니티 운영 도구, Anthropic과 무관합니다. 엔진: assets/parse.js (판정 규칙 v2.1, scripts/check_cache_loss.py와 동일). 증거 스레드: anthropics/claude-code#87966