클로드 페이블 5 속도 제한 설명

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의 조직 티어, 모델 클래스, RPM/ITPM/OTPM 기준으로 잡아야 합니다. 모델 개요가 필요하다면 Claude Fable 5 개요를 먼저 확인하세요.

지금 Apidog를 사용해 보세요

TL;DR

Claude Fable 5는 Anthropic의 표준 티어 기반 속도 제한을 사용합니다.

확인해야 할 값은 세 가지입니다.

• RPM: 분당 요청 수
• ITPM: 분당 입력 토큰 수
• OTPM: 분당 출력 토큰 수

이 제한은 조직 및 모델 클래스별로 적용됩니다. 누적 지출이 증가해 사용량 티어가 올라가면 제한도 상향됩니다. 실제 수치는 항상 Anthropic 콘솔에서 확인하고, 429 응답을 받으면 retry-after 헤더를 기준으로 재시도하세요.

Anthropic 속도 제한 작동 방식

Anthropic은 하나의 전역 API 제한만 적용하지 않습니다. 대신 사용량 티어 시스템을 사용합니다.

개발자가 구분해야 할 개념은 두 가지입니다.

1. 지출 제한: 월별 청구 가능한 금액
2. 속도 제한: API를 얼마나 빠르게 호출할 수 있는지

이 글에서는 속도 제한을 다루지만, 두 값은 모두 조직 티어와 연결됩니다.

제한 유형

Messages API의 속도 제한은 모델 클래스별로 다음 세 가지 차원에서 측정됩니다.

1. RPM

RPM은 분당 시작할 수 있는 API 요청 수입니다.

예를 들어 50 RPM이라면 1분에 50개의 요청을 보낼 수 있다는 의미입니다. 다만 토큰 버킷 방식으로 적용되므로, 짧은 시간에 요청을 몰아서 보내면 평균 RPM이 제한 이하여도 제한에 걸릴 수 있습니다.

2. ITPM

ITPM은 분당 보낼 수 있는 입력 토큰 수입니다.

대부분의 현재 모델에서는 캐시되지 않은 입력 토큰이 ITPM에 포함됩니다. 프롬프트 캐시에서 읽은 토큰은 일반적으로 ITPM에 계산되지 않으므로, 반복되는 시스템 프롬프트나 참조 문서를 캐싱하면 실제 처리량을 높일 수 있습니다.

3. OTPM

OTPM은 분당 모델이 생성할 수 있는 출력 토큰 수입니다.

중요한 점은 max_tokens 값이 미리 OTPM에서 차감되지 않는다는 것입니다. 실제로 생성된 출력 토큰만 계산됩니다. 긴 응답을 생성하는 작업에서는 RPM보다 OTPM이 먼저 병목이 될 가능성이 큽니다.

토큰 버킷 방식 이해하기

Anthropic은 토큰 버킷 알고리즘으로 제한을 적용합니다.

즉, 매분 정각에 전체 할당량이 한 번에 초기화되는 방식이 아닙니다. 버킷은 시간이 지나면서 계속 채워지고, 최대치에 도달하면 더 이상 쌓이지 않습니다.

실무적으로는 다음처럼 동작한다고 보면 됩니다.

• 트래픽을 짧은 시간에 몰아 보내면 제한에 걸리기 쉽습니다.
• 일정한 속도로 요청을 보내면 같은 제한에서도 더 안정적으로 처리됩니다.
• 큐와 워커를 사용해 요청 속도를 평탄화하는 것이 좋습니다.

조직별, 모델 클래스별로 제한이 적용됨

속도 제한을 설계할 때 두 가지를 반드시 고려하세요.

조직 단위 제한

제한은 API 키별이 아니라 조직 수준에서 적용됩니다.

즉, 같은 조직의 여러 API 키가 동일한 제한 풀을 공유합니다. 특정 워크스페이스나 서비스가 전체 제한을 소모하지 않도록 하려면, 워크스페이스별 내부 제한을 별도로 두는 것이 좋습니다.

모델 클래스별 제한

제한은 모델 클래스별로도 분리됩니다.

