Codex 429 exceeded retry limit 해결: 원인 구분과 복구 기준

Codex에 exceeded retry limit, last status: 429 Too Many Requests가 표시되면 확정할 수 있는 사실은 두 가지뿐입니다. 마지막 요청이 HTTP 429로 거절됐고, Codex가 정해진 재시도 횟수를 소진해 멈췄다는 것입니다. 이 문구만으로는 ChatGPT 사용량 소진, OpenAI API의 속도 또는 할당량 제한, 외부 공급자 제한, 일시적인 장애 가운데 무엇이 원인인지 알 수 없습니다.

복구는 반복 실행을 멈추고 현재 Codex가 어떤 계정과 공급자를 통해 요청하는지 확인하는 데서 시작합니다. ChatGPT 계정으로 로그인했다면 계정 사용량을, OpenAI API 키를 쓴다면 응답 코드와 조직·프로젝트 제한을 확인해야 합니다. 별도 게이트웨이나 모델 공급자를 설정했다면 그 공급자의 응답과 대시보드가 판단 기준입니다.

먼저 할 일: 실패를 늘리지 말고 증거를 남기기

같은 작업을 짧은 간격으로 계속 실행하면 진단이 쉬워지지 않습니다. OpenAI API에서는 실패한 요청도 분당 한도에 포함될 수 있으므로, 무제한 재시도는 회복을 늦출 수 있습니다. OpenAI의 한국어 도움말은 API 속도 제한에 지수 백오프를 적용하고 요청 빈도를 낮추라고 안내합니다. 이 안내는 API 조직의 속도 제한에 관한 것이며, ChatGPT 계정 사용량이나 외부 공급자의 오류를 직접 설명하지는 않습니다.

• 근거: OpenAI의 API 429 해결 안내

재시도 전에 다음 정보를 기록해 두면 원인을 훨씬 빨리 좁힐 수 있습니다.

• 발생 시각과 시간대
• 사용 환경: Codex CLI, IDE 확장 또는 클라우드 작업
• 인증 방식: ChatGPT 로그인, OpenAI API 키 또는 외부 공급자 자격 증명
• 선택한 모델과 공급자
• HTTP 상태, 응답 본문의 구체적인 오류 코드와 메시지
• Retry-After 같은 응답 헤더
• 민감정보를 제거한 request ID
• 작은 작업도 모두 실패하는지, 특정 작업이나 모델에서만 실패하는지

API 키, 액세스 토큰, 전체 설정 파일, 조직·프로젝트 식별자처럼 계정 접근에 쓰일 수 있는 값은 로그나 문의 글에 그대로 넣지 마세요.

어느 경로의 429인지 먼저 구분하기

429를 해결하는 첫 단계는 얼마나 기다릴지 정하는 것이 아니라 누가 요청을 거절했는지 확인하는 것입니다.

환경 변수 이름만 보고 단정하지 말고, 실제 실행에 적용된 인증과 공급자 설정을 확인해야 합니다. IDE와 터미널이 서로 다른 계정이나 설정을 사용할 수도 있습니다. 한쪽에서는 되고 다른 쪽에서만 실패한다면 그 차이가 중요한 단서입니다.

ChatGPT 계정으로 사용하는 Codex라면

ChatGPT 로그인 기반 Codex에서는 먼저 계정에 표시된 사용량과 재설정 시각을 확인하세요. 현재 공식 안내에 따르면 한도에 접근했거나 도달한 경우 Settings 또는 Codex usage dashboard에서 소진된 사용량, 크레딧 잔액과 표시된 재설정 시각을 확인할 수 있습니다. 활성 Codex CLI 세션에서는 /status로 현재 상태를 확인할 수 있습니다. 계정과 플랜에 따라 보이는 항목이나 이용 가능한 선택지는 다를 수 있습니다.

• 근거: ChatGPT 플랜에서 Codex를 사용하는 방법

Codex TUI의 /usage는 ChatGPT 계정의 일간, 주간, 누적 토큰 활동을 확인하는 공식 명령입니다. 다만 이 숫자 하나만으로 특정 429의 원인을 확정할 수는 없습니다. API 조직의 limits를 보여 주는 명령도 아닙니다.

• 근거: Codex 내장 슬래시 명령 안내

