커뮤니티 도구 · Anthropic 공식 아님

캐시 유실 관측소

Claude Code in-TTL previous_message_not_found 프롬프트 캐시 유실을 보고한 기계 단위로 추적한다. 기계 1대가 1행이고, 같은 기계의 두 번째 제출은 행을 늘리지 않고 기존 행을 갱신한다. 아래 모든 수치는 자발적 제출자의 브라우저에서 로컬로 파싱되어, 본인이 승인한 집계 숫자만 제출된 것이다.

보고한 기계 수
사람이 아니라 기계 1대 = 1행
총 관측 유실
정당한 TTL 만료는 제외
재과금 토큰
유실 후 다시 과금된 캐시 생성 토큰
관측 기간
제출된 가장 이른 날 ~ 가장 늦은 날
내 데이터 진단하기 →

왜 이 관측소가 있나

짧은 경위. 헤드라인에 불리한 사실도 함께 적는다.

2026년 봄부터 일부 Claude Code 사용자에게서 사용량이 비정상적으로 빨리 소진되는 일이 반복됐다. 5시간 한도 창이 수십 분 만에 바닥나는 수준이었다. 5월의 GitHub 신고(#63282)는 응답 없이 자동으로 닫혔다.

8월, 서버가 로컬 세션 로그에 직접 남기는 진단 필드 message.diagnostics.cache_miss_reason이 확인됐다. 이때부터 유실을 체감이 아니라 서버 기록으로 판정할 수 있게 됐다.

정직한 반론도 적어 둔다: 원시 집계의 대부분(운영자 데이터 기준 78%)은 장시간 유휴 후의 정당한 만료였다. 이 사이트는 그것을 제외하고 TTL 안쪽 유실만 센다.

통제된 재현에서는 같은 기계의 4개 세션이 같은 1분 안에 동시에 캐시를 잃었고, 생성된 지 24초 된 캐시 엔트리가 사라지는 것도 관측됐다. 같은 시그니처가 독립 계정 3곳에서 확인됐다.

개인 환경 문제인지 광범위한 문제인지 가르려면 여러 기계에서 모은 구조화된 데이터가 필요하다. 그것을 모으는 곳이 이 사이트다. 논의는 anthropics/claude-code#87966에서 진행 중이다.

진단하면 이런 걸 본다 예시 데이터

내 로그로 진단을 돌리면 돌아오는 화면이 이 모양이다. 아래 테두리 안의 숫자는 전부 assets/demo.js가 만든 합성 예시다. 관측 데이터도, 누군가의 제출 데이터도, 운영자 기계의 실측도 아니다.

왜 합성 예시여야 하나: 제출 스키마에는 일별 집계만 있고 시간대별 항목이 아예 없다. 제출만으로 언제 일하는지가 드러나지 않도록 일부러 뺐다. 그래서 실제 제출로는 시간 단위 히트맵을 그릴 수 없고, 여기서도 쓰지 않는다.

스캔한 요청
in-TTL 유실
30분(메인) / 5분(서브에이전트) 안쪽
iron 유실
유휴 간격 5분 미만
재과금 토큰
다시 과금된 캐시 생성 토큰
유실률
in-TTL 유실 / 요청
유실 건수 (좌축) 유실률 % (우축) 무결한 날
미사용(요청 0) 회색 음영 = 그 시간대 요청량(진할수록 많음) 적색 = 유실 건수(셀 안 숫자, 클릭하면 아래 표가 그 시간대로 바뀐다)

내 로그로 직접 돌려보기 → 파싱은 브라우저 안에서 일어난다. 로그 파일은 기기를 떠나지 않고, 공유 버튼을 누르기 전에는 아무것도 제출되지 않는다.

Fleet 일별 유실률 추이 실제 제출 데이터

그날 요청 대비 in-TTL 유실 비율, 보고한 기계별 한 선. 기계를 가로질러 수직으로 정렬된 급등은 서버측 이벤트를, 기계 전체에서 유지되는 하락 계단은 수정 배포 시점을 가리킨다. 이 축의 하루는 모두 UTC 기준이고 모든 제출에 같은 기준이 적용된다. 서로 다른 기계를 같은 날짜에 놓고 보는 일이 의미를 가지는 근거가 이것이다.

환경별 분해 실제 제출 데이터

같은 제출 데이터를 환경 항목 하나로 묶어 본 것이다. 표본 수는 모든 행에 함께 적는다. 기준 미만인 그룹은 건수만 보여주고 유실률은 내지 않는다.

제출 데이터를 어떤 자기신고 항목으로 묶을지 고르는 버튼이다. 고른 기준으로 아래 표가 다시 묶이고, 그룹마다 유실률을 새로 계산하며, 표본 수는 모든 행에 함께 적는다.

표본 수 (n)합산 요청in-TTL 유실유실률
원자료 보기 (제출 1건 = 1행)
닉네임클라이언트플랜동시 세션총 요청in-TTL유실률
  • 환경 항목은 전부 제출자가 스스로 적은 값이다. 검증할 수단이 없다.
  • 기계마다 요청 규모가 자릿수 단위로 다르다. 여기 유실률의 분모는 서로 크기가 비대칭이고, 큰 기계 하나가 그룹 전체를 끌고 갈 수 있다.
  • 제출 5건 미만인 그룹은 건수만 표시한다. 행 순서는 정렬이지 순위가 아니다. 한 행이 뒷받침하는 것은 "지금까지 제출된 것이 이렇다"까지다.

제출 목록 실제 제출 데이터

제출별 집계 합계. 시각·세션 ID·파일 경로는 없다. 스키마 차원에서 담을 수 없다. 닉네임은 마스킹해서 저장하므로, 본인이 제출한 행은 이 브라우저에 남은 기록으로 표시한다. 열 제목을 누르면 정렬된다. 화면에 보이는 행 순서만 바뀌고 이 페이지의 다른 것은 아무것도 바뀌지 않는다.

방법론 · 신뢰

무엇을 유실로 판정하는지, 그리고 왜 모든 단계를 직접 검증할 수 있는지.

  • 근거 데이터: 로컬 세션 로그(~/.claude/projects/**/*.jsonl)에 서버가 직접 찍은 진단 필드 message.diagnostics.cache_miss_reason = previous_message_not_found. 추정이 아니라 서버가 표시한 레코드만 후보다.
  • TTL-strict 판정: 같은 세션 파일에서 직전 요청과의 유휴 간격이 30분 미만(메인 세션) / 5분 미만(서브에이전트)일 때만 유실로 집계. 그보다 길면 정당한 TTL 만료로 보고 제외한다.
  • iron 유실: 유휴 간격 5분 미만인 부분집합. 공표된 어떤 TTL로도 만료됐을 수 없는 구간.
  • 중복 제거 · 비용: requestId 기준으로 중복을 제거하고, 유실 1건의 재과금 비용은 그 요청의 cache_creation_input_tokens다.
  • 요청이 어느 날짜로 세어지나: 이 관측소와 여기 쌓인 모든 제출은 하루를 UTC로 자른다. 여러 나라의 제출을 날짜별로 더하는 자리라, 각자의 현지 날짜로 자르면 전체 일별 합계가 어긋나기 때문이다. 진단 페이지는 일부러 반대다. 한 사람의 자기 진단이므로 그래프·히트맵·건별 시각을 읽는 사람의 현지 시각으로 그리고, 그 시간대는 브라우저에서 읽어 와 화면에 이름으로 적는다. 요청도 총계도 같고 날짜 경계만 움직이므로, 자정 근처의 요청은 그쪽에서 본 날짜와 여기의 날짜가 하루 다를 수 있다. 진단 페이지의 전송 미리보기가 보내기 전에 이 차이를 알려 준다.
신뢰 모델: 파싱은 당신의 브라우저에서 로컬로 실행된다. 로그 파일은 기기를 떠나지 않는다. 전송되는 것은 본인이 명시적으로 승인한 집계 숫자(일별 건수·합계)뿐이다. 진단 페이지는 결과를 그 브라우저의 저장 공간에 남길 수 있는데, 저장 버튼을 누르고 확인 창에서 확인했을 때만 그렇다. 저장분은 본인 컴퓨터 안에만 있고 서버로 가지 않으며 버튼 하나로 지운다. 이 사이트는 빌드 스텝이 없어서 실행되는 코드가 repo에 있는 코드 그대로다. 실행 전에 한 줄씩 읽어볼 수 있다.
내 대화 내용이 업로드되나?
아니다. 파싱은 전부 브라우저 안에서 일어난다. 직접 검증할 수 있다: F12 Network 탭을 열고 진단을 돌려 보면 네트워크 요청이 없다. 공유 버튼을 누르기 전에는 아무것도 전송되지 않고, 누르면 화면에 미리 보여준 집계 숫자 JSON만 나간다.
이 사이트가 내 컴퓨터에 뭔가를 남기나?

본인이 시켰을 때만 남는다. 기본값에서 진단 결과는 열려 있는 탭 안에만 있고 탭을 닫으면 사라진다. 진단 페이지에서 "이 브라우저에 저장"을 누르고 확인 창에서 확인하면, 총계·일별 집계·시간대별 요청 수가 그 브라우저의 저장 공간에 기록된다.

저장분의 성격: 그 컴퓨터의 그 브라우저 안에만 있고, 서버로는 전송되지 않으며, "저장된 기록 지우기"를 누르면 즉시, 완전히 삭제된다. 다음 진단이 마지막 제출 다음 날부터 시작되게 해서 이미 공유한 기간을 다시 보내지 않도록 하는 용도다. 로그 파일 경로·세션 ID·requestId·대화 내용은 저장하지 않는다. 제출 스키마에서 빼 둔 것과 같은 기준이다. 공용·공유 컴퓨터에서는 저장하지 말 것.

이 코드가 뭐 하는지 어떻게 믿나?

실행되는 코드가 repo 파일 그대로다(빌드 없음). 브라우저 view-source와 repo를 한 줄씩 대조할 수 있다. 구성은 이게 전부다:

  • assets/parse.js: 유실 판정 엔진(브라우저에서 실행). CLI scripts/check_cache_loss.py와 같은 규칙이고, 두 결과가 같은지 자동 테스트로 대조한다.
  • assets/charts.js: 그래프 그리기 전용. 판정 계산은 하지 않는다.
  • assets/store.js: 진단 페이지의 선택적 로컬 저장. 브라우저 저장 공간만 쓰고 네트워크는 쓰지 않으며, 확인했을 때만 동작한다.
  • functions/api/submit.js: 서버에서 도는 유일한 코드. 제출 버튼을 눌렀을 때만 호출되고, 스키마 검증 후 이 repo에 커밋한다.
  • data/submissions.json: 이 페이지가 읽는 공개 데이터. 제출 1건 = 커밋 1건이라 이력 전체가 감사 대상이다.
  • wrangler.toml: 서버 설정도 repo에 공개. 숨겨진 백엔드가 없다.
돌리면 내 Claude 계정에 영향이 있나?
없다. 로그 파일을 읽기만 한다. Anthropic 계정이나 API와는 어떤 통신도 하지 않는다.
in-TTL 유실이 나왔다. 이제 뭐를 하나?
GitHub #87966에 결과를 남겨 달라. 0이 나왔어도 똑같이 가치 있는 데이터다. 정상 계정의 존재도 원인 특정에 필요하다.
제출하면 뭐가 공개되나?
미리보기로 승인한 집계·일별 숫자와 선택 입력한 닉네임뿐이다. 제출 이력 전체가 repo 커밋으로 남아 누구나 감사할 수 있다.
Anthropic 공식 사이트인가?
아니다. Anthropic과 무관한 커뮤니티 도구다.
내 데이터 진단하기 →