속도 제한 (Rate Limits)

Anthropic은 API 악용을 막고 용량을 관리하기 위해, 한 조직이 Claude API를 얼마나 쓸 수 있는지에 제한을 둬요. 이 페이지에서 다루는 제한은 두 종류로 나뉘어요.

지출 한도(Spend limits) — 조직이 한 달에 API 사용으로 지출할 수 있는 최대 비용이에요.
속도 제한(Rate limits) — 조직이 정해진 시간 동안 만들 수 있는 API 요청의 최대 수예요.

API는 조직 단위로 설정된 서비스 제한을 적용하지만, 각 워크스페이스에 대해 사용자가 직접 낮춰서 정할 수도 있어요.

속도 제한 개요

제한은 API 남용을 막도록 설계됐지만, 일반적인 사용 패턴에는 영향을 최소화하도록 잡혀 있어요. 조직은 사용 내역과 계정 상태에 따라 자동으로 특정 사용 티어(usage tier)에 배치되고, API를 쓸수록 더 높은 티어로 올라갈 수 있어요.

새 조직이나 사용 내역이 적은 조직은 Evaluation 티어에서 시작할 수 있는데, 이때 제한은 이 페이지에 나온 표준 제한보다 낮아요. 이 시작 제한은 Anthropic이 사기와 남용을 막는 방식의 일부이며, 조직이 사용 내역을 쌓아갈수록 자동으로 늘어나요.

제한은 조직 단위로 설정돼요. 조직의 티어와 현재 제한은 Claude Console의 Rate limits 페이지에서 확인할 수 있어요. 그리고 속도 제한은 더 짧은 시간 간격으로 걸리기도 해요. 예를 들어 분당 60회(RPM) 제한이 초당 1회로 enforce될 수 있어요. 짧은 순간에 요청이 몰리면 한도를 넘어 속도 제한 오류가 발생할 수 있으니 주의하세요.

API는 속도 제한에 **토큰 버킷 알고리즘(token bucket algorithm)**을 사용해요. 즉 용량이 고정 간격으로 리셋되는 게 아니라, 최대 한도까지 연속적으로 보충돼요.

여기 설명된 모든 제한은 최대 허용 사용량이지, 보장된 최소치가 아니에요. 이 제한은 의도치 않은 과지출을 줄이고 사용자 간 자원을 공정하게 배분하기 위한 거예요.

지출 한도

Start, Build, Scale 티어에는 각각 월별 지출 상한이 붙어 있어요. 이 상한은 조직이 매달 API에 쓸 수 있는 최대 금액이에요. 월별 지출 상한을 확인하거나 직접 한도를 설정하려면 Billing 페이지에서 할 수 있어요.

사용 티어	월별 지출 상한
Start	$500 USD
Build	$1,000 USD
Scale	$200,000 USD

Custom 티어 조직에는 월별 지출 상한이 없어요. 한도는 계정 팀과 별도로 협의해요.

지출 상한에 도달했을 때

조직이 티어의 지출 상한에 도달하면, 더 높은 한도를 요청하지 않는 한 다음 달 1일 00:00 UTC까지 API 사용이 중단돼요. 사용이 중단되는 동안 API 요청은 HTTP 429를 반환해요.

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "You have reached your API usage limits: your organization has crossed its monthly API usage threshold, set based on your organization's API tier. You will regain access on 2026-09-01 at 00:00 UTC.",
    "details": { "error_code": "enforced_spend_limit_reached" }
  },
  "request_id": "req_018EeWyXxfu5pfWkrYcMdjWG"
}

오류 타입은 rate_limit_error로 속도 제한과 같지만, 응답에 retry-after 헤더가 없어요. SDK의 자동 재시도를 포함해 재시도해도 접근이 재개될 때까지 실패해요. Messages API에서는 error.details.error_code가 enforced_spend_limit_reached이므로 이 값으로 속도 제한 응답과 구분할 수 있어요. 더 높은 티어로 올리면 접근이 복구돼요.

