Claude 529 overloaded_error란? 2026년 기준 의미와 해결 방법

Claude 529 Overloaded 에러 뜻: 모델 용량 부족, 내 한도 아님

529 overloaded_error는 Anthropic API가 일시적으로 과부하 상태라는 응답입니다. Claude API 오류 문서는 이 오류가 "모든 사용자의 트래픽이 높을 때" 생길 수 있다고 설명합니다. 요청 형식, API 키, 결제 상태가 잘못됐다는 뜻이 아니고, 내 사용 한도를 넘었다는 뜻도 아닙니다. 한도 초과는 429입니다.

Claude Code 공식 오류 레퍼런스(한국어)는 더 분명하게 적습니다. "529는 사용 한도가 아니며 할당량에 대해 계산되지 않습니다." 그리고 용량은 모델별로 관리되므로, 한 모델이 막혀도 다른 모델은 정상일 수 있습니다.

그래서 2026년 10월 14일 기준으로 해야 할 일은 세 가지로 좁혀집니다.

1. 메시지가 어디서 왔는지 확인합니다. Claude Code 한 줄 오류인지, API 응답인지, 사내 게이트웨이나 Amazon Bedrock 같은 클라우드에서 온 것인지에 따라 확인할 상태 페이지가 다릅니다.
2. 급하면 모델을 바꿉니다. Claude Code에서는 /model로 Opus에서 Sonnet으로 바꾸는 것이 가장 빠른 우회입니다. 자주 겪는다면 fallbackModel로 대체 모델을 미리 지정해 둡니다.
3. 급하지 않으면 기다립니다. Claude Code는 오류를 보여주기 전에 이미 자동 재시도를 마친 상태입니다. 같은 요청을 연달아 다시 보내기보다 status.claude.com에서 해당 모델의 장애 공지가 있는지 보고 몇 분 뒤 다시 시도합니다.

메시지별로 보는 Claude 529: 어디서 났고 다음에 무엇을 할까

같은 529라도 화면에 찍히는 문구는 도구마다 다릅니다. 문구의 끝부분이 어느 층에서 실패했는지를 알려 주므로, 아래 표에서 지금 보이는 문구를 먼저 찾으십시오.

몇 가지는 따로 짚어 둘 만합니다.

API Error: 529 Overloaded. 한 줄 오류. Claude Code는 5xx 응답을 받으면 상태 코드와 API의 오류 메시지를 그대로 보여 주고, 끝에 상태를 확인할 곳을 붙입니다. 2026년 3월에는 API의 오류 메시지 자체에 문서 주소가 들어 있어서 API Error: 529 Overloaded. https://docs.claude.com/en/api/errors 같은 형태로 보였습니다(GitHub #39767, 2026년 3월 27일). 주소가 붙은 형태든 안내 문장이 붙은 형태든 뜻은 같습니다.

check your inference gateway가 붙은 경우. ANTHROPIC_BASE_URL로 LiteLLM 같은 자체 게이트웨이를 거치면, Claude Code는 status.claude.com 대신 그 게이트웨이 주소를 안내합니다. 이때는 Anthropic이 아니라 내 프록시가 먼저 확인 대상입니다. 게이트웨이가 상위에서 받은 529를 그대로 넘겼는지, 게이트웨이 자체가 실패했는지를 그 로그에서 구분합니다.

anthropic stream error (overloaded_error) 문구. 스트리밍 응답은 HTTP 200으로 시작한 뒤에도 중간에 event: error와 overloaded_error를 보낼 수 있습니다. 스트리밍 문서는 이 이벤트가 "스트리밍이 아니었다면 HTTP 529에 해당한다"고 설명합니다. 위 문구는 여러 클라이언트 도구가 이 이벤트를 자기 형식으로 출력한 것으로, 의미는 529와 같습니다.

처음 10분 동안 해야 할 일: 대기, 모델 전환, 보고 순서

529를 처음 봤을 때 아래 순서로 판단하면 불필요한 디버깅을 피할 수 있습니다.

