최근 Claude Code를 사용하면서 "어라, 5시간 제한에 전혀 걸리지 않는데?"라고 느끼지 않으십니까? 기분 탓이 아닙니다. 2026년 5월, Anthropic은 Claude / Claude Code의 이용 상한을 연달아 인상했습니다. 본 기사에서는 그 완화 내용을 공식 소스로 확인하면서, 제가 Opus 4.8을 **$100 플랜 (Max 5x)**으로 본격적으로 돌린 실측 데이터를 통해 "실제로 어느 정도 여유가 있는지"를 확인해 보겠습니다.

검증 환경: NVIDIA DGX Spark (GB10 / aarch64・Ubuntu 24.04) 상의 Claude Code v2.1.157. 본 기사의 커맨드는 기본적으로 OS에 의존하지 않으나, aarch64 고유의 차이가 발생하는 부분에 대해서만 주석을 답니다.

• 2026년 5월, Claude Code의 상한은 3단계로 완화되었습니다 (4월: 스로틀링 (Throttling) 철폐 → 5/6: 5시간 프레임 2배 → 5/13: 주간 +50%).
• 또한 5/28의 Opus 4.8 출시 시에도, ClaudeDevs가 "Claude Code의 레이트 리밋 (Rate Limit)을 인상했다"고 명시했습니다 (Effort 증가에 따른 토큰 소비 대응).
• **"5시간 프레임이 좀처럼 줄지 않는다"는 체감의 주된 원인은 5/6의 "5시간 프레임 2배" (영구 조치)**입니다.
• 단, 5/13의 "주간 +50%"는 7/13까지의 잠정 조치입니다. 이 부분은 혼동에 주의하십시오.
• 저의 실측 로그(이 머신)에서는 5월 한 달 동안에만 약 6.14억 토큰을 소비했습니다. 그중 약 98%는 캐시 (Cache) 읽기였습니다.
• 그럼에도 현재 이 계정 (Max 5x / $100)은 **5시간 프레임 6% · 주간 16%**만을 사용하고 있습니다 (후술할 /usage 실측).
• 자신의 소비량은 /usage (공식) 또는 ccusage (서드파티)로 측정할 수 있습니다. 방법도 기재하겠습니다.

체감상 "줄어들지 않는다"는 느낌의 이면에는 실제로 여러 번의 공지가 있었습니다. 시계열로 나열합니다.

① 4월: 스로틀링 (Throttling) 철폐
혼잡한 시간대에 속도나 상한이 제한되는 동작 (Pro/Max・Claude Code)이 철폐되었습니다. 우선 "느려지기 어려워진" 것이 이 단계입니다.

② 5/6: 5시간 프레임 2배
Pro / Max / Team / 시트형 Enterprise를 대상으로, 5시간 로링 (Rolling) 프레임의 상한이 2배가 되었습니다. Anthropic은 배경으로 SpaceX / Colossus 1 유래의 계산 자원 증강을 꼽고 있습니다. 이는 영구 조치로 공지되었으며, "5시간 프레임이 좀처럼 줄지 않는다"는 체감의 주된 원인이 바로 이것입니다.

③ 5/13: 주간 상한 +50%
게다가 주간 상한이 +50% 되었습니다. 다만 이것은 공식 (@ClaudeDevs) 공지에서 7/13까지의 잠정 조치라고 되어 있습니다. 연장되지 않으면 실효된다는 점에 주의하십시오.

⚠️ 혼동 주의: ② (영구・5시간 프레임・2배)와 ③ (잠정・주간・+50%)는 별개입니다. 본 기사에서 몇 번 언급하겠지만, ③의 주간 +50%는 기간 한정입니다.

체감상으로는 "어느샌가 완화되어 있었다"였지만, 사실로서는 각 단계 모두 공식 공지가 있었습니다 (몰래 한 것이 아닙니다). 뉴스를 쫓지 않으면 알아차리기 어려웠을 뿐이라는 것이 정확한 상황입니다.

[참고: Max 5x의 구조]

• Max 5x는 공식 표현으로 "Pro의 약 5배 / 세션"입니다.
• 구조는 5시간 로링 (Rolling) 프레임 + 주간 상한 2개 ("전 모델 횡단" + "Sonnet 계열")입니다. 주간 상한은 세션 시작으로부터 7일 후에 리셋됩니다.
• Claude (채팅)와 Claude Code는 동일한 상한을 공유합니다.
• 참고로 2025년 8월 발표 시점 (Max 5x)의 주간 기준은 Sonnet 140–280h/주・Opus 15–35h/주였습니다. 다만 그 이후 +50% 반영 후의 구체적인 수치는 공식적으로 발표되지 않았으므로, 여기서는 단정하지 않겠습니다.