나만의 지출 한도 설정하기

조직의 티어 상한보다 낮은 한도를 직접 설정해 비용을 통제할 수도 있어요.

Claude Console에서 Settings > Billing으로 이동해요.
Spend limits 섹션에서 Adjust limit을 클릭해요 (현재 한도가 없으면 Set limit).
새 값을 입력해요. 지출 한도는 현재 티어의 상한을 넘을 수 없어요.

직접 설정한 지출 한도에 도달하면 요청이 HTTP 400, 오류 타입 invalid_request_error를 반환해요. 메시지는 You have reached your specified API usage limits로 시작하거나, 워크스페이스 한도일 땐 You have reached your specified workspace API usage limits로 시작하며 접근이 재개되는 시점을 알려줘요. 한도를 올리거나 없애면 더 빨리 복구돼요.

Claude Code 워크스페이스의 한도는 별도로 확인돼요. 해당 워크스페이스 한도를 넘는 Claude Code 요청은 retry-after 헤더가 달린 429를 받을 수 있어요.

속도 제한

Messages API의 속도 제한은 모델 클래스별로 분당 요청 수(RPM), 분당 입력 토큰 수(ITPM), **분당 출력 토큰 수(OTPM)**로 측정돼요. 어떤 속도 제한이든 초과하면, 어떤 제한을 넘었는지와 얼마나 기다려야 하는지(retry-after 헤더) 를 알려주는 429 오류가 반환돼요.

조직의 사용량이 급격히 늘면 API의 가속 제한(acceleration limits) 때문에 429를 만날 수도 있어요. 가속 제한을 피하려면 트래픽을 점진적으로 늘리고 사용 패턴을 일정하게 유지하세요.

캐시 인식 ITPM

많은 API 제공자는 "분당 토큰 수(TPM)" 제한에 캐시된 토큰과 캐시되지 않은 토큰, 입력·출력 토큰을 모두 합쳐 넣어요. 하지만 대부분의 Claude 모델에서는 캐시되지 않은 입력 토큰만 ITPM 제한에 포함돼요. 이게 속도 제한을 겉으로 보이는 것보다 실질적으로 높게 만드는 핵심 이점이에요.

ITPM 제한은 각 요청 시작 시 추정되고, 요청 중에 실제 사용된 입력 토큰 수를 반영해 조정돼요.

ITPM에 포함되는 항목은 이래요.

input_tokens (마지막 캐시 breakpoint 이후의 토큰) ✓ ITPM에 포함
cache_creation_input_tokens (캐시에 쓰이는 토큰) ✓ ITPM에 포함
cache_read_input_tokens (캐시에서 읽은 토큰) ✗ 대부분의 모델에서는 ITPM에 포함 안 됨

input_tokens 필드는 요청의 모든 입력 토큰이 아니라, 마지막 캐시 breakpoint 이후에 나타나는 토큰만 나타내요. 총 입력 토큰을 계산하려면:

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

즉 캐시된 콘텐츠가 있으면 input_tokens는 총 입력보다 훨씬 작아지는 경우가 많아요. 예를 들어 200k 토큰의 캐시된 문서와 50토큰의 사용자 질문이 있으면, 총 입력이 200,050토큰이어도 input_tokens: 50으로 보여요. 대부분의 모델에서 ITPM 한도에는 input_tokens + cache_creation_input_tokens만 포함되므로, 프롬프트 캐싱이 실질적 처리량을 늘리는 효과적인 방법이 돼요.

예시: ITPM 제한이 2,000,000이고 캐시 적중률이 80%라면, 분당 총 10,000,000 입력 토큰을 처리할 수 있어요(2M 비캐시 + 8M 캐시). 캐시된 토큰은 속도 제한에 포함되지 않기 때문이에요.

참고로 Claude Haiku 3.5(아래 속도 제한 표에서 각주 4로 표시)는 cache_read_input_tokens를 ITPM 제한에 포함해요. 그 외 모든 모델에서는 캐시된 입력 토큰이 속도 제한에 포함되지 않고, 기본 입력 가격의 일부인 캐시 읽기 요금으로 청구돼요. 프롬프트 캐싱을 쓰면 실질적 처리량을 크게 높일 수 있는 이유예요.

