핵심부터 보기
exceeded retry limit, last status: 429 Too Many Requests만으로 Codex 구독 한도를 모두 소진했다고 판단할 수는 없습니다. 먼저 계정과 제공업체를 확인하고 실제 원인에 해당하는 오류를 읽으세요. 일시적인 요청 제한은 기다린 뒤 풀릴 수 있지만, API 잔액이나 지출 제한에는 해당 계정에서의 조치가 필요합니다. 새 채팅이나 로컬 타이머가 모든 429 오류를 해결하지는 않습니다.
“exceeded retry limit”는 무슨 뜻인가요?
이 메시지는 클라이언트가 재시도를 중단했고 마지막 HTTP 응답이 429였다는 두 가지 단서로 읽을 수 있습니다. 이는 주어진 문구에 대한 진단적 해석이며, 모든 클라이언트의 재시도 횟수에 대한 공식 보장은 아닙니다. App Server 프로토콜은 시도 실패 오류와 상위 서비스의 HTTP 상태 정보를 구분합니다.
앞서 표시된 상세 오류가 있다면 함께 저장하세요. HTTP 상태만으로는 요청 제한과 API 할당량 또는 결제 제한을 구분할 수 없습니다. 같은 작업을 계속 다시 시작하면 원인은 해결되지 않은 채 요청만 늘어날 수 있습니다.
1. 요청을 거부한 서비스 확인하기
클라이언트에서 계정과 워크스페이스를 확인하세요. CLI에서는 codex login status를 사용할 수 있습니다. Codex 인증 문서는 ChatGPT 로그인과 API 키 접근을 구분합니다.
- ChatGPT 로그인: 같은 계정의 Codex 사용량 대시보드를 확인하세요. 사용량 구간이 소진됐다면 Codex 한도 도달 안내를 따르세요. API 결제 잔액은 구독 한도와 다릅니다.
- OpenAI API 키: 반환된 오류와 해당 API 조직·프로젝트의 사용량 및 결제를 확인하세요. ChatGPT 초기화 시간으로 API 제한을 진단하지 마세요.
- 사용자 지정 제공업체 또는 게이트웨이: 실패한 요청이 실제로 어느 제공업체에 도달했는지 확인하세요. 속도 제한과 결제 방식이 다를 수 있습니다. OpenAI API 오류 코드는 해당 서비스가 그 코드를 반환할 때만 적용할 수 있습니다. 해당 업체의 문서와 지원 채널을 확인하세요.
2. 일시적인 요청 제한과 할당량 소진 구분하기
확인할 수 있다면 error.code, error.type과 메시지를 함께 살펴보세요. 필드가 없다는 이유로 특정 원인을 추정하지 마세요. API 오류 참조는 다음 경우를 구분합니다.
- 요청 속도 제한: 응답이 속도 제한을 나타내며
slow_down이 포함될 수 있습니다. 동시 작업과 순간적으로 몰리는 요청을 줄인 뒤 다시 시도하세요. - 크레딧 잔액:
credit_balance_exhausted는 API 크레딧에 관한 오류입니다. 계정 소유자와 결제를 확인하세요. Codex 구독 한도가 초기화되기를 기다려도 이 잔액은 충전되지 않습니다. - 지출 또는 사용량 제한:
organization_spend_limit_exceeded,project_spend_limit_exceeded,organization_usage_limit_exceeded는 각각 다른 제한을 가리킵니다. 추가 지출을 승인하기 전에 관리자와 적용 기간 및 계정 설정을 확인하세요. - 포괄적인 할당량 유형:
insufficient_quota는error.code보다 덜 구체적일 수 있습니다. 일시적인 요청 속도 문제로 취급하지 말고 상세 메시지를 읽으세요.
이는 OpenAI API의 예시이며 Codex 화면에서 모든 필드가 제공된다는 뜻은 아닙니다. 화면에 429만 보인다면 계정 정보나 더 자세한 오류로 확인될 때까지 원인을 미확정 상태로 두세요.
3. 기다리는 것이 도움이 될 때만 재시도하기
일시적인 API 요청 제한에는 Retry-After가 있으면 이를 따르세요. 없다면 OpenAI가 권장하는 지수 백오프와 지터를 적용합니다. 대기 시간을 점차 늘리고 무작위 지연을 더하는 방식입니다. 직접 제어하는 재시도 반복에는 횟수 제한과 총시간 제한이 모두 있어야 합니다. 필요한 대기 시간이 그 범위를 넘으면 서버가 요구한 시간을 줄이지 말고 작업을 나중으로 미루세요.
대화형 Codex 작업에서는 반복 제출을 멈추고 동시 작업을 줄인 뒤, 표시된 대기 시간이 지난 후 작은 후속 작업을 한 번 시도하세요. 클라이언트의 자동 재시도 위에 빠른 수동 반복 요청을 더하지 마세요. 크레딧이나 지출 오류는 백오프로 해결되지 않으며, 모든 경우에 통하는 “5분 기다리기”도 없습니다.
중단된 작업을 계속하기 전에 이미 바뀐 파일, 명령 결과와 완료된 외부 작업을 살펴보세요. 상태가 확인된 단계부터 이어가야 재시도로 같은 작업을 중복 실행하는 일을 피할 수 있습니다.
401, 403, 500, 503 및 스트림 중단
실제 메시지에 따라 다음 확인 항목을 정하세요. 이 오류들이 모두 사용량 초기화를 기다려야 한다는 뜻은 아닙니다. 오류 참조와 Codex 문제 해결을 확인하세요.
- 401: 인증 방식, 선택한 계정과 인증 정보의 유효성을 확인하세요. 지원 게시물에 키를 붙여 넣지 마세요.
- 403: 명시된 접근 권한, 정책 또는 지역 제한을 확인하세요. 요청을 반복한다고 권한이 생기지는 않습니다.
- 500 또는 503: 서버 오류나 일시적 과부하에는 대기 후 제한된 횟수의 재시도가 적절할 수 있습니다. 계속되면 제공업체의 서비스 상태 정보를 확인하고 오류를 보고하세요.
- 스트림 중단 또는 시간 초과: 클라이언트가 완전한 결과를 받기 전에 연결이 끝난 상태입니다. 이 문구만으로 할당량 문제라고 판단하거나 아무 작업도 완료되지 않았다고 볼 수는 없습니다. 원래 상태 코드, 클라이언트 로그와 네트워크 경로를 살펴보고 작업 진행 상황을 확인한 뒤 계속하세요.
오류가 계속될 때 기록할 정보
발생 시각과 시간대, 클라이언트와 버전, 모델, 로그인 방식, 제공업체, 민감 정보를 제거한 메시지, HTTP 상태, 제공된 경우 요청 ID를 보관하세요. 작은 요청 하나도 실패하는지, 다른 클라이언트는 작동하는지, 계정에서 무엇을 확인했는지도 기록하세요. 제공업체의 지원 채널에 로그를 공유하기 전에 API 키, 인증 헤더, 쿠키와 비공개 작업 내용을 제거하세요.
확인 결과 구독 사용량 구간이 소진된 것이 원인이라면 Codex 초기화 시간 안내를 따르세요. 개인 타이머는 화면에 표시된 복구 시간을 기억하는 데 도움을 줄 뿐, API 요청 제한을 해제하거나 접근 복구를 확인하지 않습니다.