Claude Code Pro Max 5x 요금제, 적당한 사용량에도 1.5시간 만에 할당량 소진되는 문제
(github.com/anthropics)- Pro Max 5x(1M 컨텍스트) 요금제에서 적당한 수준의 Q&A와 개발 작업만으로도 1.5시간 만에 토큰 한도 초과가 발생
- 원인으로
cache_read토큰이 전체 비율(1.0x) 로 계산되는 오류가 지목되며, 캐싱 효과가 사라져 급격한 소모가 발생 - 백그라운드 세션의 자동 호출, 자동 압축(auto-compact), 대형 컨텍스트 입력이 복합적으로 소모 속도를 높임
- 커뮤니티는 캐시 TTL 단축(1시간→5분) 및 캐시 무효화(cache busting) 현상을 핵심 원인으로 분석
- Anthropic은 기본 컨텍스트 축소(400k), UX 개선, 비활성 호출 최적화를 진행 중이며 사용자 피드백을 수집 중임
Pro Max 5x 요금제의 급격한 할당량 소진 문제
-
Pro Max 5x(claude-opus-4-6, 1M 컨텍스트) 요금제에서 중간 수준의 Q&A 및 경량 개발만으로도 1.5시간 만에 할당량이 소진되는 현상이 보고됨
- 이전 5시간의 고강도 개발에서는 정상적인 소모였으나, 재설정 이후 급격한 소모가 발생
- 환경은 Claude Code CLI on WSL2, 단일 세션(자동 압축 2회)에서 발생
-
cache_read토큰이 전체 비율(1.0x)로 계산되는 오류가 주요 원인으로 지목됨- 정상이라면
cache_read는 1/10 비율로 계산되어야 하며, 그렇지 않으면 캐싱 효과가 사라짐 - 세션 로그(
~/.claude/projects/.../*.jsonl)의usage객체를 통해 토큰 사용량이 분석됨
- 정상이라면
- 백그라운드 세션의 자동 호출, 자동 압축(auto-compact)의 고비용 처리, 1M 컨텍스트 윈도우의 대형 입력이 복합적으로 작용해 소모 속도를 가속화함
- 커뮤니티 분석 결과, 일부 사용자는 캐시 TTL 단축(1시간→5분) 및 캐시 무효화(cache busting) 현상을 핵심 원인으로 지목
- Anthropic 팀은 기본 컨텍스트 축소(400k), UX 개선, 비활성 호출 최적화를 진행 중이며, 사용자 피드백을 통한 추가 데이터 수집을 요청함
측정된 토큰 소비량
-
윈도우 1 (15:00–20:00, 5시간, 고강도 개발)
- API 호출 2,715회, Cache read 1,044M, Cache create 16.8M, 출력 1.15M 토큰
- 유효 입력(1/10 비율 적용 시) 121.8M 토큰
- Express 서버 + iOS 앱 구현, graphify 파이프라인, SPEC 기반 멀티에이전트 조정 수행
-
윈도우 2 (20:00–21:30, 1.5시간, 중간 수준 사용)
- 메인 세션(vibehq): API 222회, Cache read 23.2M, Cache create 1.4M, 출력 91k
- 백그라운드 세션(token-analysis, career-ops 포함): 총 691회 호출, Cache read 103.9M, 출력 387k
- 총 13.1M 유효 토큰(1/10 비율 적용 시) → 정상이라면 할당량 초과 없음
- 실제로는 105.7M 토큰(1.0x 계산 시) → 시간당 70.5M 수준으로, 할당량 소진과 일치
주요 문제 요약
-
1. Cache read 토큰의 요금 한도 계산 오류
- 기대:
cache_read는 1/10 비율로 계산 - 실제: 전체 비율로 계산되어 캐싱 효과 무효화
- 1M 컨텍스트 환경에서 호출당 100~960k 토큰이 전송되어, 200회 이상 호출 시 수분 내 소진
- 기대:
-
2. 백그라운드 세션의 공유 할당량 소모
- 비활성 세션(token-analysis, career-ops 등)도 자동 압축·후처리 호출로 공유 할당량을 지속 소모
-
3. 자동 압축(auto-compact)의 고비용 호출
- 압축 전 전체 컨텍스트(~966k 토큰)를
cache_creation으로 전송해 가장 비싼 호출이 자동 발생
- 압축 전 전체 컨텍스트(~966k 토큰)를
-
4. 1M 컨텍스트 윈도우의 부작용
- 대형 컨텍스트는 호출당 토큰 수를 급증시켜 할당량 소모 속도를 가속화
재현 절차
- Pro Max 5x 요금제에서 Opus 모델로 Claude Code 실행
-
~/.claude/rules/에 약 30개 규칙 파일(19k 토큰 오버헤드) 포함 - 파일 읽기·빌드·테스트 등 툴 중심 작업 수행
-
/context명령으로 컨텍스트 증가 확인 - 200~300회 호출 후 할당량 급감 확인
- 다른 터미널에서 2~3개 세션 유지
- 재설정 후에도 짧은 시간 내 할당량 소진 확인
기대 동작과 실제 동작 비교
-
기대:
-
cache_read는 1/10 비율로 계산 - 비활성 세션은 최소한의 소모
- 자동 압축은 과도한 소모를 유발하지 않음
- 중간 수준 사용 시 2~3시간 지속 가능
-
-
실제:
- 1.5시간 내 소진
- 백그라운드 세션이 78% 소모
- 총 105.7M 토큰 전송으로
cache_read가 전체 비율로 계산된 것으로 추정
개선 제안
-
cache_read계산 방식 명확화 — 문서에 실제 요금 한도 계산 비율 명시 -
유효 토큰 기준 제한 —
cache_read를 1/10 비율로 계산하도록 수정 - 세션 유휴 감지 — 비활성 세션의 자동 호출 방지 또는 경고 표시
-
실시간 토큰 소비 가시화 —
cache_read,cache_create, 입력·출력별 사용량 표시 - 컨텍스트 기반 비용 예측 — 작업 전 예상 토큰 비용 표시
커뮤니티 분석 및 논의
-
cnighswonger
-
claude-code-cache-fix인터셉터로 24시간 동안 1,500회 호출 데이터를 수집 - 세 가지 가설(
cache_read0.0x, 0.1x, 1.0x)을 검증한 결과, 0.0x 모델만이 5시간 창에서 일관된 결과(CV 34.4%) 를 보임 - 결론:
cache_read는 실질적으로 할당량에 거의 영향을 주지 않음, 캐시가 정상 작동 중 - 단, 단일 계정 데이터로 추가 검증 필요
-
-
henu-wang
-
캐시 TTL이 1시간에서 5분으로 단축된 회귀(regression) 이후, 세션 일시 중단 시마다
cache_create가 발생해 12.5배 높은 비용을 유발 - 컨텍스트가 길어질수록 비용이 비선형적으로 증가
- 임시 해결책으로 짧은 세션 유지,
/compact명령 적극 사용, CLAUDE.md에 핵심 컨텍스트 사전 로드를 제안
-
캐시 TTL이 1시간에서 5분으로 단축된 회귀(regression) 이후, 세션 일시 중단 시마다
-
bcherny (Anthropic 팀)
- 1M 컨텍스트 윈도우 사용 시 프롬프트 캐시 미스가 고비용임을 인정
- UX 개선(장기 세션 재개 시
/clear유도)과 기본 컨텍스트를 400k로 축소하는 방안을 실험 중 - 다중 에이전트·플러그인 사용 시 비활성 작업이 토큰을 과소비하는 사례를 확인, 자동 정리 및 스케줄링 개선을 진행 중
-
wadabum
커뮤니티 제안 요약
- RockyMM: 세션이 한도에 도달하면 자동 요약 후 재개를 유도하고, TTL을 10분으로 단축
- mikebutash: Pro 요금제에서 5시간당 2회 프롬프트만 가능하다고 보고, v2.1.81 버전으로 롤백 및 cache-fix 설치로 3~4배 개선 확인
- wutlu: 작업별로 세션을 초기화해 문제 완화
- dprkh: 디버그 모드 스킬(Skill.md) 공유로 원인 규명 지원
결론
- Pro Max 5x 요금제의 급격한 할당량 소진 문제는 캐시 동작, TTL 회귀, 컨텍스트 팽창, 백그라운드 호출의 복합적 영향으로 확인됨
- 커뮤니티는
cache_read계산 오류보다는 캐시 무효화와 TTL 단축이 핵심 원인이라는 분석을 제시 - Anthropic 팀은 컨텍스트 기본값 축소, 캐시 UX 개선, 비활성 호출 최적화를 진행 중이며, 사용자 피드백(
/feedback)을 통한 추가 데이터 수집을 요청함
Hacker News 의견들
-
Claude Code 팀의 Boris임. 최근 보고된 문제들을 조사한 결과, 주요 원인은 두 가지임
-
1M 토큰 컨텍스트 윈도우 사용 시 프롬프트 캐시 미스가 비쌈. 현재 캐시 TTL이 1시간이라, 한 시간 이상 자리를 비우면 세션이 만료되어 전체 캐시를 다시 불러와야 함. 이를 개선하기 위해 UX 개선을 배포했고, 기본값을 400k로 낮추는 옵션을 검토 중임. 지금 바로 테스트하려면
CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude명령을 사용하면 됨 - 너무 많은 플러그인이나 에이전트를 동시에 실행하는 경우 토큰 낭비가 발생함. 이를 해결하기 위해 UX 개선과 비주요 작업의 자동 정리 및 스케줄링을 진행 중임
문제를 겪는 사용자는/feedback명령으로 피드백을 보내주면 디버깅에 도움이 됨
- Boris, 지금 커뮤니티에 올라오는 사용자 경험담이 단순한 예외가 아님. Jeff Bezos가 말했듯, 데이터가 아니라 일화들이 진실을 말할 때가 있음. 메트릭이 잘못된 게 아닌지 진지하게 검토해야 함
- 왜 갑자기 이런 문제가 생겼는지 의문이었는데, 조사해보니 프롬프트 캐시 TTL이 1시간에서 5분으로 줄어든 게 원인이었음. 세션을 새로 시작해도 결국 모든 걸 다시 빌드해야 하므로 비효율적임. 캐시 만료를 감시해야 하는 구조는 CC의 철학과 어긋남
- 내 경우 가장 심각한 회귀는 시스템 프롬프트가 매번 파일을 악성코드 검사하려고 하는 부분이었음. 이로 인해 토큰이 빠르게 소모되고, “not a malware” 응답이 계속 나왔음. 이런 설계는 잘못된 판단임. 결국 프로젝트를 중단하고 Qwen으로 옮겼는데 꽤 괜찮음
-
/clear알림은 해결책이 아님. 캐시를 비우면 결국 다시 빌드해야 하므로 비용은 동일함. UX로 사용자를 작은 컨텍스트로 유도하는 건 서비스 품질 저하임. 비용 문제라면 가격이나 아키텍처를 고쳐야 함 - OpenAI는 문제가 생기면 사용량 한도를 초기화해줬는데, Anthropic은 그런 조치가 없음. 이번 일은 의도적이라는 인상임
-
1M 토큰 컨텍스트 윈도우 사용 시 프롬프트 캐시 미스가 비쌈. 현재 캐시 TTL이 1시간이라, 한 시간 이상 자리를 비우면 세션이 만료되어 전체 캐시를 다시 불러와야 함. 이를 개선하기 위해 UX 개선을 배포했고, 기본값을 400k로 낮추는 옵션을 검토 중임. 지금 바로 테스트하려면
-
최근 Claude가 눈에 띄게 느려지고 비효율적이었음. 파일을 지정해줘도 5분 이상 탐색 루프에 빠지고, 세션 제한에 금방 도달함. 하루 세 번만 써도 주간 한도의 25%가 사라짐. 그래서 $100짜리 Codex 플랜으로 옮겼는데, 정확도와 관대함 면에서 훨씬 나음. 다만 Codex의 말투가 거슬려서 Agents.md에 따로 지시문을 추가했음. UI 감각은 예전 Claude Code가 더 좋았지만, 백엔드 디버깅과 복잡한 문제 해결은 Codex가 우세함. 지금은 Codex와 Cursor의 $20 플랜을 비교해보길 추천함
- 나도 비슷한 경험을 했음. Claude가 며칠 전엔 멈춘 듯 생각만 하더니, 다음날엔 정상 작동했음
- Codex Business 플랜(30유로)을 쓰고 있는데, 최근 쿼터가 줄어든 느낌임. 그래도 Claude Code보다는 여전히 훨씬 나은 조건임
- 현재 Opus, Haiku, Sonnet 모델의 confidence score 동작을 비교 중임. Opus는 중간 난이도 작업에서 효율이 가장 좋음
- CC, Gemini-cli, Codex를 써봤는데 CC가 여전히 가장 뛰어남. Cursor나 Aider 조합이 더 좋은지 궁금함
- AI 코딩은 컨텍스트 낭비가 심하므로, 커스텀 샌드박스로 범위를 제한하면 효율이 높아짐
-
이슈를 훑어보니 Anthropic이 티켓을 빨리 닫는 이유를 알겠음. 대부분 AI가 생성한 노이즈로 보임. 내가 한 해결책은 다음과 같음
- 모든 세션에서 max thinking을 켜서 불필요한 경로 탐색을 줄임
- 세션을 계속 활성 상태로 유지함. 캐시가 5분 만에 만료되면 토큰을 다시 빌드해야 함
- 200k 토큰 이후엔 바로 compact 실행
Anthropic이 강제로 1M 모델을 적용한 게 가장 불만임
- 나도 이슈를 보고 웃었음. 아마 Claude Code에게 “왜 토큰이 다 썼는지 조사하라”고 시킨 결과일 듯
- 어떤 사람은 thinking을 켜라 하고, 어떤 사람은 끄라 함. 둘 다 토큰 절약이라니 아이러니함
- 캐시가 무작위로 무효화되는 버그가 핵심임. API 클라이언트가 구독자 캐시를 조기 종료시키는 듯함. 게다가 입력 토큰 비용도 몰래 올림
- 나도 확인함. max effort가 도움이 됨. 컨텍스트를 25% 이하로 유지하는 게 중요함. 캐시 만료 상태를 확인할 방법이 있는지 궁금함
-
/model opus나/model sonnet명령으로 1M 모델을 끌 수 있음
-
이제 보조금 시대의 끝이 다가오는 느낌임. Google Gemini 커뮤니티에서도 최근 쿼터 축소로 불만이 폭주 중임 (이슈 링크). 나도 결국 Kiro IDE와 Codex CLI 조합으로 옮겼고 만족 중임
- 이런 변화는 예견된 일이었음. 무료 토큰 시절에 필요한 라이브러리들을 미리 구축해두는 게 현명한 전략이었음
- Anthropic이 이제 기업 고객 중심으로 전환 중이고, OpenAI도 비슷한 길을 걷고 있음. Reddit과 Discord에서는 오픈모델이나 중국산 대안을 찾는 움직임이 있지만 완전한 대체재는 없음
- antigravity는 프로 쿼터를 빠르게 소모하지만, flash 모드는 훨씬 관대함. STM32 프로젝트를 진행하며 3배 빠른 생산성을 얻었음
- 결국 이 흐름의 끝은 출력에 광고가 붙는 시대일지도 모름
- 예전 $3짜리 Uber 택시가 떠오름
-
문제의 근본 원인을 지적한 이슈가 “Not planned”으로 닫힌 게 불안함
- 답변 내용이 AI가 쓴 듯 부자연스러움. “1시간 TTL이 더 비싸다”는 논리도 이상함. 토글을 제공하지 않는 이유가 비용이라니 납득하기 어려움
- 굳이 무서워할 필요는 없음. 품질이 나빠지면 그냥 안 쓰면 됨
- Anthropic이 카지노처럼 토큰을 팔고, 사용자가 돈을 잃어도 신경 쓰지 않는 구조라고 봄. 이런 모델이 싫다면 로컬 LLM을 쓰는 게 낫다고 생각함
-
버전 2.1.34로 롤백했더니 쿼터 문제와 캐시 문제 대부분이 해결됨.
~/.claude/settings.json에"effortLevel": "high","CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1등을 추가하고, 다른 버전은 삭제함.
Adaptive thinking은 아직 불완전하지만, 향후 개선되면 도움이 될 듯. 그래도 Codex로 옮길까 고민 중임- 나도
~/.bashrc에CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000,DISABLE_AUTOUPDATER=1등을 설정해둠
- 나도
-
하위 모델에서도 비슷한 문제가 있었음. 공정한 거래는 투명한 측정에서 시작된다고 생각함. 이번 달 구독은 취소 예정임
- 컴퓨터가 절전 모드일 때도 세션이 시작돼 토큰이 소모되는 경우가 있었음. “지금 몇 시야?” 같은 간단한 질문에도 10%를 써버림
-
올해 세금 신고를 AI 에이전트로 실험해봤음. Opus 4.6, Codex 5.4, Antigravity 3.1을 각각 $20 플랜으로 사용함.
Codex는 12분 만에 완벽히 처리했고, Antigravity는 한 페이지를 누락했지만 빠르게 수정됨. Claude Code는 사용 한도 초과로 중단되고, 재시도 후에도 오차가 있었음. 기대 이하였음- 나도 비슷한 실험을 했는데, 내 경우 Claude가 회계사 수준으로 정확했음. 같은 작업이라도 세션마다 결과가 달라지는 게 흥미로움. 비결정적 소프트웨어 시대의 고객 지원은 정말 낯선 경험임
-
Reddit에 올라온 업데이트 공지 이후로 Claude가 일상 코딩용으로 쓸 수 없을 정도로 변했음. Pro 계정 크레딧이 한 시간 만에 소진되어 Gemini나 ChatGPT로 돌아감
-
결국 Anthropic의 토큰 과금 구조가 일반 사용자에게 불리하게 설계된 듯함. 실제로 써보면 그들이 얼마나 많은 돈을 원했는지 바로 느껴짐