속도 제한을 최대한 활용하려면 시스템 지시문, 프롬프트, 큰 컨텍스트 문서, 도구 정의, 대화 히스토리처럼 반복되는 콘텐츠를 캐시하세요. 효과적인 캐싱으로 속도 제한을 올리지 않고도 실제 처리량을 크게 늘릴 수 있어요. 캐시 적중률은 Usage 페이지에서 모니터링하며 캐싱 전략을 조정하면 돼요.

OTPM 제한은 출력 토큰이 생성되는 대로 실시간으로 평가되며, 실제 생성된 토큰만 세요. max_tokens 파라미터는 OTPM 제한 계산에 포함되지 않으므로, 더 높은 max_tokens를 설정해도 속도 제한 측면에서 손해는 없어요.

속도 제한은 모델마다 별도로 적용돼요. 그래서 각 모델의 제한까지 동시에 서로 다른 모델을 사용할 수 있어요. 현재 속도 제한과 동작은 Claude Console의 Rate limits 페이지에서 확인하거나, Rate Limits API로 프로그래밍 방식으로 읽을 수 있어요.

속도 제한은 현재 모든 inference_geo 값에 걸쳐 공유돼요. inference_geo: "us" 요청과 inference_geo: "global" 요청은 같은 속도 제한 풀을 사용해요.

속도 제한 표

각 티어의 표준 속도 제한이에요. (아래는 Start 티어 값. Build/Scale 티어는 지출 상한과 배치 제한이 다르며, Custom 티어는 계정 팀과 협의.)

모델	분당 최대 요청 수(RPM)	분당 최대 입력 토큰(ITPM)	분당 최대 출력 토큰(OTPM)
Claude Fable 5.x¹	1,000	500,000	100,000
Claude Opus 5	1,000	2,000,000	400,000
Claude Opus 4.x²	1,000	2,000,000	400,000
Claude Sonnet 5	1,000	2,000,000	400,000
Claude Sonnet 4.x³	1,000	2,000,000	400,000
Claude Haiku 4.5	1,000	2,000,000	400,000
Claude Haiku 3.5 (은퇴, Bedrock·Google Cloud 제외)	1,000	100,000⁴	20,000

¹ Fable 제한은 Claude Fable 5.1과 Claude Fable 5의 합산 트래픽에 적용되는 총 제한이에요. Claude Mythos 5.1과 Claude Mythos 5는 같은 조건의 별도 합산 제한을 공유해요.
² Opus 제한은 Claude Opus 4.8, Opus 4.7, Opus 4.6, Opus 4.5의 합산 트래픽에 적용되는 총 제한이에요. Claude Opus 5는 별도 속도 제한을 가지며 이 합산 버킷에 포함되지 않아요.
³ Sonnet 4.x 제한은 Sonnet 4.6과 Sonnet 4.5의 합산 트래픽에 적용되는 총 제한이에요. Claude Sonnet 5는 별도 속도 제한을 가지며 이 버킷에 포함되지 않아요.
⁴ 이 모델은 cache_read_input_tokens를 ITPM 사용량에 포함해요.

Message Batches API

Message Batches API는 모든 모델에 걸쳐 공유되는 별도의 속도 제한을 가져요. 모든 API 엔드포인트에 적용되는 분당 요청 수(RPM) 제한과, 동시에 처리 큐에 있을 수 있는 배치 요청 수 제한이 포함돼요. 여기서 "배치 요청(batch request)"은 Message Batch의 일부를 뜻해요. 수천 개의 배치 요청을 담은 Message Batch를 만들 수 있고, 각각이 이 제한에 포함돼요. 배치 요청은 모델이 아직 성공적으로 처리하지 못한 경우 처리 큐의 일부로 간주돼요.

