Claude Platform on AWS: 이 페이지의 속도 제한은 Claude Platform on AWS에도 적용되지만, 청구 및 제한 관리 방식은 다릅니다. 청구는 AWS Marketplace를 통해 이루어집니다(Anthropic 크레딧 구매가 아님). Claude Platform on AWS의 조직은 Start 티어에 배치되며 사용량 티어 간에 자동으로 이동하지 않습니다. 더 높은 제한을 요청하려면 Anthropic 계정 담당자 또는 Anthropic 지원팀에 문의하세요. Request rate limit increase 플로우는 사용할 수 없습니다. 지출 제한은 Settings > Limits가 아닌 Settings > Billing에서 설정합니다. 워크스페이스별 속도 제한 구성 및 고속 모드는 Claude Platform on AWS에서 사용할 수 없습니다. 자세한 내용은 Claude Platform on AWS의 속도 제한 및 할당량을 참조하세요.
제한에는 두 가지 유형이 있습니다:
API는 조직 수준에서 서비스가 구성한 제한을 적용하지만, 조직의 워크스페이스에 대해 사용자가 구성할 수 있는 제한을 설정할 수도 있습니다.
Claude Platform on AWS: 지출 제한은 Claude Platform on AWS에서 다르게 작동합니다. Settings > Limits 대신 Settings > Billing에서 지출 제한을 설정하세요. 지출 상한과 자체 설정 지출 제한이 조직에 어떻게 적용되는지는 Claude Platform on AWS의 지출 제한을 참조하세요.
Start, Build, Scale 티어 각각에는 월간 지출 상한이 있으며, 이는 조직이 매 달력 월마다 API에 지출할 수 있는 최대 금액입니다. 티어의 지출 상한에 도달하면 더 높은 제한을 요청하지 않는 한 다음 달까지 API 사용이 일시 중지됩니다. Limits 페이지에서 조직의 월간 지출 상한을 확인할 수 있습니다.
| 사용량 티어 | 월간 지출 상한 |
|---|---|
| Start | $500 USD |
| Build | $1,000 USD |
| Scale | $200,000 USD |
Custom 티어의 조직에는 월간 지출 상한이 없으며, 제한은 계정 팀과 협의하여 정해집니다.
비용을 관리하기 위해 티어의 상한보다 낮은 자체 지출 제한을 설정할 수도 있습니다:
Limits 페이지로 이동
Claude Console에서 Settings > Limits로 이동합니다.
지출 제한 편집기 열기
Spend limits 섹션에서 Change Limit(또는 현재 설정된 제한이 없는 경우 Set spend limit)을 클릭합니다.
지출 제한 조정
새 값을 입력합니다. 지출 제한은 현재 티어의 상한을 초과할 수 없습니다.
Messages API의 속도 제한은 각 모델 클래스에 대해 분당 요청 수(RPM), 분당 입력 토큰 수(ITPM), 분당 출력 토큰 수(OTPM)로 측정됩니다.
속도 제한 중 하나라도 초과하면 어떤 속도 제한이 초과되었는지 설명하는 429 오류와 함께 얼마나 기다려야 하는지 나타내는 retry-after 헤더를 받게 됩니다.
조직의 사용량이 급격히 증가하는 경우 API의 가속 제한으로 인해 429 오류가 발생할 수도 있습니다. 가속 제한에 도달하지 않으려면 트래픽을 점진적으로 늘리고 일관된 사용 패턴을 유지하세요.
많은 API 제공업체는 캐시된 토큰과 캐시되지 않은 토큰, 입력과 출력을 모두 포함할 수 있는 통합된 "분당 토큰 수"(TPM) 제한을 사용합니다. 대부분의 Claude 모델에서는 캐시되지 않은 입력 토큰만 ITPM 속도 제한에 포함됩니다. 이는 속도 제한이 처음 보이는 것보다 실질적으로 더 높게 작동하도록 만드는 핵심적인 장점입니다.
ITPM 속도 제한은 각 요청 시작 시 추정되며, 요청 중에 실제 사용된 입력 토큰 수를 반영하도록 추정치가 조정됩니다.
ITPM에 포함되는 항목은 다음과 같습니다:
input_tokens (마지막 캐시 중단점 이후의 토큰) ✓ ITPM에 포함됨cache_creation_input_tokens (캐시에 기록되는 토큰) ✓ ITPM에 포함됨cache_read_input_tokens (캐시에서 읽은 토큰) ✗ 대부분의 모델에서 ITPM에 포함되지 않음input_tokens 필드는 요청의 모든 입력 토큰이 아니라 마지막 캐시 중단점 이후에 나타나는 토큰만 나타냅니다. 총 입력 토큰을 계산하려면:
total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens즉, 캐시된 콘텐츠가 있는 경우 input_tokens는 일반적으로 총 입력보다 훨씬 작습니다. 예를 들어, 200k 토큰의 캐시된 문서와 50 토큰의 사용자 질문이 있는 경우, 총 입력이 200,050 토큰임에도 불구하고 input_tokens: 50으로 표시됩니다.
대부분의 모델에서 속도 제한 목적으로는 input_tokens + cache_creation_input_tokens만 ITPM 제한에 포함되므로, 프롬프트 캐싱은 실질적인 처리량을 늘리는 효과적인 방법입니다.
예시: 2,000,000 ITPM 제한과 80% 캐시 적중률을 가진 경우, 캐시된 토큰은 속도 제한에 포함되지 않기 때문에 실질적으로 분당 총 10,000,000개의 입력 토큰(캐시되지 않은 2M + 캐시된 8M)을 처리할 수 있습니다.
Claude Haiku 3.5(다음 속도 제한 표에서 †로 표시됨)는 cache_read_input_tokens도 ITPM 속도 제한에 포함합니다.
† 표시가 없는 모든 모델의 경우, 캐시된 입력 토큰은 속도 제한에 포함되지 않으며 할인된 요금(기본 입력 토큰 가격의 10%)으로 청구됩니다. 즉, 프롬프트 캐싱을 사용하여 실질적인 처리량을 크게 높일 수 있습니다.
OTPM 속도 제한은 출력 토큰이 생성될 때 실시간으로 평가되며, 실제로 생성된 토큰만 계산합니다. max_tokens 매개변수는 OTPM 속도 제한 계산에 포함되지 않으므로, 더 높은 max_tokens 값을 설정해도 속도 제한 측면에서 불이익이 없습니다.
속도 제한은 각 모델에 대해 별도로 적용됩니다. 따라서 서로 다른 모델을 각각의 제한까지 동시에 사용할 수 있습니다. Claude Console의 Limits 페이지에서 현재 속도 제한과 동작을 확인하거나, Rate Limits API를 사용하여 구성된 제한을 프로그래밍 방식으로 읽을 수 있습니다.
속도 제한은 현재 모든 inference_geo 값에서 공유됩니다. inference_geo: "us"와 inference_geo: "global"을 사용하는 요청은 동일한 속도 제한 풀에서 차감됩니다.
| 모델 | 분당 최대 요청 수 (RPM) | 분당 최대 입력 토큰 수 (ITPM) | 분당 최대 출력 토큰 수 (OTPM) |
|---|---|---|---|
| Claude Fable 5 | 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 |
* 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에는 모든 모델에서 공유되는 자체 속도 제한이 있습니다. 여기에는 모든 API 엔드포인트에 대한 분당 요청 수(RPM) 제한과 동시에 처리 대기열에 있을 수 있는 배치 요청 수에 대한 제한이 포함됩니다. 여기서 "배치 요청"은 Message Batch의 일부를 의미합니다. 수천 개의 배치 요청을 포함하는 Message Batch를 생성할 수 있으며, 각각이 이 제한에 포함됩니다. 배치 요청은 모델에 의해 아직 성공적으로 처리되지 않은 경우 처리 대기열의 일부로 간주됩니다.
| 분당 최대 요청 수 (RPM) | 처리 대기열의 최대 배치 요청 수 | 배치당 최대 배치 요청 수 |
|---|---|---|
| 1,000 | 200,000 | 100,000 |
Claude Managed Agents 엔드포인트는 조직별로 속도 제한이 적용됩니다. 이러한 제한은 위의 Messages API 속도 제한과는 별개입니다.
| 작업 | 제한 |
|---|---|
| 생성 엔드포인트(예: 에이전트, 세션, 환경) | 분당 300개 요청 |
| 읽기 엔드포인트(예: 조회, 목록, 스트림) | 분당 1,200개 요청 |
Claude Opus 5, Opus 4.8 또는 Opus 4.7에서 speed: "fast"로 고속 모드(연구 프리뷰)를 사용할 때는 표준 Opus 속도 제한과 별개인 전용 속도 제한이 적용됩니다. 고속 모드 속도 제한을 초과하면 API는 retry-after 헤더와 함께 429 오류를 반환합니다. 고속 모드는 Claude Opus 4.6에서 사용할 수 없습니다. speed: "fast"로 claude-opus-4-6에 보낸 요청은 표준 속도로 실행됩니다. 고속 모드를 참조하세요.
응답에는 고속 모드 속도 제한 상태를 나타내는 anthropic-fast-* 헤더가 포함됩니다. 이러한 헤더에 대한 자세한 내용은 고속 모드 속도 제한을 참조하세요.
Claude Console의 Usage 페이지에서 속도 제한 사용량을 모니터링할 수 있습니다.
토큰 및 요청 차트 외에도 Usage 페이지는 두 개의 별도 속도 제한 차트를 제공합니다. 이러한 차트를 사용하여 성장할 수 있는 여유 공간을 확인하고, 최대 사용 시점을 파악하고, 어떤 속도 제한을 요청해야 하는지 이해하고, 캐싱 비율을 개선하는 방법을 알아보세요. 차트는 주어진 속도 제한(예: 모델별)에 대한 여러 지표를 시각화합니다:
더 높은 속도 제한 또는 더 높은 월간 지출 상한을 요청하려면 Limits 페이지에서 Request rate limit increase를 사용하세요.
지원팀도 제한을 높일 수 있습니다. 긴급한 경우 Anthropic 지원팀에 문의하세요.
Claude Platform on AWS: Request rate limit increase 플로우는 사용할 수 없습니다. Anthropic 계정 담당자 또는 Anthropic 지원팀에 문의하고, 제한을 높여야 하는 모델, 각 모델의 최대 분당 입력 및 출력 토큰 수, 입력 중 캐시되거나 반복되는 컨텍스트의 대략적인 비율을 포함하세요. Claude Platform on AWS의 속도 제한 및 할당량을 참조하세요.
워크스페이스에 대한 자세한 내용은 워크스페이스를 참조하세요.
조직 내 워크스페이스를 잠재적인 과다 사용으로부터 보호하기 위해 워크스페이스별로 사용자 지정 지출 및 속도 제한을 설정할 수 있습니다.
예시: 조직의 제한이 분당 40,000개의 입력 토큰과 분당 8,000개의 출력 토큰인 경우, 한 워크스페이스를 분당 30,000개의 입력 토큰으로 제한할 수 있습니다. 이렇게 하면 다른 워크스페이스를 잠재적인 과다 사용으로부터 보호하고 조직 전체에 자원을 보다 공평하게 분배할 수 있습니다. 남은 미사용 분당 토큰(또는 해당 워크스페이스가 제한을 사용하지 않는 경우 그 이상)은 다른 워크스페이스에서 사용할 수 있습니다.
참고:
현재 조직 및 워크스페이스 속도 제한을 프로그래밍 방식으로 읽으려면 Rate Limits API를 사용하세요.
API 응답에는 적용된 속도 제한, 현재 사용량, 제한이 재설정되는 시점을 보여주는 헤더가 포함됩니다.
다음 헤더가 반환됩니다:
| 헤더 | 설명 |
|---|---|
retry-after | 요청을 재시도할 수 있을 때까지 기다려야 하는 시간(초)입니다. 더 일찍 재시도하면 실패합니다. |
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 사용에 가장 관련성 높은 제약 조건을 파악할 수 있도록 보장합니다.
Was this page helpful?