exceeded retry limit, last status: 429 Too Many Requests가 표시되면 Codex는 이미 자동 재시도를 여러 번 수행한 뒤 작업을 종료한 상태입니다. 이 문구만으로 주간 한도 소진, API 잔액 부족, 서버 장애 중 하나를 고를 수는 없습니다.
같은 대형 작업을 새 창과 여러 subagent에서 즉시 다시 보내지 마세요. 현재 변경 파일을 보존하고, 새 병렬 작업을 멈춘 다음, 오류 원문·발생 시각과 시간대·표시된 request ID를 기록하세요. 복구의 출발점은 “몇 분 기다릴까”가 아니라 “이 요청은 어느 계정, workspace, API project, provider가 소유했나”입니다.
재시도 한도와 사용량 한도는 다른 값이다
retry limit은 클라이언트가 자동으로 다시 시도할 수 있는 횟수입니다. 별도의 계정 quota가 아닙니다. last status: 429는 마지막 서버 또는 gateway 응답입니다. 429 역시 하나의 원인 이름이 아닙니다.
OpenAI의 현재 API 오류 코드 안내는 요청 속도, 선불 credit 소진, organization/project spend limit, organization usage limit을 서로 다른 429로 설명합니다. direct API의 billing 관련 사례에서는 넓은 error.type보다 error.code가 구체적이며 복구 행동도 달라집니다.
또한 custom base_url, 기업 gateway, model router, 외부 provider를 쓰면 그 중간 계층이 429를 만들거나 변환할 수 있습니다. ChatGPT 사용량이 남아 있다는 사실은 제3자 지갑이나 동시 실행 pool이 남았다는 증거가 아닙니다.
설정을 바꾸기 전에 limit owner를 고정한다
로그아웃, model 교체, network 변경, key 회전, provider 변경을 한꺼번에 하면 증상이 사라져도 원인을 알 수 없습니다. 현재 경로를 먼저 분류하세요.
| Codex 실행 방식 | 확인할 소유자 | 분류에 필요한 증거 |
|---|---|---|
| ChatGPT 로그인 | 개인 account 또는 workspace의 Codex Usage | 5시간/주간 창, reset, credits, CLI /status |
| direct OpenAI API key | API organization/project | response body, error.code, Retry-After, Limits, Billing |
| Business·Enterprise·Edu | 관리형 workspace | seat, 공유/구매 credits, 관리자 정책과 예산 owner |
| 제3자 provider/gateway | 해당 provider 계약 | 실제 base URL, headers, request ID, balance, model pool, status |
OpenAI의 현재 Codex 사용량 안내는 account의 현재 limit을 Usage Dashboard에서 확인하고 Codex CLI에서는 /status로 잔여 limit을 볼 수 있다고 설명합니다. 표시 필드는 client, version, 인증, plan, rollout에 따라 다릅니다. 보이지 않는 필드를 0이나 “제한 없음”으로 읽지 마세요.
계정을 바꿨는데 같은 제한이 이어진다면 계정·workspace·API·로컬 로그인 점검으로 분기하세요. 오래된 세션, 동일 workspace, 동일 API organization을 확인하는 문제이며, 연속 재시도로 구분할 수 없습니다.
“한도가 남았다”를 meter 이름으로 다시 말하기
남은 값이 주간 퍼센트인지, 5시간 창인지, ChatGPT credits인지, API prepaid credit인지, project spend 여유인지, 외부 provider 잔액인지 적어 보세요. 이들은 서로 다른 장부입니다.
OpenAI의 tokens와 credits 설명에 따르면 credit cost는 model, context, reasoning, tools에 따라 달라지고, 해당 plan에서는 included limits 이후 available credits로 계속 작업할 수 있습니다. 같은 문서는 ChatGPT plan의 local messages와 cloud chats가 5시간 window를 공유하고 추가 주간 limit이 적용될 수 있다고 설명합니다. 따라서 메시지 수는 비용 단위가 아니며, 주간 퍼센트가 남았다고 다른 짧은 창이나 provider 제한이 사라지는 것도 아닙니다.
복구 전 상태 기록에는 다음이면 충분합니다.
- Codex surface와 client version
- ChatGPT login, API key, 또는 custom provider
- 가린 account/workspace와, API라면 organization/project
- model, reasoning, Fast, subagent 사용 여부
- visible usage, reset, credits, provider balance
- 실행 중인 local, cloud, scheduled, delegated, background task
- 오류 원문, timestamp, timezone, request ID
지원 자료에는 API key, access token, OTP, 전체 email, credential file, 비공개 code, 전체 결제 화면을 넣지 않습니다.
429 유형에 따라 멈춤 조건을 바꾼다
요청 속도 또는 일시적 throttling
direct OpenAI API의 request-rate 429에서 공식 안내는 요청 속도를 낮추고, Retry-After가 있으면 적어도 해당 시간만큼 기다리라고 설명합니다. custom HTTP client에서 header가 없으면 jitter를 더한 exponential backoff를 쓰고 시도 횟수와 총 retry 시간을 모두 제한합니다. OpenAI 공식 SDK는 적용 가능한 rate-limit error를 자동 재시도하고 Retry-After가 있으면 따르므로 별도 retry layer를 추가하기 전에 그 시도를 계산해야 합니다. 실패한 요청도 분당 limit에 포함될 수 있습니다.
Codex가 이미 exceeded retry limit을 표시했다면 클라이언트의 bounded retry는 끝났습니다. 여러 session에서 수동 재전송하지 말고 병렬 작업을 중지하세요. 화면의 reset 또는 provider 지시를 기다린 뒤, 종료 조건이 분명한 작은 작업 하나로 복구를 확인합니다. 성공하면 대기 queue를 한꺼번에 풀지 말고 점진적으로 늘립니다.
ChatGPT/Codex 사용량 창
ChatGPT 인증이면 동일 account 또는 workspace의 Usage를 확인합니다. 5시간과 주간 meter를 분리하고, 실제 표시된 reset, 사용할 수 있는 credits, 겹쳐서 실행 중인 agentic task를 기록하세요.
지배하는 창이 명확히 소진됐다면 표시된 reset을 기다리거나, account가 제공하고 비용을 받아들일 수 있을 때 정식 credits를 사용합니다. 더 가벼운 model, 짧은 context, 적은 tools는 복구 이후 소모를 예측하기 쉽게 만들지만 닫힌 창을 즉시 다시 여는 방법은 아닙니다.
API credit, spend, usage limit
direct API라면 response의 error.code를 읽습니다. credit_balance_exhausted, organization_spend_limit_exceeded, project_spend_limit_exceeded, organization_usage_limit_exceeded는 모두 429일 수 있지만 owner와 해결 조건이 다릅니다.
OpenAI는 credit, spend, quota 오류를 계속 재시도해도 API access가 복구되지 않는다고 명시합니다. 실제 reset을 기다리거나 권한 있는 organization/project owner가 해당 balance 또는 limit을 조정해야 합니다. 동일 project의 key만 교체해도 새 quota가 생기지 않습니다.
제3자 gateway
base URL이 OpenAI direct endpoint가 아니면 provider의 rate-limit headers, balance, concurrency, model pool, request ID, status를 확인합니다. gateway가 다른 upstream 오류를 자체 429로 매핑할 수도 있습니다. 원본 응답이 없다면 “이 route가 429를 반환했다”까지만 확정할 수 있습니다.
인증과 model은 유지하고, provider가 제시한 간격을 기다리거나 동시 실행 수 한 가지만 낮춘 뒤 작은 요청을 테스트합니다. 제3자 계약을 ChatGPT Usage 퍼센트로 설명하지 마세요.
서비스 incident
OpenAI Status에서 제품, 시각, 지역이 겹치는 공개 incident를 확인합니다. 일치하는 사건이 있으면 공식 timeline을 따르고 request ID를 보존하세요. 공개 사건이 없다는 것은 공개 확인이 없다는 뜻일 뿐, 모든 account·지역·gateway가 정상이라는 증거는 아닙니다.
재개 후 첫 작업은 원래 작업보다 작아야 한다
reset, limit 변경, provider 복구 뒤에도 이전 process나 cloud task가 살아 있지 않은지 확인합니다. account, route, model, reasoning, Fast를 고정하고 몇 분 안에 끝나는 좁은 작업을 실행하세요. 전후의 같은 meter 또는 provider 상태를 저장합니다.
작은 작업은 성공하지만 큰 작업만 다시 429가 되면 부하 모양, concurrency, context, 짧은 사용량 창이 더 강한 후보입니다. 가장 작은 작업도 즉시 같은 429를 받으면 대형 재전송은 새 정보를 주지 않습니다. quota, provider, status 증거로 돌아가세요.
이 전후 비교는 주간 사용량이 예상보다 빠르게 줄어든 경우에도 유용합니다. 완전한 task별 청구서는 아니지만, 보이는 작업과 함께 움직인 값, 다른 surface의 활동, 아직 설명되지 않는 변화를 구분할 수 있습니다.
복구 조건을 충족했는데도 재현된다면 client/version, 인증 경로, provider, model/mode, 오류 원문, timestamp/timezone, request ID, visible usage/reset, 병렬 활동, 최소 재현 순서를 정리합니다. API에서는 비밀을 제거한 error.code와 관련 rate-limit headers를 추가하되 Authorization header와 private request body는 제외합니다.
올바른 순서는 중복 요청 중지, request owner 확인, subtype 증거 읽기, 실제로 실패한 조건 변경, 작은 테스트 1회입니다. 이렇게 해야 기다림, credit 조정, workspace 관리자 문의, provider ticket 중 하나를 근거 있는 다음 행동으로 선택할 수 있습니다.