사용량은 단순히 메시지를 몇 개 보냈는지만으로 계산되지 않습니다. 공식 설명에 따르면 모델, 작업의 규모와 복잡도, 컨텍스트, 추론, 도구, 검색, 캐시 사용에 따라 소비량이 달라질 수 있습니다. 대상 플랜에서는 로컬 메시지와 클라우드 작업이 5시간 사용 구간을 공유하고 추가 주간 제한이 적용될 수 있습니다. 플랜과 모델별 수치는 바뀔 수 있으므로 과거 경험보다 현재 계정 화면에 표시된 값을 우선하세요.

• 근거: Codex 플랜별 사용량 안내

계정 화면에 allowance 소진과 재설정 시각이 명확히 표시된다면, 그 시각을 기준으로 작업을 중단하거나 크기를 조정하는 것이 합리적입니다. 반대로 잔여량이 보인다는 사실만으로 서비스 상태, 계정 동기화 또는 다른 실행 경로의 문제까지 배제할 수는 없습니다. 최소 작업도 계속 실패한다면 발생 범위와 시각을 기록한 뒤 지원 문의에 사용할 자료를 준비하세요.

OpenAI API 키를 사용하는 경로라면

OpenAI API의 속도 제한은 ChatGPT 계정으로 사용하는 Codex의 사용량 한도와 별개입니다. API 속도 제한은 조직·프로젝트 단위로 적용되고 모델에 따라 다르며, Developer Console의 limits 화면에서 확인할 수 있습니다.

• 근거: OpenAI API 속도 제한 안내

응답 본문에 있는 구체적인 오류 코드와 메시지를 보존하세요. OpenAI API의 429는 잔액 소진, 요청 속도 초과, 조직·프로젝트의 지출 제한, 조직 사용 한도처럼 서로 다른 범주를 가리킬 수 있습니다. 따라서 HTTP 상태만 보고 백오프를 적용해서는 안 됩니다.

• 근거: OpenAI API 오류 코드 안내

• RPM 또는 TPM 초과가 명시됐다면 요청 빈도, 동시성, 토큰 규모를 줄입니다.

• 잔액이나 quota 소진이 명시됐다면 재시도가 아니라 해당 조직·프로젝트의 billing과 사용 한도를 확인합니다.

• 지출 한도가 원인이라면 올바른 프로젝트를 보고 있는지 확인한 뒤 권한 있는 관리자가 설정을 검토해야 합니다.

• 모델별 제한이 다르므로, 다른 모델에서 성공했다는 사실만으로 계정 전체가 정상이라고 결론 내리지 않습니다.

일시적인 API 속도 제한으로 확인됐을 때만 제한된 재시도가 적합합니다. 응답에 Retry-After가 있다면 그 값을 최소 대기 기준으로 따르세요. 직접 만든 HTTP 클라이언트에서 이 헤더가 없다면 작은 무작위 지연을 더한 지수 백오프를 사용하되, 최대 시도 횟수와 전체 대기 시간을 반드시 제한해야 합니다.

• 근거: OpenAI API의 지수 백오프 지침

예를 들어 1초, 2초, 4초처럼 대기 시간을 늘리면서 작은 무작위 지연을 더할 수 있습니다. 그러나 응답이 quota나 billing 조치를 요구한다면 같은 요청을 늦게 반복해도 해결되지 않습니다. 자동화에서는 몇 번 실패하면 사람에게 넘길지까지 정해야 합니다.

게이트웨이 또는 외부 모델 공급자를 사용한다면

Codex가 별도 모델 공급자나 AI 게이트웨이를 거치도록 설정돼 있다면, 화면에 Codex가 보인다는 이유만으로 OpenAI 계정의 제한이라고 판단하면 안 됩니다. 실제 429 응답의 헤더, 본문, 요청 대상 호스트와 공급자 로그를 확인하세요. 해결 기준은 해당 공급자의 계정, 할당량, 속도 제한, 결제 상태와 장애 공지입니다.

여기서도 경계를 하나씩 분리하는 것이 유용합니다.

1. 같은 Codex 클라이언트에서 공급자만 바꾸면 증상이 달라지는가?
2. 같은 공급자를 직접 호출해도 동일한 오류 코드가 나오는가?
3. 게이트웨이 로그에 upstream 응답과 자체 제한 중 어느 쪽으로 표시되는가?
4. 실패가 특정 모델, 리전, 프로젝트 또는 자격 증명에만 한정되는가?