예를 들어 Fable 5 트래픽과 Opus 트래픽은 각각 별도의 버킷에 대해 측정됩니다. 따라서 한 모델 클래스의 트래픽이 다른 모델 클래스의 제한을 직접 소모하지 않습니다.

티어 상승 방식

Anthropic의 사용량 티어는 누적 크레딧 구매 기준으로 상승합니다. 공개된 구조는 다음과 같습니다. 실제 상태는 반드시 콘솔에서 확인하세요.

• 티어 1: $5 크레딧 구매 시 해제
• 티어 2: 누적 $40
• 티어 3: 누적 $200
• 티어 4: 누적 $400

티어가 올라가면 월별 지출 한도와 API 속도 제한도 증가합니다. 티어 4 이상에서는 영업팀 또는 월별 청구를 통해 더 높은 한도를 사용할 수 있습니다.

Fable 5 비용 구조까지 함께 계산하려면 Claude Fable 5 가격 책정을 참고하세요.

Claude Fable 5에 대한 의미

Fable 5는 별도의 속도 제한 프레임워크를 사용하지 않습니다.

따라서 “내 Fable 5 제한은 얼마인가요?”라는 질문은 다음 질문으로 바꿔야 합니다.

내 조직은 어떤 티어이며, 해당 티어의 Fable 5 모델 클래스 제한은 얼마인가?

Anthropic이 공개한 속도 제한 티어 기준으로 Fable 5 행은 대략 다음과 같습니다. 단, 실제 값은 콘솔이 기준입니다.

티어	RPM	ITPM	OTPM
티어 1	50	100,000	20,000
티어 2	1,000	500,000	100,000
티어 3	2,000	1,500,000	300,000
티어 4	4,000	4,000,000	800,000

이 숫자는 시스템의 형태를 이해하기 위한 기준입니다. Anthropic은 제한 테이블을 업데이트할 수 있고, Priority Tier 또는 엔터프라이즈 계약은 다른 제한을 가질 수 있습니다. 콘솔에 표시된 값이 이 표와 다르다면 콘솔 값을 기준으로 사용하세요.

Fable 5에서 특히 주의할 병목: OTPM

Fable 5는 긴 작업과 많은 출력이 필요한 에이전트형 워크로드에 자주 사용됩니다. 이런 작업에서는 RPM보다 OTPM이 먼저 한계에 도달할 수 있습니다.

예를 들어 여러 개의 긴 생성 작업을 동시에 실행하면 다음 상황이 발생할 수 있습니다.

• 요청 수는 RPM 제한 이하
• 입력 토큰도 ITPM 제한 이하
• 하지만 출력이 길어 OTPM 제한 도달

이를 줄이려면 다음 원칙을 적용하세요.

• max_tokens를 작업에 필요한 수준으로만 설정합니다.
• 긴 응답은 스트리밍으로 받습니다.
• 동시에 실행되는 장기 생성 작업 수를 제한합니다.
• 응답 헤더에서 남은 OTPM을 읽고 큐 속도를 조절합니다.

Fable 5 요청 형식을 처음 연결한다면 Claude Fable 5 API 가이드를 함께 확인하세요.

실제 제한 확인 방법

블로그 글이나 예시 표만 보고 운영 제한을 결정하지 마세요. 실제 값은 다음 두 곳에서 확인해야 합니다.

1. Anthropic 콘솔 확인

Anthropic 콘솔의 제한 페이지에서 조직의 현재 티어와 모델별 속도 제한을 확인할 수 있습니다.

사용량 페이지에서는 다음 지표를 확인할 수 있습니다.

• 입력 토큰 사용량
• 출력 토큰 사용량
• 캐시 히트율
• 시간대별 제한 접근 수준

트래픽을 늘리기 전에는 이 화면에서 “현재 여유가 있는지”를 먼저 확인하세요.

2. API 응답 헤더 확인

Anthropic은 API 응답에 anthropic-ratelimit-* 헤더를 포함합니다.

주요 헤더는 다음과 같습니다.

