Anthropic의 최신 모델을 기반으로 구축 중이며 Claude Fable 5의 속도 제한에 대해 궁금해하신다면, 솔직한 답변을 먼저 드립니다. Anthropic은 출시 시점에 Fable-5 전용의 별도 속도 제한 시스템을 제공하지 않았습니다. Fable 5(모델 ID claude-fable-5, 2026년 6월 9일 출시, 입력 토큰 100만 개당 $10, 출력 토큰 100만 개당 $50)는 표준 Messages API를 사용하며, 조직의 표준 티어 기반 API 속도 제한을 따릅니다. 이러한 제한은 계정의 사용량 및 지출 내역에 따라 달라지며, 조직 및 모델 클래스별로 적용되고, 정확한 수치는 사용 중인 티어에 따라 달라집니다. 이 프레임워크가 중요한 이유는 Fable 5 에이전트의 용량을 계획하고 있다면, 출시 발표에 인쇄된 마법의 숫자가 아니라 Anthropic의 티어 시스템을 중심으로 계획해야 하기 때문입니다. 모델 자체에 대해 처음이시라면 Claude Fable 5 개요를 함께 읽어보시면 좋습니다.
TL;DR
Claude Fable 5는 Anthropic의 표준 티어 기반 속도 제한(분당 요청 수(RPM), 분당 입력 토큰 수(ITPM), 분당 출력 토큰 수(OTPM))을 사용하며, 이는 조직 및 모델 클래스별로 적용됩니다. 누적 지출이 증가하여 사용량 티어(1~4단계)가 올라가면 제한도 상향 조정됩니다. Anthropic 콘솔에서 실제 수치를 항상 확인하고, 429 응답은 retry-after 헤더를 읽어 처리하세요.
Anthropic 속도 제한 작동 방식
Anthropic은 단일의 전역 "API 제한"을 설정하지 않습니다. 대신 사용량 티어 시스템을 운영하며, 이 티어가 사용자가 얻을 수 있는 처리량(throughput)을 결정합니다. 여기에는 두 가지 관련 개념이 있습니다: 지출 제한(월별 청구될 수 있는 금액)과 속도 제한(API를 얼마나 빨리 호출할 수 있는지)입니다. 이 글은 후자에 대한 것이지만, 두 가지는 연결되어 있습니다. 왜냐하면 사용자의 티어가 두 가지 모두를 진행시키기 때문입니다.
제한 유형
Messages API의 경우, 속도 제한은 세 가지 차원으로 측정되며, 각각 분당 및 모델 클래스별로 적용됩니다:
- 분당 요청 수(RPM). 매분 시작할 수 있는 개별 API 호출의 수입니다.
- 분당 입력 토큰 수(ITPM). 매분 보낼 수 있는 입력 토큰의 수입니다. 대부분의 현재 모델에서는 캐시되지 않은 입력 토큰만 여기에 포함됩니다. 프롬프트 캐시에서 읽은 토큰은 ITPM에 계산되지 않으므로, 캐싱이 실제 처리량을 원시 숫자보다 훨씬 높게 만들 수 있습니다.
- 분당 출력 토큰 수(OTPM). 매분 모델이 사용자에게 생성할 수 있는 토큰의 수입니다. 이는 토큰이 스트리밍될 때 실시간으로 평가되며,
max_tokens상한선이 미리 차감되지 않습니다. 높은max_tokens를 설정하는 것만으로는 OTPM을 소모하지 않으며, 실제로 생성된 토큰만 계산됩니다.
Anthropic은 토큰 버킷 알고리즘으로 이를 적용합니다. 매분마다 전체 할당량을 재설정하는 대신, 용량은 최대치까지 계속 채워집니다. 실제 결과는 "50 RPM"과 같은 제한이 초당 약 1개의 요청처럼 작동할 수 있다는 것입니다. 따라서 짧은 시간 내에 집중적으로 호출하면 분당 평균이 괜찮아 보여도 제한에 걸릴 수 있습니다. 들쭉날쭉한 트래픽보다 부드럽고 꾸준한 트래픽이 동일한 숫자에서 더 많은 이점을 얻습니다.
조직별, 모델 클래스별
숫자가 사용자에게 어떻게 적용되는지 결정하는 두 가지 세부 사항이 더 있습니다. 첫째, 제한은 API 키별이 아니라 조직 수준에서 설정되므로, 조직 내의 모든 키는 동일한 풀에서 사용됩니다(한 워크스페이스를 다른 워크스페이스로부터 보호하려면 더 작은 워크스페이스별 제한을 설정할 수 있습니다). 둘째, 제한은 모델 클래스별로 적용됩니다. 이는 Fable 5 트래픽과 Opus 트래픽이 각각 별도의 버킷에 대해 측정된다는 것을 의미합니다. 한 모델 클래스가 다른 모델 클래스를 방해하지 않고 동시에 해당 제한까지 실행할 수 있습니다.
티어 상승 방식
누적 크레딧 구매가 임계값을 넘으면 티어가 자동으로 상승합니다. Anthropic이 공개한 티어(콘솔에서 본인의 상태를 확인하세요)에 따르면 구조는 다음과 같습니다: 티어 1은 $5 크레딧 구매 시 해제되고, 티어 2는 누적 $40, 티어 3은 누적 $200, 티어 4는 누적 $400에 해제되며, 각 단계에서 월별 지출 한도가 증가합니다. 임계값을 넘는 순간 티어가 상승하며, 별도의 티켓을 제출할 필요가 없습니다. 티어 4 이상에서는 더 높은 한도가 영업 또는 월별 청구를 통해 제공됩니다.
이러한 구매가 특정 모델의 비용으로 어떻게 전환되는지 더 자세히 알아보려면 Claude Fable 5 가격 책정 분석이 이 섹션과 잘 맞습니다.
Claude Fable 5에 대한 특정 의미
사람들이 가장 명확히 알고 싶어 하는 부분입니다. Fable 5는 특별하거나 모델별로 다른 제한 프레임워크를 사용하지 않습니다. Fable 5는 자체 모델 클래스로 표준 티어 테이블에 포함되므로, "내 Fable 5 제한은 무엇인가요?"라는 질문은 "내 조직은 어떤 티어에 있으며, 해당 티어에 대한 Fable 5 열에는 무엇이라고 나와 있나요?"로 해석됩니다.
Anthropic이 공개한 속도 제한 티어(다시 한번, 맞춤형 및 엔터프라이즈 계약은 다를 수 있으므로 콘솔에서 본인의 티어를 확인하세요)에 따르면 Fable 5 행은 대략 다음과 같습니다:
- 티어 1: 50 RPM, 100,000 ITPM, 20,000 OTPM.
- 티어 2: 1,000 RPM, 500,000 ITPM, 100,000 OTPM.
- 티어 3: 2,000 RPM, 1,500,000 ITPM, 300,000 OTPM.
- 티어 4: 4,000 RPM, 4,000,000 ITPM, 800,000 OTPM.
이것들은 시스템의 형태를 나타내는 것이지 계약을 의미하는 것은 아닙니다. Anthropic은 테이블을 업데이트하며, Priority Tier 및 엔터프라이즈 계약은 상황을 변경할 수 있고, 콘솔이 진실의 원천입니다. 여기의 숫자가 계정 정보와 일치하지 않는 경우, 계정 정보를 믿으십시오.
Fable 5에서 가장 크게 영향을 미치는 부분은 OTPM입니다. Fable 5는 수백만 개의 토큰을 사용하는 장기적인 작업을 위해 구축되었으며, 에이전트가 큰 작업을 처리하고 그 과정에서 많은 출력을 생성하는 종류의 작업에 적합합니다. 긴 생성은 시작할 때 OTPM을 한꺼번에 많이 소모하지 않고, 스트리밍되면서 출력 예산을 꾸준히 사용합니다. 따라서 하나의 야심찬 Fable 5 작업은 상당한 기간 동안 OTPM 상한선 근처에 머물 수 있으며, 이러한 작업을 여러 개 동시에 실행하면 RPM이 아닌 OTPM이 일반적으로 먼저 도달하는 제한이 됩니다. 여기에서 두 가지 습관이 파생됩니다: 폭주하는 생성이 과도하게 늘어나지 않도록 max_tokens를 적절하게 설정하고, 거대한 비스트림 응답을 기다리면서 연결을 계속 유지하지 않도록 긴 출력을 스트리밍하는 것입니다(이는 요청 시간 초과를 피하는 데도 도움이 됩니다). 모델을 처음 연결하는 경우 Claude Fable 5 API 가이드에서 이러한 제한이 적용되는 요청 형식을 안내합니다.
제한 읽기 및 확인
이 블로그 게시물을 포함하여 블로그 게시물에서 제한을 추측하지 마십시오. 실제 숫자를 확인할 수 있는 두 가지 신뢰할 수 있는 방법이 있습니다.
첫 번째는 Anthropic 콘솔입니다. 설정 아래의 '제한' 페이지는 조직의 현재 티어와 적용 중인 모델별 속도 제한을 보여주며, '사용량' 페이지는 캐시 히트율을 포함하여 시간 경과에 따른 실제 입력 토큰 및 출력 토큰 비율을 상한선과 비교하여 차트로 보여줍니다. 이러한 차트는 트래픽을 확장하기 전에 "여유가 있나, 아니면 한계에 도달하고 있나?"라는 질문에 가장 빠르게 답할 수 있는 방법입니다.
두 번째는 모든 API 호출의 응답 헤더입니다. Anthropic은 현재 상태를 정확히 알려주는 anthropic-ratelimit-* 헤더 세트를 반환합니다:
- RPM에 대한
anthropic-ratelimit-requests-limit및anthropic-ratelimit-requests-remaining. - ITPM에 대한
anthropic-ratelimit-input-tokens-limit및anthropic-ratelimit-input-tokens-remaining. - OTPM에 대한
anthropic-ratelimit-output-tokens-limit및anthropic-ratelimit-output-tokens-remaining. - 각각에 대한 일치하는
*-reset헤더(RFC 3339 형식)는 해당 버킷이 완전히 보충되는 시기를 알려줍니다.
남은 토큰 헤더는 가장 가까운 천 단위로 반올림되며, 결합된 토큰 헤더는 현재 가장 제한적인 제한(예: 설정한 경우 워크스페이스 수준 상한)을 보고합니다. 각 응답에서 *-remaining을 읽으면 클라이언트가 429 오류를 받기 전에 자체적으로 조절할 수 있으며, 이는 우아한 역압(backpressure)과 오류 스트림의 차이입니다.
429 오류를 우아하게 처리하기
429 응답은 제한 중 하나에 도달했음을 의미합니다. 본문은 어떤 제한에 도달했는지 알려주며, 결정적으로 응답에는 다시 시도하기 전에 기다려야 할 시간(초)을 나타내는 retry-after 헤더가 포함되어 있습니다. retry-after에 명시된 시간보다 일찍 다시 시도하면 또 다시 실패할 것이므로, 이를 따르십시오.
다행히도 공식 SDK는 이미 올바르게 작동합니다. Anthropic SDK는 지수 백오프(기본적으로 두 번 재시도)를 사용하여 429 및 5xx 응답을 자동으로 재시도하며, 각 시도에 대한 시간을 맞추기 위해 retry-after를 읽습니다. 대부분의 애플리케이션에서는 이 내장된 동작으로 충분하며, SDK가 제공하지 않는 것이 필요하지 않은 한 재시도 루프를 직접 만들 필요는 없습니다. 다음은 Fable 5를 사용한 기본 호출입니다:
import anthropic
client = anthropic.Anthropic() # 환경에서 ANTHROPIC_API_KEY를 읽어옵니다.
# 429 발생 가능성이 있는 배치 워크로드의 경우 max_retries를 기본값인 2보다 높게 설정합니다.
resilient = client.with_options(max_retries=5)
message = resilient.messages.create(
model="claude-fable-5",
max_tokens=4096,
messages=[
{"role": "user", "content": "6월 변경 로그에 대한 릴리스 요약을 작성해 주세요."}
],
)
print(message.content[0].text)
예를 들어, 사용자 UI에 "현재 바쁩니다. 재시도 중입니다."와 같은 상태를 표시해야 하는 명시적인 제어가 필요한 경우, 특정 예외를 catch하고 헤더를 직접 읽을 수 있습니다:
import anthropic
client = anthropic.Anthropic()
try:
message = client.messages.create(
model="claude-fable-5",
max_tokens=4096,
messages=[{"role": "user", "content": "이 사고 보고서를 요약해 주세요."}],
)
except anthropic.RateLimitError as exc:
wait_seconds = int(exc.response.headers.get("retry-after", "60"))
print(f"Rate limited. Backing off for {wait_seconds}s before retry.")
재시도를 넘어, 지속적인 압력에 대한 견고한 해결책은 큐를 사용하는 것입니다. 트래픽이 폭주한다면, 요청을 큐에 넣고 anthropic-ratelimit-*-remaining 헤더를 사용하여 티어가 흡수할 수 있는 속도로 큐를 비워내세요. 이는 429 오류의 연속을 부드럽고 약간 느린 파이프라인으로 전환하며, 이는 거의 항상 실제로 원하는 것입니다. 동일한 스로틀 및 큐 규율은 속도 제한이 있는 API를 테스트할 때 나타나며, Apidog로 ChatGPT API 테스트하기의 패턴은 Claude 작업에도 직접 적용됩니다.
제한 상향 조정 및 부담 감소
지속적으로 제한에 부딪힐 때에는 두 가지 방법이 있습니다: 여유 공간을 더 확보하거나, 필요한 여유 공간을 줄이는 것입니다.
더 많은 여유 공간을 확보하려면 티어를 올리세요. 티어는 누적 크레딧 구매에 따라 이동하므로, 꾸준한 실제 사용량은 자동으로 티어 상승을 유도하며, 각 단계는 RPM, ITPM, OTPM을 의미 있게 높여줍니다. 자동 일정보다 빨리 티어를 올리거나 맞춤형 또는 엔터프라이즈 제한이 필요한 경우, 콘솔의 '제한' 페이지를 통해 영업팀에 문의하세요. Priority Tier 및 월별 청구는 전용 고용량 워크로드를 위해 존재합니다.
필요한 여유 공간을 줄이려면 토큰 처리량 자체를 공략하세요:
- 지연 시간에 민감하지 않은 작업에는 Batches API를 사용하세요. 이는 Messages API 요청을 비동기식으로 표준 비용의 약 50%로 처리하며, 자체적인 별도의 속도 제한 풀을 가지고 있어 대량 작업이 실시간 상호작용 트래픽과 경쟁하는 것을 방지합니다.
- 반복되는 컨텍스트에 대해 프롬프트 캐싱을 활성화하세요. 캐시된 입력 토큰은 일반적으로 ITPM에 계산되지 않으므로, Fable 5 배치 전반에 걸쳐 대규모 시스템 프롬프트, 도구 세트 또는 참조 문서를 캐싱하면 티어에 영향을 주지 않고도 효과적인 입력 처리량을 늘릴 수 있습니다. '사용량' 페이지에서 캐시 히트율을 확인하여 캐싱이 제대로 작동하는지 확인하세요.
max_tokens를 적절하게 설정하세요. 높은 상한선에 대한 OTPM 페널티는 없지만, 관대한max_tokens는 단일 응답이 길어지고 OTPM을 더 오래 소모하게 만듭니다. 작업에 실제로 필요한 만큼 설정하세요.- 긴 출력을 스트리밍하세요. 스트리밍은 대규모 생성 시 요청 시간 초과로부터 사용자를 보호하고 출력이 실시간으로 축적되는 것을 볼 수 있게 해주며, 이는 OTPM 헤더를 읽는 것과 자연스럽게 연결됩니다.
이러한 기술들은 복합적으로 작용합니다. 캐싱되고, 배치 처리되며, 잘 스트리밍되는 Fable 5 파이프라인은 단순한 파이프라인보다 동일한 티어 내에서 훨씬 더 많은 작업을 수행할 수 있습니다. 특히 에이전트 스타일 워크로드의 경우, Claude Fable 5 에이전트 상세 설명은 이러한 레버들이 장기 실행 루프에 어떻게 적용되는지 보여줍니다. 그리고 처리량에 민감한 작업을 위해 모델 클래스를 비교한다면, Claude Opus 4.8 API 가이드 및 Opus 4.8 가격 안내는 각 모델 클래스마다 별도의 제한 버킷이 있으므로 유용한 참고 자료가 될 수 있습니다.
Apidog로 Fable 5 사용량 모니터링
실제 제한을 이해하는 가장 확실한 방법은 실시간 요청에서 이를 확인하는 것이며, API 클라이언트는 이를 구체적으로 보여줍니다. Apidog를 사용하면 Messages API에 대한 Fable 5 요청을 구축하고 전송한 다음, anthropic-ratelimit-* 헤더와 해당 호출에 대한 입력, 출력 및 캐시된 토큰 수를 보고하는 usage 객체를 포함하여 전체 응답을 검사할 수 있습니다. 요청마다 이러한 숫자를 나란히 보면 429 오류를 기다릴 필요 없이 ITPM 및 OTPM에 얼마나 근접하게 실행되고 있는지, 캐싱이 실제로 얼마나 절약해 주는지 정확히 알 수 있습니다.
구축하는 동안 실용적인 반복 작업: Apidog에서 대표적인 Fable 5 프롬프트를 전송하고, 응답에서 anthropic-ratelimit-output-tokens-remaining 및 usage.output_tokens 값을 읽고, 긴 생성이 남은 수를 얼마나 빨리 감소시키는지 확인하세요. 그런 다음 캐시된 시스템 프롬프트를 추가하고 다시 전송한 다음, ITPM 소비는 거의 움직이지 않으면서 usage.cache_read_input_tokens가 증가하는 것을 확인하세요. 이 두 요청 비교를 통해 추상적인 티어 테이블이 본인의 여유 공간에 대한 실제 감각으로 바뀝니다. 요청을 저장하고 max_tokens를 변경하여 OTPM 소비가 상한선이 아닌 실제 출력을 어떻게 추적하는지 확인할 수도 있습니다. 이는 높은 max_tokens가 안전하다는 것을 스스로에게 납득시키는 가장 빠른 방법입니다. 본인의 키로 이 실험을 실행하고 싶다면 Apidog를 다운로드하고, 요청 속도를 조정할 때 응답 헤더를 계속 주시하세요. API 설계 및 테스트를 위해 이미 Apidog를 표준으로 사용하는 팀은 Fable 5 모니터링을 다른 모든 작업에 사용하는 동일한 워크스페이스에 통합할 수 있습니다.