이 확인은 불필요한 요청을 늘리지 않는 작은 재현으로 진행하세요. 다른 경로에서 성공했다면 Codex 전체가 복구된 것이 아니라 실패 범위가 좁아졌다는 뜻입니다.

재시도 횟수를 늘리기 전에 확인할 것

오류에 retry limit가 포함돼 있으면 재시도 횟수를 키우고 싶을 수 있습니다. 그러나 이는 원인을 제거하지 않습니다. Codex의 별도 모델 공급자 설정에서 model_providers 항목의 stream_max_retries는 SSE 스트림 중단 재시도를 제어하며, 문서에 적힌 기본값은 5입니다. 이 값만으로 현재 환경에 적용된 설정이나 429 발생 주체를 알 수는 없습니다.

• 근거: Codex config.toml 설정 항목 안내

다음 상황에서는 재시도 상향이 특히 부적절합니다.

• allowance, quota, 잔액 또는 지출 한도 소진이 명시된 경우
• 잘못된 조직·프로젝트·공급자 계정을 사용 중인 경우
• 모든 최소 요청이 같은 오류로 즉시 실패하는 경우
• 공급자 상태나 계정 화면에서 사용자 조치가 필요한 제한이 확인된 경우

재시도는 간헐적이고 회복 가능한 실패를 흡수하는 장치입니다. 지속적인 제한을 숨기거나 요청을 무한히 보내는 장치가 아닙니다.

증상별로 다음 행동 결정하기

계정 화면에 소진과 재설정 시각이 표시된다

표시된 시각과 시간대를 기록하고 그 계정의 안내를 기준으로 기다리거나 작업 계획을 조정하세요. 다른 계정이나 API 키의 한도와 혼동하지 마세요. 남은 시간이 길다면 큰 작업을 잘게 나누는 것만으로 당장 실행 권한이 돌아오지는 않습니다.

API 응답이 일시적인 속도 제한을 명시한다

Retry-After를 따르거나 제한된 지수 백오프를 적용하고, 동시성과 요청·토큰 규모를 줄입니다. 재시도 예산을 소진하면 자동으로 멈추고 응답 세부정보를 남기세요.

응답이 할당량, 잔액 또는 지출 한도를 가리킨다

재시도를 멈추고 실제 요청이 귀속된 조직과 프로젝트의 limits 및 billing을 확인하세요. 결제 정보가 있다고 해서 사용 가능한 잔액이나 지출 한도가 자동으로 충분하다는 뜻은 아닙니다.

계정 화면과 응답만으로 분류되지 않는다

작은 작업 하나로 재현 범위를 확인한 뒤 더 이상 반복하지 마세요. 발생 시각, Codex 사용 환경, 인증 방식, 모델·공급자, 오류 코드, 관련 헤더, 민감정보를 제거한 request ID와 재현 범위를 정리해 해당 계정이나 공급자의 지원 채널에 문의할 수 있습니다. 현재 상태를 확인하지 않은 채 서비스 장애 또는 사용량 소진으로 추정하면 잘못된 곳에서 기다리게 됩니다.

복구 여부를 확인하는 안전한 기준

복구 확인은 원래의 큰 작업을 바로 다시 실행하는 방식보다 작은 읽기 전용 또는 저비용 요청 한 번으로 시작하는 편이 낫습니다. 한 번 성공했다면 동일한 인증·모델·공급자 경로에서 짧은 후속 작업을 진행하고, 다시 429가 나타나면 즉시 중단하세요.

다음 조건을 만족하면 작업 재개를 고려할 수 있습니다.

• 계정 또는 공급자 화면에서 필요한 allowance·quota가 사용 가능한 상태다.
• API 응답이 요구한 대기 시간이 지났다.
• 작은 요청이 같은 경로에서 성공한다.
• 자동 재시도에 최대 횟수와 총 시간이 설정돼 있다.
• 다시 실패했을 때 원인을 확인할 로그가 남는다.

반대로 재설정 시각이 명시됐거나 할당량 또는 결제 조치가 필요한 상태라면, 계속 실행하는 것보다 멈추는 것이 올바른 복구 절차입니다. 429는 하나의 상태 코드이지만, 실제 해결책은 요청을 거절한 계정과 공급자 경계에서 결정됩니다.