저의 생생한 감상은 다음과 같았습니다.

Opus 4.8 (1M context・max effort)을 $100 (Max 5x)로, 여러 에이전트 (Agent)를 병행시켜 본격적으로 사용해 보았는데, 5시간 제한조차 좀처럼 줄어들지 않는다. 이번 업데이트로 토큰 제한도 슬그머니 인상된 듯한데, 이는 고마운 일이다. 다만, 추론 (Inference) 시간은 조금 길어진 느낌이 든다.

이 "추론이 길어진 느낌이 든다"는 것은 기분 탓이 아니라, 사양대로입니다. 순서대로 설명하겠습니다.

정리하자면, 5/6(5시간 프레임 2배)와 5/13(주간 +50%)은 Opus 4.8의 출시(5/28)와는 별개의 타이밍에 이루어진 완화입니다(둘 다 계산 자원 증강을 바탕으로 하고 있지만, 섞어서 이해하면 오해의 소지가 있습니다).

하지만 Opus 4.8의 출시 자체에도 Claude Code의 레이트 리밋(Rate Limit, 속도 제한) 인상이 포함되어 있었습니다. @ClaudeDevs가 X(5/28)에서 다음과 같이 명시했습니다.

Opus 4.8 defaults to high effort. For coding tasks, it spends similar tokens to the 4.7 default while delivering better performance. For difficult tasks and long-running async work, use xhigh.

We've increased rate limits in Claude Code to accommodate the increased token usage. (번역: 4.8은 기본적으로 high effort입니다. 코딩 작업 시 4.7 기본 설정과 비슷한 토큰을 사용하면서도 더 나은 성능을 제공합니다. 어렵거나 장시간 실행되는 비동기 작업에는 xhigh를 사용하세요. 증가한 토큰 사용량에 맞춰 Claude Code의 레이트 리밋을 인상했습니다.)

동일한 취지의 내용이 공식 공지(Opus 4.8의 "A note on effort")에도 명시되어 있습니다.

We have increased rate limits in Claude Code to accommodate the higher token usage of higher effort levels.

즉, "추론을 깊게 한 만큼 상한선도 올려두었다"라는 설계로, effort 증가와 레이트 리밋 인상은 세트로 제공된 것입니다. 서두에서 언급한 "슬그머니 토큰 제한도 올라갔다"의 정체 중 하나가 바로 이것이었습니다.

Opus 4.8에는 low / medium / high / xhigh / max라는 effort (추론의 깊이) 설정이 있습니다.

• 4.8의 기본값은 high입니다 (4.7은 high / xhigh였습니다).
• max는 가장 깊게 생각하는 설정으로, 레이턴시(Latency)가 최대화됩니다.

즉, 제가 max effort로 돌렸기 때문에 "느리다"고 느낀 것은 당연하며, 이는 깊게 생각하게 만든 것에 대한 대가입니다.

출처(공식 docs): 모델 설정 / Claude Opus 4.8

• effort를 낮추기 (max → high / medium): 일상적인 코딩이라면 high만으로도 충분히 빠르고 똑똑합니다.
• Fast mode 사용하기: 출력이 약 2.5배 빨라집니다 (effort와는 별개의 축인 설정입니다).
• 1M context: Max 계열에서는 Opus가 자동으로 1M을 적용합니다 (추가 설정 불필요, 200K를 초과해도 가격은 그대로 유지). 긴 문맥을 던져도 상한선 문제로 곤란해질 일이 적은 것이 "줄어들지 않는다"는 체감에 기여하고 있습니다.
• "여러 에이전트를 본격적으로" 사용하는 파티라면, 리서치 프리뷰의 Dynamic workflows (수백 개의 서브 에이전트를 병렬로 실행)도 있습니다. 병렬도가 높아질수록 후술할 캐시 읽기(Cache Read)의 효과가 커집니다.

"상한선이 완만하다"라고 해도 체감만으로는 설득력이 부족하므로, 이 머신의 실제 로그를 보겠습니다. 사용한 것은 후술할 ccusage입니다. 수치는 모두 **Claude Code 이용분 (이 머신의 로컬 로그)**입니다.