anthropic-ratelimit-requests-limit
anthropic-ratelimit-requests-remaining

anthropic-ratelimit-input-tokens-limit
anthropic-ratelimit-input-tokens-remaining

anthropic-ratelimit-output-tokens-limit
anthropic-ratelimit-output-tokens-remaining

각 제한에는 *-reset 헤더도 있습니다. 이 값은 RFC 3339 형식이며, 해당 버킷이 완전히 보충되는 시점을 알려줍니다.

클라이언트에서는 각 응답의 *-remaining 값을 읽어 429 오류가 발생하기 전에 자체적으로 속도를 낮추는 것이 좋습니다.

429 오류 처리하기

429 응답은 RPM, ITPM, OTPM 중 하나의 제한에 도달했다는 의미입니다.

이때 응답에는 일반적으로 retry-after 헤더가 포함됩니다. 이 값은 다시 시도하기 전 기다려야 할 시간을 초 단위로 알려줍니다.

retry-after보다 빨리 재시도하면 다시 실패할 가능성이 높습니다. 반드시 이 헤더를 기준으로 백오프하세요.

Python SDK에서 재시도 설정

Anthropic 공식 SDK는 기본적으로 429 및 5xx 응답에 대해 지수 백오프를 수행합니다. 기본 재시도 횟수는 2회입니다.

배치성 작업이나 일시적 제한이 잦은 워크로드에서는 max_retries를 늘릴 수 있습니다.

import anthropic

client = anthropic.Anthropic()  # 환경 변수 ANTHROPIC_API_KEY를 읽습니다.

# 429가 발생할 수 있는 배치 워크로드라면 기본값보다 높게 설정합니다.
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)

429를 직접 처리해야 하는 경우

UI에 “재시도 중” 상태를 보여주거나, 큐 처리 로직과 연동해야 한다면 RateLimitError를 직접 처리할 수 있습니다.

import time
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.")
    time.sleep(wait_seconds)

운영 환경에서는 단순 재시도보다 큐 기반 제어가 더 안정적입니다.

큐로 요청 속도 제어하기

트래픽이 갑자기 증가하는 워크로드라면 요청을 즉시 Anthropic API로 보내지 말고 큐에 넣으세요.

기본 구조는 다음과 같습니다.

1. 요청을 큐에 저장합니다.
2. 워커가 일정 속도로 요청을 처리합니다.
3. 응답 헤더의 anthropic-ratelimit-*-remaining 값을 읽습니다.
4. 남은 제한이 낮으면 워커 처리 속도를 늦춥니다.
5. 429가 발생하면 retry-after만큼 대기 후 재시도합니다.

간단한 의사 코드는 다음과 같습니다.

def should_slow_down(headers):
    output_remaining = int(headers.get(
        "anthropic-ratelimit-output-tokens-remaining",
        "0"
    ))

    return output_remaining < 10_000

속도 제한이 있는 API를 테스트하는 패턴은 Claude 작업에도 그대로 적용할 수 있습니다. 관련 예시는 Apidog로 ChatGPT API 테스트하기를 참고하세요.

제한을 높이거나 사용량을 줄이는 방법

지속적으로 제한에 도달한다면 선택지는 두 가지입니다.

1. 더 높은 제한을 확보합니다.
2. 필요한 토큰 처리량을 줄입니다.

방법 1: 티어 올리기

티어는 누적 크레딧 구매에 따라 상승합니다. 실제 사용량이 꾸준히 증가하면 자동으로 다음 티어에 도달할 수 있습니다.

자동 상승보다 빠르게 한도를 높여야 하거나, 맞춤형/엔터프라이즈 제한이 필요하다면 콘솔의 제한 페이지에서 영업팀에 문의하세요.

Priority Tier 및 월별 청구는 고용량 워크로드를 위한 옵션입니다.

방법 2: 토큰 처리량 줄이기

제한을 높이는 것보다 먼저 토큰 사용량을 줄일 수 있는지 확인하세요.

Batches API 사용

지연 시간에 민감하지 않은 작업에는 Batches API를 사용하세요.

