# Claude Code Pro Max 5x 요금제, 적당한 사용량에도 1.5시간 만에 할당량 소진되는 문제 > Clean Markdown view of GeekNews topic #28459. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28459](https://news.hada.io/topic?id=28459) - GeekNews Markdown: [https://news.hada.io/topic/28459.md](https://news.hada.io/topic/28459.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-13T09:47:07+09:00 - Updated: 2026-04-13T09:47:07+09:00 - Original source: [github.com/anthropics](https://github.com/anthropics/claude-code/issues/45756) - Points: 7 - Comments: 2 ## Topic Body - **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`으로 전송해 **가장 비싼 호출이 자동 발생** - ## 4. 1M 컨텍스트 윈도우의 부작용 - 대형 컨텍스트는 호출당 토큰 수를 급증시켜 **할당량 소모 속도를 가속화** ### 재현 절차 1. Pro Max 5x 요금제에서 Opus 모델로 Claude Code 실행 2. `~/.claude/rules/`에 약 30개 규칙 파일(19k 토큰 오버헤드) 포함 3. 파일 읽기·빌드·테스트 등 툴 중심 작업 수행 4. `/context` 명령으로 컨텍스트 증가 확인 5. 200~300회 호출 후 할당량 급감 확인 6. 다른 터미널에서 2~3개 세션 유지 7. 재설정 후에도 짧은 시간 내 할당량 소진 확인 ### 기대 동작과 실제 동작 비교 - ## 기대: - `cache_read`는 1/10 비율로 계산 - 비활성 세션은 최소한의 소모 - 자동 압축은 과도한 소모를 유발하지 않음 - 중간 수준 사용 시 2~3시간 지속 가능 - ## 실제: - 1.5시간 내 소진 - 백그라운드 세션이 78% 소모 - 총 105.7M 토큰 전송으로 `cache_read`가 전체 비율로 계산된 것으로 추정 ### 개선 제안 1. **`cache_read` 계산 방식 명확화** — 문서에 실제 요금 한도 계산 비율 명시 2. **유효 토큰 기준 제한** — `cache_read`를 1/10 비율로 계산하도록 수정 3. **세션 유휴 감지** — 비활성 세션의 자동 호출 방지 또는 경고 표시 4. **실시간 토큰 소비 가시화** — `cache_read`, `cache_create`, 입력·출력별 사용량 표시 5. **컨텍스트 기반 비용 예측** — 작업 전 예상 토큰 비용 표시 ### 커뮤니티 분석 및 논의 - ## cnighswonger - `claude-code-cache-fix` 인터셉터로 24시간 동안 1,500회 호출 데이터를 수집 - 세 가지 가설(`cache_read` 0.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에 핵심 컨텍스트 사전 로드**를 제안 - ## bcherny (Anthropic 팀) - 1M 컨텍스트 윈도우 사용 시 **프롬프트 캐시 미스가 고비용**임을 인정 - UX 개선(장기 세션 재개 시 `/clear` 유도)과 **기본 컨텍스트를 400k로 축소**하는 방안을 실험 중 - 다중 에이전트·플러그인 사용 시 비활성 작업이 토큰을 과소비하는 사례를 확인, **자동 정리 및 스케줄링 개선**을 진행 중 - ## wadabum - 신규 세션에서 캐시가 전혀 적중하지 않는 버그([#47098](https://github.com/anthropics/claude-code/issues/47098), [#47107](https://github.com/anthropics/claude-code/issues/47107))를 지적 - `git status` 기반 시스템 프롬프트와 `CLAUDE.md` 블록이 매 세션마다 달라져 **캐시 무효화(cache busting)** 발생 - **cnighswonger**는 인터셉터가 일부 정렬 안정화를 수행하지만, `git-status` 문제는 별도 수정이 필요하다고 응답 ### 커뮤니티 제안 요약 - **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`)을 통한 추가 데이터 수집을 요청함 ## Comments ### Comment 55198 - Author: kimjoin2 - Created: 2026-04-13T14:50:54+09:00 - Points: 1 퀄리티로 따지면 대체할것도 없고 간단한 패치로 더 사용될 수 있으면 좋겠내요. ### Comment 55172 - Author: neo - Created: 2026-04-13T09:47:08+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47739260) - Claude Code 팀의 Boris임. 최근 보고된 문제들을 조사한 결과, 주요 원인은 두 가지임 1. **1M 토큰 컨텍스트 윈도우** 사용 시 프롬프트 캐시 미스가 비쌈. 현재 캐시 TTL이 1시간이라, 한 시간 이상 자리를 비우면 세션이 만료되어 전체 캐시를 다시 불러와야 함. 이를 개선하기 위해 UX 개선을 배포했고, 기본값을 400k로 낮추는 옵션을 검토 중임. 지금 바로 테스트하려면 `CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude` 명령을 사용하면 됨 2. 너무 많은 **플러그인이나 에이전트**를 동시에 실행하는 경우 토큰 낭비가 발생함. 이를 해결하기 위해 UX 개선과 비주요 작업의 자동 정리 및 스케줄링을 진행 중임 문제를 겪는 사용자는 `/feedback` 명령으로 피드백을 보내주면 디버깅에 도움이 됨 - Boris, 지금 커뮤니티에 올라오는 **사용자 경험담**이 단순한 예외가 아님. Jeff Bezos가 말했듯, 데이터가 아니라 **일화들이 진실을 말할 때**가 있음. 메트릭이 잘못된 게 아닌지 진지하게 검토해야 함 - 왜 갑자기 이런 문제가 생겼는지 의문이었는데, 조사해보니 **프롬프트 캐시 TTL이 1시간에서 5분으로 줄어든** 게 원인이었음. 세션을 새로 시작해도 결국 모든 걸 다시 빌드해야 하므로 비효율적임. 캐시 만료를 감시해야 하는 구조는 CC의 철학과 어긋남 - 내 경우 가장 심각한 회귀는 시스템 프롬프트가 매번 파일을 **악성코드 검사**하려고 하는 부분이었음. 이로 인해 토큰이 빠르게 소모되고, “not a malware” 응답이 계속 나왔음. 이런 설계는 잘못된 판단임. 결국 프로젝트를 중단하고 Qwen으로 옮겼는데 꽤 괜찮음 - `/clear` 알림은 해결책이 아님. 캐시를 비우면 결국 다시 빌드해야 하므로 비용은 동일함. UX로 사용자를 **작은 컨텍스트로 유도**하는 건 서비스 품질 저하임. 비용 문제라면 가격이나 아키텍처를 고쳐야 함 - OpenAI는 문제가 생기면 **사용량 한도를 초기화**해줬는데, Anthropic은 그런 조치가 없음. 이번 일은 의도적이라는 인상임 - 최근 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가 생성한 노이즈**로 보임. 내가 한 해결책은 다음과 같음 1. 모든 세션에서 **max thinking**을 켜서 불필요한 경로 탐색을 줄임 2. 세션을 계속 활성 상태로 유지함. 캐시가 5분 만에 만료되면 토큰을 다시 빌드해야 함 3. 200k 토큰 이후엔 바로 compact 실행 Anthropic이 강제로 1M 모델을 적용한 게 가장 불만임 - 나도 이슈를 보고 웃었음. 아마 Claude Code에게 “왜 토큰이 다 썼는지 조사하라”고 시킨 결과일 듯 - 어떤 사람은 thinking을 켜라 하고, 어떤 사람은 끄라 함. 둘 다 **토큰 절약**이라니 아이러니함 - 캐시가 **무작위로 무효화**되는 버그가 핵심임. API 클라이언트가 구독자 캐시를 조기 종료시키는 듯함. 게다가 입력 토큰 비용도 몰래 올림 - 나도 확인함. max effort가 도움이 됨. 컨텍스트를 25% 이하로 유지하는 게 중요함. 캐시 만료 상태를 확인할 방법이 있는지 궁금함 - `/model opus`나 `/model sonnet` 명령으로 1M 모델을 끌 수 있음 - 이제 **보조금 시대의 끝**이 다가오는 느낌임. Google Gemini 커뮤니티에서도 최근 **쿼터 축소**로 불만이 폭주 중임 ([이슈 링크](https://github.com/google-gemini/gemini-cli/issues/24937)). 나도 결국 Kiro IDE와 Codex CLI 조합으로 옮겼고 만족 중임 - 이런 변화는 예견된 일이었음. 무료 토큰 시절에 필요한 **라이브러리들을 미리 구축**해두는 게 현명한 전략이었음 - Anthropic이 이제 **기업 고객 중심**으로 전환 중이고, OpenAI도 비슷한 길을 걷고 있음. Reddit과 Discord에서는 오픈모델이나 중국산 대안을 찾는 움직임이 있지만 완전한 대체재는 없음 - antigravity는 프로 쿼터를 빠르게 소모하지만, **flash 모드**는 훨씬 관대함. STM32 프로젝트를 진행하며 3배 빠른 생산성을 얻었음 - 결국 이 흐름의 끝은 **출력에 광고가 붙는 시대**일지도 모름 - 예전 $3짜리 Uber 택시가 떠오름 - 문제의 근본 원인을 지적한 [이슈](https://github.com/anthropics/claude-code/issues/46829)가 **“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에 올라온 [업데이트 공지](https://www.reddit.com/r/ClaudeAI/comments/1s4idaq/update_on...) 이후로 Claude가 **일상 코딩용으로 쓸 수 없을 정도**로 변했음. Pro 계정 크레딧이 한 시간 만에 소진되어 Gemini나 ChatGPT로 돌아감 - 결국 Anthropic의 **토큰 과금 구조**가 일반 사용자에게 불리하게 설계된 듯함. 실제로 써보면 그들이 얼마나 많은 돈을 원했는지 바로 느껴짐