여기서 가장 흥미로운 점은 **캐시 읽기가 약 98%**라는 점입니다. 즉, 사용자가 키보드로 입력하는 입력값(약 2.9만 토큰)은 거의 오차 범위이며, 소비의 대부분은 "과거의 문맥을 다시 읽는" 프롬프트 캐시의 재로드입니다. 에이전트를 병렬로 돌릴수록 이 부분이 강력한 효과를 발휘합니다.

• 피크 시간대 5시간 프레임 ≈ 9,830만 토큰 (API 환산 ≈ $58 상당). 단 하나의 프레임만으로도 사용량이 적은 날의 "하루 전체"를 가볍게 뛰어넘습니다.
• 가장 사용량이 많았던 날은 5/20 ≈ 1.19억, 그다음은 5/10 ≈ 1.15억.
• 월내 active한 5시간 블록(block)은 24개 정도. 대부분은 작고, 그 사이에 긴 유휴 시간이 있는 버스트형 (Burst type) 이었습니다 (몇 차례의 무거운 세션에 소비가 집중됨).
• 모델은 opus-4-7이 주체였으며, 5/29 이후 opus-4-8로 이행, haiku-4-5도 약간 포함되었습니다.

솔직히 말씀드리면, 위의 무거운 소비에는 별도 계정으로 돌리던 시기의 로그도 포함되어 있기 때문에, "$100 상한선에 대해 엄밀히 몇 %"라고 단정 지어 말할 수는 없습니다 (로컬 로그는 계정을 넘나들며 축적되기 때문입니다).

그래서, 현재 작동 중인 $100 (Max 5x) 계정의 "진정한 여유"는 공식적인 /usage로 확인합니다.

/usage

의 실측 (이 계정·Max 5x／$100·2026-05-30 취득)

• 현재 5시간 프레임: 6% (리셋 14:50 JST)
• 주간 (전 모델 통합): 16% (리셋 6/2 14:00 JST)
• 주간 (Sonnet 계열): 9% (리셋 6/2 14:00 JST)

실제로 이 기사를 작성한 세션을 통째로 포함하더라도, **현재 5시간 프레임의 사용률은 불과 6%**입니다. 주간으로도 전 모델 통합 16%입니다. "여러 에이전트를 본격적으로" 돌려도, $100 플랜으로 1세션 진지하게 개발한 정도로는 상한선의 발치에도 미치지 못한다는 것이 공식 실측치로 확인되었습니다.

"나는 얼마나 쓰고 있는 걸까"는 두 가지 방법으로 측정할 수 있습니다.

Claude Code의 프롬프트에 /usage를 입력하기만 하면 됩니다. 주로 다음 세 가지 미터(meter)가 나타납니다.

• 현재 5시간 프레임 사용 % (＋리셋 시각)
• 주간 (전 모델 통합) 사용 % (＋리셋 시각)
• 주간 (Sonnet 계열) 사용 % (＋리셋 시각)

5시간 프레임은 첫 프롬프트로부터 5시간의 로링 (Rolling) 방식이며, 고정된 "매시 0분 리셋"이 아닙니다 (리셋 시각 = 첫 프롬프트 시각 + 5h). 또한 최근에는 "무엇이 상한선 소비에 영향을 주고 있는가"에 대한 내역 (최근 24h: 서브 에이전트를 다용도한 세션이나 무거운 스킬 등) 및 추가 프레임 (Usage credits) 상황도 표시되며, d / w로 일간·주간 표시를 전환할 수 있습니다.

공식 수치이므로, "내 계정이 실제로 얼마나 남아 있는지"를 알고 싶다면 우선 이것을 확인해야 합니다.