Batches API는 Messages API 요청을 비동기식으로 처리하며, 별도의 속도 제한 풀을 사용합니다. 대량 작업이 실시간 사용자 요청과 같은 제한을 두고 경쟁하지 않게 만들 수 있습니다.

프롬프트 캐싱 사용

반복되는 컨텍스트가 있다면 프롬프트 캐싱을 활성화하세요.

캐싱하기 좋은 대상은 다음과 같습니다.

• 긴 시스템 프롬프트
• 고정 도구 정의
• 반복 참조 문서
• 에이전트 루프에서 매번 포함되는 공통 컨텍스트

캐시된 입력 토큰은 일반적으로 ITPM에 계산되지 않으므로, 같은 티어에서 더 많은 요청을 처리할 수 있습니다.

max_tokens 조정

max_tokens가 높다고 해서 즉시 OTPM을 소모하지는 않습니다. 하지만 너무 넉넉한 값은 응답이 불필요하게 길어지는 원인이 될 수 있습니다.

작업별로 적절한 상한을 정하세요.

# 요약 작업
max_tokens = 1024

# 긴 보고서 생성
max_tokens = 4096

# 대규모 문서 초안 생성
max_tokens = 8192

긴 출력은 스트리밍

긴 응답을 비스트리밍으로 기다리면 요청 시간 초과나 사용자 경험 문제가 발생할 수 있습니다.

긴 생성 작업에서는 스트리밍을 사용하세요. 스트리밍은 응답이 생성되는 동안 결과를 점진적으로 받을 수 있게 해주며, 출력 토큰이 실시간으로 누적되는 워크로드에 적합합니다.

에이전트 스타일 워크로드에서 이러한 전략을 적용하는 방법은 Claude Fable 5 에이전트 설명을 참고하세요.

모델 클래스별 제한 버킷을 비교해야 한다면 Claude Opus 4.8 API 가이드와 Opus 4.8 가격도 함께 확인할 수 있습니다.

Apidog로 Fable 5 사용량 모니터링

실제 제한을 이해하는 가장 좋은 방법은 직접 요청을 보내고 응답 헤더를 확인하는 것입니다.

Apidog를 사용하면 Messages API 요청을 구성하고 전송한 뒤, 전체 응답을 확인할 수 있습니다.

특히 다음 값을 함께 보면 좋습니다.

• anthropic-ratelimit-requests-remaining
• anthropic-ratelimit-input-tokens-remaining
• anthropic-ratelimit-output-tokens-remaining
• usage.input_tokens
• usage.output_tokens
• usage.cache_read_input_tokens

이 값을 요청마다 비교하면 429 오류가 발생하기 전에 현재 워크로드가 어느 제한에 가까워지고 있는지 확인할 수 있습니다.

Apidog에서 확인할 실험 절차

다음 순서로 테스트하면 Fable 5 제한을 더 구체적으로 이해할 수 있습니다.

1. Apidog에서 대표적인 Fable 5 요청을 만듭니다.
2. 요청을 전송합니다.
3. 응답 헤더에서 anthropic-ratelimit-output-tokens-remaining을 확인합니다.
4. 응답 본문의 usage.output_tokens를 확인합니다.
5. 긴 생성이 남은 OTPM을 얼마나 줄이는지 기록합니다.
6. 반복되는 시스템 프롬프트를 캐싱합니다.
7. 같은 요청을 다시 보냅니다.
8. usage.cache_read_input_tokens가 증가하는지 확인합니다.
9. ITPM 소비가 줄어드는지 비교합니다.
10. max_tokens를 변경해 실제 출력 토큰만 OTPM에 반영되는지 확인합니다.

이 과정을 통해 추상적인 티어 표가 실제 애플리케이션의 처리 여유 공간으로 바뀝니다.

직접 테스트하려면 Apidog를 다운로드하고, 요청 속도를 조정하면서 응답 헤더를 확인하세요. 이미 API 설계 및 테스트에 Apidog를 사용 중인 팀이라면 Fable 5 모니터링도 같은 워크스페이스에서 관리할 수 있습니다.