분당 최대 요청 수(RPM)	처리 큐의 최대 배치 요청 수	배치당 최대 배치 요청 수
1,000	200,000	100,000

Managed Agents

Claude Managed Agents 엔드포인트는 조직별로 속도 제한이 적용돼요. 이 제한은 위의 Messages API 속도 제한과 분리돼 있어요.

작업	제한
생성 엔드포인트 (예: agents, sessions, environments)	분당 300 요청
읽기 엔드포인트 (예: retrieve, list, stream)	분당 1,200 요청

Files API

Files API 요청은 조직별 고유한 제한을 가져요. 업로드, 목록, 조회, 다운로드, 삭제 작업에 걸쳐 공유되며, 앞서 설명한 Messages API 제한과는 분리돼요. 현재 값은 Files API 속도 제한 문서를 참고하세요.

Fast mode 속도 제한

Claude Opus 5 또는 Opus 4.8에서 speed: "fast"로 fast mode(연구 프리뷰)를 사용하면, 표준 Opus 속도 제한과 분리된 전용 속도 제한이 적용돼요. fast mode 속도 제한을 초과하면 API가 retry-after 헤더와 함께 429 오류를 반환해요. fast mode는 Claude Opus 4.7에서는 사용할 수 없고(요청 시 오류 반환), Claude Opus 4.6에서는 사용할 수 없어요(claude-opus-4-6에 speed: "fast" 요청이 표준 속도로 실행). 응답에는 fast mode 속도 제한 상태를 알려주는 anthropic-fast-* 헤더가 포함돼요.

콘솔에서 속도 제한 모니터링하기

Claude Console의 Usage 페이지에서 속도 제한 사용량을 모니터링할 수 있어요. 이 페이지는 토큰·요청 차트 외에도 별도의 속도 제한 차트 두 개를 제공해요. 이 차트들로 성장 여유(headroom)를 파악하고, 최대 사용 시점을 알며, 어떤 속도 제한을 요청할지 이해하고, 캐싱 비율을 개선하는 방법을 배울 수 있어요.

Rate Limit - Input Tokens 차트: 시간당 최대 비캐시 입력 토큰/분, 현재 ITPM 제한, 입력 토큰의 캐시율(캐시에서 읽은 입력 토큰 비율)
Rate Limit - Output Tokens 차트: 시간당 최대 출력 토큰/분, 현재 OTPM 제한

더 높은 제한 요청하기

더 높은 속도 제한이나 월별 지출 상한을 요청하려면 Rate limits 페이지의 Request rate limit increase를 사용해요. Anthropic 지원팀도 한도를 올려줄 수 있고, 긴급한 경우에는 지원팀에 연락하세요.

워크스페이스에 더 낮은 제한 설정하기

조직의 워크스페이스가 과도하게 사용되는 것을 막기 위해, 워크스페이스별로 맞춤 지출·속도 제한을 설정할 수 있어요.

예시: 조직의 제한이 입력 토큰 분당 40,000, 출력 토큰 분당 8,000이라면, 특정 워크스페이스를 입력 토큰 분당 30,000으로 제한할 수 있어요. 이렇게 하면 다른 워크스페이스를 과사용으로부터 보호하고 조직 전체에 자원을 더 공평하게 배분할 수 있어요. 남는 토큰/분(또는 그 워크스페이스가 한도를 쓰지 않으면 더 많은 양)은 다른 워크스페이스가 사용할 수 있어요.

기본 워크스페이스(default Workspace)에는 제한을 설정할 수 없어요.
설정하지 않으면 워크스페이스 제한은 조직의 제한과 일치해요.
워크스페이스 제한은 제한 유형별(분당 요청 수, 분당 입력 토큰 수, 분당 출력 토큰 수 등)로 설정돼요.
워크스페이스 제한을 합산해도 조직 전체 제한은 항상 적용돼요.

현재 조직 및 워크스페이스 속도 제한을 프로그래밍 방식으로 읽으려면 Rate Limits API를 사용하세요.

응답 헤더

