---
title: "Claude Code Pro Max 5x, 가벼운 사용에도 1.5시간 만에 쿼터 소진 — cache_read 토큰 카운팅이 원인?"
published: 2026-04-12T13:15:31.000Z
canonical: https://jeff.news/article/1683
---
# Claude Code Pro Max 5x, 가벼운 사용에도 1.5시간 만에 쿼터 소진 — cache_read 토큰 카운팅이 원인?

Claude Code Pro Max 5x(Opus) 플랜에서 쿼터 리셋 후 가벼운 사용만으로 1.5시간 만에 쿼터가 소진되는 문제가 보고됨. JSONL 로그 분석 결과, cache_read 토큰이 할인율(1/10) 없이 풀 레이트로 rate limit에 카운팅되는 것이 원인으로 추정됨.

- Claude Code Pro Max 5x(Opus) 플랜 유저가 쿼터 리셋 후 **1.5시간 만에 쿼터가 바닥남** — 가벼운 Q&A 위주 사용이었는데도
  - 리셋 전에는 5시간 동안 멀티파일 구현, 멀티에이전트 스폰 같은 헤비한 작업을 했고, 그건 예상 범위 안이었음
  - 문제는 리셋 후 가벼운 작업만 했는데도 쿼터가 순삭된 것

- 핵심 의심: **cache_read 토큰이 할인 없이 풀 레이트로 쿼터에 카운팅**되는 것으로 보임
  - 프롬프트 캐싱은 비용을 1/10로 줄여주지만, rate limit 측면에서는 할인이 적용 안 되는 듯
  - 1M 컨텍스트 윈도우에서 API 콜 한 번에 ~960K 토큰이 날아가는데, 시간당 200+ 콜이면 분 단위로 쿼터가 증발함

> [!WARNING]
> 백그라운드 세션이 쿼터의 78%를 잡아먹었음. 다른 터미널에 Claude Code 세션을 열어두기만 해도 compact, retro, hook 처리 등으로 공유 쿼터를 계속 소모함

- 유저가 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 비용이 최대치로 잡혀요. 이게 유저 의도 없이 자동으로 발생하니까 쿼터 관리가 어려워지는 거예요

## 핵심 포인트

- cache_read 토큰이 비용은 1/10이지만 rate limit에는 풀 레이트로 카운팅되는 것으로 의심
- 백그라운드 Claude Code 세션이 쿼터의 78%를 소모 — 유휴 상태에서도 compact/hook 처리 발생
- auto-compact 시점에 ~960K 토큰의 최대 비용 API 콜이 자동 발생
- 1M 컨텍스트 윈도우가 콜당 토큰 수를 증폭시켜 쿼터 고갈 가속

## 인사이트

Claude Code 헤비 유저라면 백그라운드 세션 관리가 필수적이라는 실질적 교훈. cache_read 토큰의 rate limit 카운팅 방식이 명확하게 문서화되지 않은 점이 핵심 이슈.