Claude Code Pro Max 5x, 가벼운 사용에도 1.5시간 만에 쿼터 소진 — cache_read 토큰 카운팅이 원인?

• Claude Code Pro Max 5x(Opus) 플랜 유저가 쿼터 리셋 후 1.5시간 만에 쿼터가 바닥남 — 가벼운 Q&A 위주 사용이었는데도

  • 리셋 전에는 5시간 동안 멀티파일 구현, 멀티에이전트 스폰 같은 헤비한 작업을 했고, 그건 예상 범위 안이었음
  • 문제는 리셋 후 가벼운 작업만 했는데도 쿼터가 순삭된 것

• 핵심 의심: cache_read 토큰이 할인 없이 풀 레이트로 쿼터에 카운팅되는 것으로 보임

  • 프롬프트 캐싱은 비용을 1/10로 줄여주지만, rate limit 측면에서는 할인이 적용 안 되는 듯
  • 1M 컨텍스트 윈도우에서 API 콜 한 번에 ~960K 토큰이 날아가는데, 시간당 200+ 콜이면 분 단위로 쿼터가 증발함

• 유저가 JSONL 세션 로그에서 직접 토큰 사용량을 분석한 결과가 상세함

  • 윈도우 1 (5시간, 헤비 사용): API 콜 2,715회, cache_read 10.4억 토큰, 출력 115만 토큰
  • 윈도우 2 (1.5시간, 가벼운 사용): 메인 세션 API 콜 222회 + 백그라운드 세션 469회, 총 cache_read 1.04억 토큰
  • cache_read를 1/10로 계산하면(예상 동작) 윈도우 2의 유효 입력은 1,310만 토큰 — 이 정도로 5x 쿼터가 소진되면 안 됨
  • cache_read를 풀 레이트로 계산하면(의심 동작) 총 1.06억 토큰 — 쿼터 소진이 설명됨

• auto-compact가 만드는 비용 스파이크도 문제

  • 컨텍스트가 ~960K까지 차면 자동 compact 발동 → 이때 한 번의 API 콜에 전체 pre-compact 컨텍스트가 cache_creation으로 잡힘
  • 유저 액션 없이 자동으로 가장 비싼 단일 콜이 발생하는 구조

• 1M 컨텍스트 윈도우가 역설적으로 문제를 증폭시킴

  • 큰 컨텍스트 = 콜당 더 많은 토큰 = 더 빠른 쿼터 고갈
  • 마케팅에서는 피처인데 실사용에서는 쿼터 함정이 될 수 있음

• 유저가 제안한 개선사항이 합리적임

  • cache_read 쿼터 어카운팅 방식 문서화
  • rate limit에 유효 토큰(cache_read 1/10) 적용
  • 유휴 세션 감지 및 경고
  • 실시간 토큰 소비 분석 대시보드 (cache_read vs cache_create vs input vs output)

---

기술 맥락

• 프롬프트 캐싱(Prompt Caching)은 이전 대화의 토큰을 캐시에 저장해서 동일한 프리픽스를 재전송할 때 비용을 1/10로 줄여주는 기술이에요. 근데 "비용"과 "rate limit"은 별개의 개념이거든요. 비용은 과금 기준이고, rate limit은 서버 부하 관리 기준이라서 할인율이 다를 수 있어요
• 1M 컨텍스트 윈도우에서 tool-heavy 워크플로우가 문제가 되는 이유는 구조적이에요. 파일 읽기, 빌드, 테스트 같은 도구 호출이 있을 때마다 전체 대화 컨텍스트를 API에 재전송하거든요. 컨텍스트가 960K까지 차 있으면 도구 호출 한 번이 거의 1M 토큰 전송인 거예요
• auto-compact는 컨텍스트가 한계에 도달하면 대화를 요약해서 새로 시작하는 메커니즘인데, compact 직전의 API 콜이 가장 큰 컨텍스트를 담고 있어서 cache_creation 비용이 최대치로 잡혀요. 이게 유저 의도 없이 자동으로 발생하니까 쿼터 관리가 어려워지는 거예요