ccusage (@ryoppippi 제작·MIT)는 로컬의 ~/.claude/projects/*.jsonl을 읽기만 하는 도구입니다.

외부 전송 없음·로그인 불필요로, 토큰의 내역이나 비용 환산치를 제공합니다.

# 최신 버전을 즉시 실행 (설치 불필요)
bunx ccusage@latest
# Claude Code 분량만으로 좁히기
...

blocks가 이번에 가장 유용합니다. 5시간 프레임 단위로 토큰과 (추정) 비용이 나열되므로, "어느 프레임에서 얼마나 사용했는지", "지금 프레임은 남은 양이 몇 %인지"를 한눈에 알 수 있습니다.

aarch64 메모: DGX Spark (aarch64·Bun 1.3.9 / Node v22)에서도 bunx ccusage@latest는 처음부터 문제없이 작동했습니다. x86과 차이는 없습니다.

ccusage가 산출하는 금액은 "만약 종량제 (API)였다면 이 요금"이라는 환산값입니다. Max / Pro는 정액제이므로, 이 $ 금액은 실제 결제 금액이 아닙니다. 저의 "약 $429" 역시 정액 플랜 내에서 작동하는 한 추가 청구는 제로입니다. 어디까지나 "API 환산 시 이만큼 일시켰다"라는 지표로 읽어주시기 바랍니다.

낙관적인 기사입니다만, 공정성을 위해 몇 가지 주의사항을 남겨둡니다.

• **주간 +50%는 "7/13까지의 잠정 조치"**입니다. 영구적인 것은 5/6의 "5시간 프레임 2배"입니다. 연장 공지가 없다면 주간 한도는 원래대로 돌아갑니다.
• max effort는 똑똑하지만 느립니다. 더 빠르게 하고 싶다면 effort를 낮추거나 fast mode를 사용하세요. 지능과 속도는 트레이드오프 (Trade-off) 관계입니다.

느린 것은 사양(Specification)입니다.

• ccusage의 $는 API 환산값이며, 정액제 플랜의 실제 결제 금액이 아닙니다.

• 공식 측에서 구체적인 상한 수치를 공개하지 않은 부분이 있으므로, 본 기사에서도 "몇 토큰에서 한계에 도달한다"라고 단정 짓지는 않았습니다. 정확한 현재 수치는 각자 /usage를 통해 확인하시기 바랍니다.

• 이것은 2026년 5월 말 시점의 스냅샷입니다. 상한 정책은 향후에도 변경될 수 있습니다.

• 2026년 5월, Claude Code의 상한은
  **4월 스로틀링(Throttling) 철폐 → 5/6 5시간 프레임 2배(영구적) → 5/13 주간 단위 +50%(7/13까지 잠정)**와 같이 3단계로 완화되었습니다.

• "5시간 프레임이 줄어들지 않는다"라고 체감되는 주된 원인은 5/6의 영구적 2배 적용입니다. 주간 +50%는 한시적이므로 혼동하지 마십시오.

• 모두 공식적으로 발표된 내용입니다 (슬그머니 발표되었을지언정, 몰래 한 것은 아닙니다).

• "추론이 길다"는 것은 **Opus 4.8의 effort 설정 (max=최심=최저속)**에 의한 것으로 사양대로 작동하는 것입니다. 더 빠르게 하고 싶다면 effort를 낮추거나 fast mode를 사용하세요.

• 자신의 소비량은 /usage(공식·계정 실측치)와 ccusage(로컬 집계·$는 API 환산)로 측정할 수 있습니다.

• 저의 실제 로그를 보면 5월 한 달 동안 약 6.14억 토큰을 사용했으며, **캐시(Cache) 비율은 약 98%**였습니다. 그럼에도 현재의 5시간 프레임은 6%, 주간 단위는 **16%**밖에 사용하지 않았습니다. 지금은 확실히 "행복한" 시기일지도 모릅니다.

• 5시간 프레임 2배 / SpaceX (공식): https://www.anthropic.com/news/higher-limits-spacex

• Claude Opus 4.8 (공식, "A note on effort"에 레이트 리밋(Rate Limit) 상향 기재): https://www.anthropic.com/news/claude-opus-4-8

• Opus 4.8 출시 시의 "Claude Code 레이트 리밋 상향" (@ClaudeDevs / X · 5/28): https://x.com/ClaudeDevs/status/2060043211129909732

• 모델 설정 / effort (공식 docs): https://code.claude.com/docs/en/model-config

• Max 플랜이란 (공식): https://support.claude.com/en/articles/11049741-what-is-the-max-plan

• 주간 상한의 발단 2025/8 (TechCrunch): https://techcrunch.com/2025/07/28/anthropic-unveils-new-rate-limits-to-curb-claude-code-power-users/

• 주간 +50% (7/13까지 잠정): https://apidog.com/blog/claude-code-weekly-limits-50-percent-increase-july-2026/

• ccusage: https://github.com/ryoppippi/ccusage