1. 카운트다운이 돌고 있으면 그대로 둡니다. Retrying in Ns · attempt x/10이 보이는 동안 Claude Code는 아직 재시도 중이므로, 중간에 취소하고 다시 보낼 이유가 없습니다.
2. 최종 오류가 뜨면 상태 페이지를 엽니다. status.claude.com에 지금 쓰는 모델 이름이 들어간 "Elevated errors" 공지가 있다면 원인은 확정입니다. 내 쪽에서 고칠 것은 없습니다.
3. 작업을 계속해야 하면 모델을 바꿉니다. Claude Code에서 /model을 실행해 다른 모델을 고릅니다. 공식 문서가 권하는 방법이며, 용량이 모델 단위로 관리되기 때문에 효과가 있습니다.
4. 공지가 없는데 계속 실패하면 경로를 의심합니다. 메시지 끝에 게이트웨이 주소나 클라우드 이름이 있으면 그쪽을 확인합니다. 실제 코드가 529가 아니라 429·500·502라면 아래의 코드별 구분 표로 넘어갑니다.
5. 장애 공지 없이 계속 이어지면 보고합니다. Claude Code에서는 /feedback, API에서는 request_id와 발생 시각, 모델 이름을 모아 지원팀에 전달합니다.

모델 전환이 통하지 않는 경우도 있습니다. 2026년 9월 29일 14:0014:59 UTC(한국 시각 23:0023:59)의 장애처럼 claude.ai, Claude Code, API가 함께 영향을 받은 경우에는 기다리는 것 외에 방법이 없었습니다. 상태 페이지의 공지 제목에 특정 모델 이름이 있는지, "multiple models"나 서비스 전체 이름이 있는지가 둘을 가르는 기준입니다.

Claude Code 529 Overloaded: 자동 재시도 약 2분 40초 뒤 멈춘다

Claude Code는 일시적인 실패를 지수 백오프로 최대 10회 재시도한 뒤에야 오류를 보여 줍니다(오류 레퍼런스). 따라서 최종 오류를 봤다면 "한 번 더 눌러 보기"는 이미 여러 번 해 본 셈입니다.

✻ 529 Overloaded · Retrying in … · attempt x/10 읽는 법

재시도 중에는 스피너에 Retrying in Ns · attempt x/y 카운트다운이 붙습니다. 처음 두 번은 이유가 API error로만 나오고, v2.1.198부터는 세 번째 시도부터 529 Overloaded처럼 구체적인 이유로 바뀝니다. 529일 때는 카운트다운 아래 줄에 확인할 상태 페이지(Anthropic API면 status.claude.com, 다른 구성이면 해당 제공자나 게이트웨이)가 함께 표시됩니다.

Retrying in 0s · attempt 4/10이 재시도가 성공한 뒤에도 화면에 남는 표시 오류는 v2.1.181에서 고쳐졌습니다. 오래된 버전이라면 claude update로 올리는 것이 먼저입니다.

기본값으로 계산한 재시도 시간: 약 160초

공식 기본값은 529 재시도 첫 대기 500ms, 대기 상한 32초, 재시도 10회입니다. 대기가 매번 두 배로 늘어난다고 보고 더하면 다음과 같습니다.

0.5 + 1 + 2 + 4 + 8 + 16 + 32 + 32 + 32 + 32 = 159.5초 ≈ 2분 40초

2026년 7월 v2.1.220 실행 파일을 분석한 GitHub #81330도 같은 구조(대기마다 0~25% 무작위 지연 추가)로 약 2.5분을 계산했습니다. 같은 보고에는 API 키로 Opus·Fable·Mythos급 모델을 쓰는 세션은 529가 3번 나오면 바로 Repeated 529 오류로 멈춘다는 관찰도 있지만, 이는 해당 버전에 대한 사용자 분석일 뿐 공식 설명은 아닙니다.

뜻은 단순합니다. 과부하가 3분 이상 이어지면 그 사이에 보낸 요청은 대부분 오류로 끝납니다. 상태 페이지에 올라오는 장애는 보통 수십 분 단위이므로, 3분 안에 끝나지 않는 529에는 모델 전환이나 대기가 맞습니다.

/model로 모델 바꾸기: 용량은 모델별로 따로 관리된다

