3P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • 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, #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)을 통한 추가 데이터 수집을 요청함
Hacker News 의견들
  • 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 커뮤니티에서도 최근 쿼터 축소로 불만이 폭주 중임 (이슈 링크). 나도 결국 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로 옮길까 고민 중임

    • 나도 ~/.bashrcCLAUDE_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의 토큰 과금 구조가 일반 사용자에게 불리하게 설계된 듯함. 실제로 써보면 그들이 얼마나 많은 돈을 원했는지 바로 느껴짐