요약: Anthropic은 2026년 6월 26일 Claude API rate limit을 상향하고 사용 티어를 Start, Build, Scale 세 단계로 정리했다. Sonnet과 Haiku의 rate limit이 Opus와 같은 수준으로 맞춰졌고, 대부분의 조직은 더 높은 한도로 이동한다. 운영팀이 봐야 할 포인트는 단순 RPM 숫자가 아니라 ITPM, OTPM, prompt caching, 429 재시도 설계다.
Claude Platform release note에 따르면 Anthropic은 Claude API 전반의 rate limit을 올렸다. Claude Sonnet과 Claude Haiku rate limit이 모든 사용 티어에서 Claude Opus와 같은 수준으로 맞춰졌고, 기존 usage tier는 Start, Build, Scale 세 단계로 통합됐다. Anthropic은 대부분의 조직이 더 높은 tier로 이동하며, 기존보다 낮은 limit을 받는 조직은 없고, 별도 조치는 필요 없다고 설명한다.
겉으로 보면 “한도가 올라갔다”는 뉴스지만, 실무 영향은 더 구체적이다. 대량 요약, 고객지원 자동화, 코드 리뷰, 에이전트 워크플로우처럼 분당 요청과 토큰 사용이 동시에 커지는 시스템에서 병목 지점이 달라진다. 이전에는 모델 선택이 품질·비용 중심이었다면, 이제는 동일한 tier 안에서 Sonnet·Haiku도 Opus급 처리량을 기대할 수 있어 라우팅 전략을 다시 짤 수 있다.
Claude API rate limit은 Messages API 기준으로 RPM(requests per minute), ITPM(input tokens per minute), OTPM(output tokens per minute)을 따로 본다. 단순히 “분당 1,000 요청이면 충분하다”고 계산하면 장애가 난다. 한 요청에 긴 문서와 많은 tool definition이 들어가면 RPM보다 ITPM이 먼저 찬다. 반대로 짧은 입력에서 긴 리포트를 생성하면 OTPM이 먼저 찬다.
Anthropic 문서는 Start tier 예시로 Claude Opus 4.x, Sonnet 4.x, Haiku 4.5가 1,000 RPM, 2,000,000 ITPM, 400,000 OTPM을 갖는다고 안내한다. Build tier에서는 5,000 RPM, 5,000,000 ITPM, 1,000,000 OTPM이고, Scale tier에서는 10,000 RPM, 10,000,000 ITPM, 2,000,000 OTPM이다. Claude Fable 5는 별도 수치가 적용된다.
운영팀은 세 숫자 중 최저 병목을 찾아야 한다. 예를 들어 요청당 uncached input이 10,000 tokens라면 Start tier의 2,000,000 ITPM은 이론상 분당 200건이다. RPM 1,000이 남아도 의미가 없다. 요청당 output이 2,000 tokens라면 400,000 OTPM도 분당 200건에서 막힌다. 실제 병목은 RPM이 아니라 input과 output token이다.
이번 문서에서 특히 봐야 할 부분은 cache-aware ITPM이다. Anthropic은 대부분의 Claude 모델에서 cached input tokens가 ITPM rate limit에 포함되지 않는다고 설명한다. input_tokens는 마지막 cache breakpoint 이후의 토큰을 의미하고, cache_read_input_tokens는 대부분의 모델에서 ITPM에 잡히지 않는다.
예를 들어 200,000 token 문서를 캐시해두고 사용자 질문 50 tokens만 새로 넣는 구조라면, total input은 200,050 tokens지만 rate limit 관점의 uncached input은 훨씬 작다. Anthropic 예시처럼 2,000,000 ITPM limit에서 cache hit rate가 80%라면 실질적으로 10,000,000 total input tokens per minute까지 처리할 수 있다.
이것은 긴 시스템 프롬프트, 대형 문서, tool schema, 반복 conversation history를 매번 그대로 보내는 서비스에 중요하다. 캐시를 제대로 쓰지 않으면 같은 tier에서도 5배 이상의 처리량 차이가 날 수 있다. 비용도 줄지만, 더 중요한 것은 429 빈도를 낮추고 tail latency를 안정화한다는 점이다.
Claude API는 rate limit 초과 시 429 error와 retry-after header를 반환한다. 하지만 문서에는 짧은 burst가 limit을 넘을 수 있고, 급격한 트래픽 증가에는 acceleration limit이 걸릴 수 있다고 되어 있다. 즉 평균 분당 사용량이 표 안의 숫자보다 낮아도, 짧은 시간에 몰아치면 실패할 수 있다.
실무에서는 token bucket을 전제로 큐를 설계해야 한다. 요청을 한 번에 쏘는 batch fan-out 방식보다, worker pool에서 ITPM·OTPM 예산을 추정하고 흘려보내는 방식이 안전하다. 429가 오면 즉시 재시도하지 말고 retry-after를 우선한다. SDK의 기본 재시도에만 맡기면 애플리케이션 큐가 같은 요청을 중복으로 밀어 넣어 더 큰 폭주를 만들 수 있다.
또한 max_tokens는 OTPM 계산에 직접 들어가는 값이 아니라 실제 생성된 output tokens가 평가된다. 그래도 지나치게 높은 max_tokens는 비용과 latency 예측을 흐리게 만든다. endpoint별 평균 output token을 측정하고, 리포트 생성·코드 생성·짧은 질의응답을 서로 다른 budget으로 나누는 편이 낫다.
Sonnet과 Haiku의 rate limit이 Opus 수준으로 맞춰졌다면, 기존의 “저렴한 모델은 처리량도 낮다”는 가정을 버려야 한다. 고빈도 분류, 짧은 요약, extraction은 Haiku 또는 Sonnet으로 몰고, 고난도 reasoning이나 긴 코드 변경만 Opus·Fable 계열로 보내는 라우팅이 더 합리적이다.
다만 모델별 context, tool compatibility, data retention 조건은 별도 확인이 필요하다. 예를 들어 Claude Fable 5는 1M token context와 adaptive thinking을 제공하지만, rate limit 수치와 데이터 보존 조건이 다르다. 무조건 최신 모델로 통합하기보다 workload별로 병목을 재측정해야 한다.
retry-after를 우선하고, acceleration limit을 피하려고 traffic ramp-up을 둔다.