Claude Code는 특정 모델이 특히 붐빌 때 Opus is experiencing high load, please use /model to switch to Sonnet처럼 직접 전환을 권합니다. Fable 모델을 쓰고 있었다면 안내에 Fable이 나옵니다. Claude 데스크톱 앱의 Code 탭이나 Cowork에서는 Opus is experiencing high load. Switch to Sonnet.으로 표시되고, 앱의 모델 선택기에서 바꾸면 됩니다.

모델 전환이 효과가 있다는 근거는 실제 장애 기록에 있습니다. 2026년 8~10월 status.claude.com에 올라온 "elevated errors" 공지는 대부분 특정 모델 이름을 달고 있었습니다.

상태 페이지의 공지는 "elevated errors"라고만 쓰고 529를 명시하지 않습니다. 다만 2026년 8월 24일에는 Opus 5 서브에이전트가 API Error: 529 Overloaded로 중단됐다는 사용자 보고(GitHub #89267)가 같은 날 올라왔습니다.

fallbackModel 설정: 529가 반복되면 대체 모델로 자동 전환

매번 /model을 치기 번거롭다면 대체 모델 체인을 지정합니다(모델 설정 문서). 한 세션에만 쓰려면 실행 옵션으로 넘깁니다.

claude --fallback-model sonnet,haiku

계속 쓰려면 settings.json에 배열로 넣습니다. 항목에는 모델 이름이나 별칭을 쓸 수 있습니다.

{
  "fallbackModel": ["sonnet", "haiku"]
}

설정하기 전에 알아 둘 조건이 있습니다.

• 기본 모델이 과부하이거나 사용할 수 없을 때만 전환합니다. 인증·결제·속도 제한(429)·요청 크기 오류에는 작동하지 않습니다.
• 전환은 현재 턴에만 적용되고, 다음 메시지는 다시 기본 모델로 시도합니다.
• 체인은 중복을 뺀 뒤 최대 3개까지만 씁니다.
• 시작할 때 확인 메시지가 없고 /status에도 나오지 않습니다. 전환 알림이 처음 보이는 순간이 설정이 작동한다는 첫 신호입니다.
• 서브에이전트(v2.1.247 이상)와 컨텍스트 압축(v2.1.178 이상)에도 적용됩니다. 압축 때는 컨텍스트 창이 더 작은 모델로는 넘어가지 않습니다.
• 별칭이 가리키는 모델은 제공자마다 다릅니다. Anthropic API에서 sonnet은 Sonnet 5.5지만, Amazon Bedrock과 Google Cloud에서는 Sonnet 4.5입니다.

"Opus가 붐비면 알아서 Sonnet으로 넘어간다"는 설명을 본 적이 있다면, 2026년 10월 기준으로는 체인을 설정했거나 안내를 보고 직접 바꾼 경우에만 해당합니다. Fable·Opus 5.5 등에 있는 "자동 모델 대체"는 보안 분류기가 거절한 요청을 다른 모델로 다시 보내는 기능이라 과부하와 관계가 없습니다.

무인 실행과 CI: 재시도 환경 변수

사람이 지켜보지 않는 작업이라면 재시도를 길게 늘리는 편이 낫습니다. 아래 변수는 오류 레퍼런스의 재시도 조정 항목에 있는 것이며, 몇 주 간격으로 새 변수가 추가되고 있으니 claude --version으로 버전을 먼저 확인하십시오.

예를 들어 첫 대기를 5000ms, 상한을 64000ms로 올리면 같은 10회 재시도가 5 + 10 + 20 + 40 + 64 × 6 = 459초, 약 7분 40초에 걸쳐 퍼집니다. 짧은 혼잡은 이 정도로 넘길 수 있습니다.

CLAUDE_CODE_RETRY_WATCHDOG=1은 지출 한도나 크레딧 소진으로 받은 429에서는 v2.1.239부터 즉시 멈추므로, 돈이 바닥난 상태로 몇 시간씩 재시도하지는 않습니다.

Claude API·SDK에서 529 처리: 재시도는 한 곳에서만

공식 Python·TypeScript SDK는 연결 오류, 408, 409, 429, 500 이상을 기본 2회 자동 재시도합니다(Python SDK 문서). 529도 여기에 포함되며, 재시도를 다 쓰면 InternalServerError(500 이상 공통 예외)로 올라옵니다. SDK에는 529 전용 예외 클래스가 없으므로 status_code가 529인지 직접 확인해야 합니다.

자주 하는 실수는 SDK 재시도를 그대로 둔 채 바깥에 재시도 루프를 하나 더 두는 것입니다. 바깥 루프 5회 × SDK 시도 3회(최초 1회 + 재시도 2회)면 한 번의 호출이 최대 15개 요청이 됩니다. 이미 붐비는 API에 요청을 몇 배로 보내는 꼴이므로, 재시도는 한 곳에서만 합니다. 아래 예시는 SDK 재시도를 끄고, 529일 때만 백오프 후 재시도하며, 같은 모델이 계속 막히면 다음 모델로 넘어갑니다.

import random
import time

import anthropic

client = anthropic.Anthropic(max_retries=0)  # 재시도는 아래 함수 한 곳에서만

MODELS = ["claude-opus-5-5", "claude-sonnet-5-5"]  # 앞에서부터 시도


def create_with_fallback(messages, attempts_per_model=4):
    last_error = None
    for model in MODELS:
        for attempt in range(attempts_per_model):
            try:
                return client.messages.create(
                    model=model,
                    max_tokens=1024,
                    messages=messages,
                )
            except anthropic.RateLimitError:
                raise  # 429는 내 조직의 한도 문제: retry-after와 사용량을 확인
            except anthropic.APIStatusError as e:
                if e.status_code != 529:
                    raise
                last_error = e
                request_id = e.response.headers.get("request-id")
                print(f"529 on {model}, request-id={request_id}")
                time.sleep(min(32, 2 ** attempt) * random.uniform(0.5, 1.0))
    raise last_error


reply = create_with_fallback([{"role": "user", "content": "Hello, Claude"}])
print(reply.content[0].text)

max_retries=0이면 네트워크 연결 오류도 SDK가 재시도하지 않으므로, 연결 오류까지 다뤄야 한다면 anthropic.APIConnectionError도 같은 방식으로 잡으십시오. 반대로 직접 루프를 만들 생각이 없다면 SDK의 max_retries만 3~5로 올리는 것이 가장 간단합니다.

몇 가지 운영 팁입니다.

• request_id를 남깁니다. 모든 응답의 request-id 헤더와 오류 본문의 request_id는 같은 값이고, 지원팀 문의 때 필요합니다.
• 스트리밍은 중간 오류를 따로 처리합니다. 200 응답 뒤에 오는 overloaded_error 이벤트는 HTTP 오류 처리 경로를 타지 않습니다. 이미 받은 부분 출력을 버릴지 이어서 요청할지를 코드에서 정해야 합니다.
• 동시에 몰아서 보내지 않습니다. 여러 작업이 같은 간격으로 함께 재시도하면 회복 직후 다시 몰립니다. 무작위 지연(jitter)을 넣는 이유입니다.
• Priority Tier는 더 이상 살 수 없습니다. 예전에는 과부하를 줄이는 방법으로 Priority Tier가 거론됐지만, 서비스 티어 문서는 2026년 10월 기준 신규 구매가 불가능하다고 밝히고 있습니다. 기존 계약 조직만 계약 종료일까지 쓸 수 있고, Opus 5.5·Sonnet 5.5·Haiku 5.5·Fable 5.1 같은 현행 모델은 지원 대상에서 빠져 있습니다.

529 vs 429 vs 500·504 vs 사용 한도: 막은 주체가 다르다

"지금 Claude를 못 쓴다"는 상태는 여러 종류이고, 누가 막았는지에 따라 할 일이 다릅니다.

헷갈리기 쉬운 지점이 하나 있습니다. 2025년 8월 11일 릴리스 노트에 따르면, 사용량이 갑자기 크게 늘었을 때 예전에는 529가 났던 상황에서 이제는 429 rate_limit_error가 반환됩니다. 그래서 내 트래픽 급증으로 막히면 429, 모두가 붐벼서 막히면 529라고 구분하면 됩니다.

클라우드를 거치면 코드 체계가 또 다릅니다. Amazon Bedrock 문서는 529 overloaded_error와 503 ServiceUnavailable을 모두 용량 부족으로, 429 ThrottlingException을 계정 할당량 초과로 설명하며 리전 간 추론(cross-Region inference)을 권합니다. Google Cloud에서는 용량 부족이 429와 Resource exhausted, please try again later.로 나오며, Claude Code를 쓴다면 CLOUD_ML_REGION=global 설정을 고려할 수 있습니다. 클라우드의 용량은 status.claude.com이 아니라 해당 클라우드의 상태 페이지에 나옵니다.

429와 구독 한도를 자세히 진단하려면 Claude Code 속도 제한 완벽 가이드: 5시간·주간 한도와 429 진단·해결을, 500 오류는 Claude API 500 오류: 무작정 재시도하기 전에 request_id를 남기세요를 참고하십시오.

먼저 상태를 확인하라: status.claude.com과 partial outage 뜻

Claude 접속 장애나 서버 상태를 확인하는 공식 경로는 status.claude.com입니다. 2026년 10월 14일 기준 구성 요소는 claude.ai, Claude Console(platform.claude.com), Claude API(api.anthropic.com), Claude Code, Claude Cowork, Claude for Government 여섯 개입니다.

확인할 때는 두 가지를 봅니다.

• 공지 제목의 모델 이름. "Elevated errors for Claude Opus 5.5"처럼 특정 모델이 적혀 있으면 다른 모델로 바꿔 계속 작업할 수 있습니다. 여러 서비스 이름이 함께 적혀 있으면 기다려야 합니다.
• 영향 시간. 해결 공지에는 보통 "Impact occurred from … UTC"처럼 실제 영향 시간이 적힙니다. 한국 시각은 UTC에 9시간을 더합니다.

알림을 받고 싶다면 상태 페이지의 구독 메뉴에서 이메일, SMS, Slack, Microsoft Teams, 웹훅, RSS·Atom 중 하나를 고릅니다. 모니터링 시스템에 넣으려면 https://status.claude.com/api/v2/summary.json (현재 상태)과 https://status.claude.com/api/v2/incidents.json (최근 장애)을 주기적으로 읽으면 됩니다.

partial outage 뜻: 일부 기능이나 일부 요청만 실패하는 상태

status.claude.com의 구성 요소 옆에 "Partial Outage"가 보이면, 그 구성 요소가 완전히 멈춘 것은 아니지만 일부 기능이나 일부 사용자의 요청이 실패하고 있다는 뜻입니다. 전면 장애(Major Outage)보다 한 단계 가볍고, 응답이 느려지는 성능 저하(Degraded Performance)보다는 무거운 표시로 이해하면 됩니다. 구성 요소는 claude.ai, Claude API처럼 서비스 단위로 나뉘어 있고 모델별 표시는 없습니다. 그래서 partial outage가 보이면 공지 제목에서 어떤 모델이 영향을 받는지 확인해야 모델을 바꿀지 판단할 수 있습니다.

반대로 상태 페이지가 모두 정상(All Systems Operational)이어도 529가 날 수 있습니다. 짧은 혼잡은 공지로 올라오지 않는 경우가 있고, claude.ai의 용량 안내는 아예 상태 페이지에 표시되지 않습니다(아래 절 참고).

claude.ai 채팅의 용량 안내와 "Claude is temporarily overloaded"

claude.ai 채팅에서 보이는 공식 용량 안내 문구는 다음과 같습니다(Claude 고객센터).

Due to unexpected capacity constraints, Claude is unable to respond to your message. Please try again soon.

고객센터는 이것이 장애가 아니라 전체 수요를 조절하는 정상 동작이며, 그래서 상태 페이지에 나타나지 않는다고 설명합니다. 몇 분 뒤 다시 보내면 됩니다. 채팅이 안 되는데 상태 페이지가 녹색인 이유가 이것입니다.

Claude is temporarily overloaded. Try again in a moment, or check status.claude.com for updates.라는 문구를 봤다는 경우도 있습니다. 이 문구는 Claude 고객센터와 Claude Code 문서에 나오지 않아, 어느 앱 화면에서 쓰이는지 공개된 설명이 없습니다. 다만 뜻은 위 용량 안내와 같으므로 대처도 같습니다.

사용 한도 소진은 문구가 완전히 다릅니다. 5-hour limit reached - resets [time]이나 You've reached your weekly limit. It resets [day] at [time]이 보이면 용량 문제가 아니라 요금제 한도이므로, 다시 보내도 초기화 시각 전에는 풀리지 않습니다. 주간 한도가 어떻게 바뀌어 왔는지는 Claude Code 주간 한도, 9월 14일에 어떻게 바뀌나에 정리돼 있습니다.

앞으로 529를 줄이려면: 모델 분산과 재시도 설계

Anthropic 쪽 용량 부족을 없앨 수는 없지만, 내 작업이 받는 피해는 줄일 수 있습니다.

• 대체 모델을 미리 정해 둡니다. Claude Code는 fallbackModel, API는 위 예시처럼 모델 목록을 둡니다. 장애가 대부분 모델 단위로 오기 때문에 가장 효과가 큽니다. 현행 Opus의 비용과 이용 경로는 Claude Opus 5.5 이용 경로·실제 비용·Opus 5 이전 점검에 있습니다.
• 재시도는 한 층에서만, 무작위 지연을 섞어서 합니다. SDK와 내 코드, 게이트웨이가 모두 재시도하면 요청이 곱절로 늘어납니다.
• 트래픽을 서서히 올립니다. 공식 오류 문서는 사용량을 급격히 늘리면 가속 제한에 걸릴 수 있으니 점진적으로 늘리라고 권합니다.
• 기다려도 되는 작업은 배치로 돌립니다. 서비스 티어 문서는 Batch를 기다릴 수 있는 비동기 작업용으로 안내합니다.
• 무인 작업은 끝까지 버티게 합니다. CI와 야간 작업에는 CLAUDE_CODE_RETRY_WATCHDOG=1과 최대 대기 시간을 함께 설정합니다.
• 기록을 남깁니다. 시각, 모델, request_id를 남겨 두면 장애 공지와 맞춰 보기 쉽고 문의할 때도 바로 쓸 수 있습니다.

Claude 529 에러 FAQ: 지속 시간, 한도, 요금

Claude 529 overloaded_error는 내 잘못인가요?

아닙니다. 529는 API 전체 트래픽이 많아 해당 모델의 용량이 부족하다는 신호이고, 프롬프트나 키, 결제 상태 때문에 나지 않습니다. 다만 메시지 끝에 게이트웨이 주소가 있다면 내 프록시 쪽 문제일 수 있고, 재시도를 여러 층에서 겹쳐 두면 혼잡을 더 키울 수 있습니다.

Claude 529 에러는 보통 얼마나 지속되나요?

정해진 시간은 없습니다. 2026년 8~10월 상태 페이지에 올라온 모델별 장애는 짧게는 약 15분(9월 2일 Sonnet 5), 길게는 약 2시간 46분(8월 24일 여러 모델) 이어졌습니다. Claude Code의 기본 자동 재시도는 약 2분 40초에서 끝나므로, 그보다 긴 혼잡에는 모델 전환이나 대기가 필요합니다.

529가 뜨면 Claude Code 사용 한도나 할당량이 줄어드나요?

Claude Code 공식 문서는 529가 사용 한도가 아니며 할당량에 대해 계산되지 않는다고 밝힙니다. claude.ai 채팅에서 용량 안내를 받은 경우에 대해서는 같은 내용의 공식 설명이 없습니다.

529 오류에도 API 요금이 나가나요?

529와 과금의 관계는 공식 문서에 적혀 있지 않습니다. 요청이 바로 거절됐다면 생성된 출력이 없지만, 스트리밍 도중 과부하로 끊긴 경우에는 그 전까지 생성된 토큰이 있을 수 있습니다. 확실히 하려면 Claude Console의 사용량 화면에서 해당 시각과 request_id를 확인하십시오.

Max나 Pro 요금제를 쓰면 529가 덜 뜨나요?

요금제에 따라 과부하 시 우선권을 준다는 공식 설명은 없습니다. Max 구독자도 529를 겪은 사례가 GitHub에 여러 건 보고돼 있습니다.

529와 429는 같은 오류인가요?

다릅니다. 529는 모두가 붐벼서 Anthropic 쪽이 막은 것이고, 429는 내 조직의 속도·지출 한도에 걸린 것입니다. 429라면 retry-after 헤더를 따르고 요청량을 줄여야 합니다. Claude Code의 대체 모델 설정도 429에는 작동하지 않습니다.