API 응답에는 적용된 속도 제한, 현재 사용량, 제한이 리셋되는 시점을 보여주는 헤더가 포함돼요.

헤더	설명
`retry-after`	요청을 재시도할 수 있을 때까지 기다려야 하는 시간(초). 더 일찍 재시도하면 실패해요. 지출 상한 429에서는 전송되지 않아요.
`anthropic-ratelimit-requests-limit`	어떤 속도 제한 기간 내에 허용되는 최대 요청 수
`anthropic-ratelimit-requests-remaining`	속도 제한에 걸리기 전 남은 요청 수
`anthropic-ratelimit-requests-reset`	요청 속도 제한이 완전히 보충되는 시점 (RFC 3339 형식)
`anthropic-ratelimit-tokens-limit`	어떤 속도 제한 기간 내에 허용되는 최대 토큰 수
`anthropic-ratelimit-tokens-remaining`	속도 제한에 걸리기 전 남은 토큰 수 (가장 가까운 천 단위로 반올림)
`anthropic-ratelimit-tokens-reset`	토큰 속도 제한이 완전히 보충되는 시점 (RFC 3339 형식)
`anthropic-ratelimit-input-tokens-limit`	어떤 속도 제한 기간 내에 허용되는 최대 입력 토큰 수
`anthropic-ratelimit-input-tokens-remaining`	속도 제한에 걸리기 전 남은 입력 토큰 수 (가장 가까운 천 단위로 반올림)
`anthropic-ratelimit-input-tokens-reset`	입력 토큰 속도 제한이 완전히 보충되는 시점 (RFC 3339 형식)
`anthropic-ratelimit-output-tokens-limit`	어떤 속도 제한 기간 내에 허용되는 최대 출력 토큰 수
`anthropic-ratelimit-output-tokens-remaining`	속도 제한에 걸리기 전 남은 출력 토큰 수 (가장 가까운 천 단위로 반올림)
`anthropic-ratelimit-output-tokens-reset`	출력 토큰 속도 제한이 완전히 보충되는 시점 (RFC 3339 형식)
`anthropic-priority-input-tokens-limit`	어떤 속도 제한 기간 내에 허용되는 최대 Priority Tier 입력 토큰 수 (Priority Tier 전용)
`anthropic-priority-input-tokens-remaining`	속도 제한에 걸리기 전 남은 Priority Tier 입력 토큰 수 (가장 가까운 천 단위로 반올림) (Priority Tier 전용)
`anthropic-priority-input-tokens-reset`	Priority Tier 입력 토큰 속도 제한이 완전히 보충되는 시점 (RFC 3339 형식) (Priority Tier 전용)
`anthropic-priority-output-tokens-limit`	어떤 속도 제한 기간 내에 허용되는 최대 Priority Tier 출력 토큰 수 (Priority Tier 전용)
`anthropic-priority-output-tokens-remaining`	속도 제한에 걸리기 전 남은 Priority Tier 출력 토큰 수 (가장 가까운 천 단위로 반올림) (Priority Tier 전용)
`anthropic-priority-output-tokens-reset`	Priority Tier 출력 토큰 속도 제한이 완전히 보충되는 시점 (RFC 3339 형식) (Priority Tier 전용)

anthropic-ratelimit-tokens-* 헤더는 현재 적용 중인 가장 제한적인 제한의 값을 보여줘요. 예를 들어 워크스페이스의 분당 토큰 제한을 초과했다면 헤더에는 워크스페이스의 분당 토큰 속도 제한 값이 들어와요. 워크스페이스 제한이 적용되지 않으면, 토큰 총계(입력+출력 합)가 남은 총 토큰으로 반환돼요. 이렇게 해서 현재 API 사용에 가장 관련성 높은 제약을 한눈에 볼 수 있어요. 요청이 어느 워크스페이스에 포함됐는지 알려면 anthropic-workspace-id 응답 헤더를 읽으면 돼요. 이 헤더는 API 키나 액세스 토큰이 해석된 워크스페이스의 ID를 담아요.