Codex에서 `gpt-image-2` 모델이 존재하지 않습니다: Status, Image API, provider 확인

Codex가 The model 'gpt-image-2' does not exist 또는 “gpt-image-2 모델이 존재하지 않습니다”라고 보여도, 먼저 모델명을 바꾸지 마세요. 먼저 실패한 surface를 나누어야 합니다. OpenAI 문서는 gpt-image-2를 문서화하고 있지만, Codex 세션, 직접 Image API, Responses tool, provider route, 조직/프로젝트 접근 권한은 서로 다른 곳에서 실패할 수 있습니다.

먼저 이 표로 분기하세요.

중지 규칙: Codex만 incident window에서 실패했다면, status와 session reset을 먼저 확인하고 product code 변경은 뒤로 미루세요.

빠른 답

이 오류 문자열은 하나의 뜻이 아닙니다. Codex 안에서만 발생하면 status/session/tool routing 문제일 수 있습니다. 직접 API에서 발생하면 endpoint, project, organization verification, request shape 문제일 수 있습니다. provider 경유라면 model mapping, base URL, upstream access가 원인일 수 있습니다. 그래서 첫 해결 단계는 model name을 바꾸는 것이 아니라 owner를 정하는 것입니다.

2026-06-03 확인 기준으로 OpenAI image generation docs는 gpt-image-2를 나열합니다. 따라서 “does not exist”라는 문구만으로 모델이 전역적으로 없다고 판단하면 안 됩니다. 특정 surface가 그 모델에 도달하지 못했다는 신호로 읽어야 합니다.

Codex가 이렇게 말하는 이유

Codex는 작업 surface이지, 여러분의 직접 https://api.openai.com/v1/images/generations 호출이 아닙니다. Codex에는 session state, auth state, tool availability, routing, service health가 있습니다. 이 중 한 층이 image route에 도달하지 못하면, official docs에 모델이 있어도 model-not-found 스타일의 메시지가 나올 수 있습니다.

한국어 개발자 안내에서는 gpt-image-2가 official API name이 아닐 수 있다는 식의 불안정한 설명이 섞이기 쉽습니다. 그런 설명은 그대로 따르지 않습니다. 공식 문서 경계를 기준으로 삼고, local reader에게 필요한 것은 “Codex, direct API, Responses, provider 중 어디를 먼저 볼 것인가”입니다.

일반 API 구현 실수라면 owner는 request에 가깝습니다. endpoint, key, project, organization, provider mapping, Responses tool shape 중 하나입니다. Codex-only failure는 application code 이전 단계일 수 있습니다. repository가 Image API를 호출하지 않았는데 Codex task 안에서만 실패했다면, code 변경은 첫 번째 해결책이 아닙니다.

먼저 Status와 Codex session 확인

Codex 안에서만 실패할 때는 다음 순서로 움직입니다.

1. OpenAI Status를 열고 같은 시간대의 Codex incident를 확인합니다.
2. monitoring 또는 resolved 이후 같은 Codex task를 한 번 retry합니다.
3. fresh session을 만들거나 authentication을 refresh합니다.
4. CLI / app이 오래되었다면 update합니다.
5. timestamp, exact error, task, image tool 호출 여부를 기록합니다.
6. status가 안정된 뒤에도 재현되거나 direct API도 실패할 때만 API/provider 테스트로 넘어갑니다.

이 순서는 잘못된 수정을 막습니다. incident 중에 gpt-image-2를 다른 이름으로 바꾸면, 실제 route 문제를 숨기고 billing, logs, retries, reproduction을 더 어렵게 만듭니다.

OpenAI Image API를 최소 요청으로 검증

API account가 gpt-image-2에 접근 가능한지 확인하려면 official base URL, 같은 organization, 같은 project로 최소 요청만 보내세요. provider, proxy, 복잡한 prompt, business wrapper를 섞지 않습니다.

bash
curl https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "A small lighthouse on a cliff, simple test image",
    "size": "1024x1024"
  }'

Image API 전체 계약은 다음 글을 참고하세요: GPT-Image-2 API Guide.

Image API와 Responses를 섞지 않기

Image API와 Responses image tool은 request shape가 다릅니다. 직접 이미지를 생성하거나 편집할 때는 Image API에 model: "gpt-image-2"를 보냅니다. assistant 또는 agent workflow 안에서 이미지를 만들 때는 main model과 tools: [{ type: "image_generation" }] 조합을 사용합니다.

오류는 주로 문법을 옮길 때 생깁니다. Image API의 model field를 Responses main model로 쓰거나, Responses tool shape를 /images/generations에 보내면 model error처럼 보이지만 실제 owner는 request shape입니다.

js
const response = await client.responses.create({
  model: "gpt-5.5",
  input: "Create a simple test image and explain the composition.",
  tools: [{ type: "image_generation" }]
});

main model의 구체 이름은 account와 docs에 따라 바뀔 수 있습니다. 고정해야 할 것은 model name이 아니라 direct image endpoint와 Responses tool의 분리입니다.

Provider 또는 custom base URL

OpenAI-compatible provider는 OpenAI-style model name을 노출할 수 있지만, model map, billing, availability, fallback, upstream account는 provider 계약입니다. provider가 The model 'gpt-image-2' does not exist를 반환해도 OpenAI direct route가 없다는 뜻은 아닙니다.

확인할 항목:

• base URL이 정말 https://api.openai.com/v1인지, provider/proxy URL인지.
• provider model list가 gpt-image-2를 정확히 포함하는지.
• provider가 다른 endpoint, route name, image mode를 요구하는지.
• provider key와 OpenAI docs, 또는 OpenAI key와 provider docs를 섞지 않았는지.
• price, speed, availability, quota, refund claim을 current run에서 검증했는지.

laozhang.ai는 API/developer/provider route 문맥에서만 언급해야 합니다. price와 coverage는 provider-owned claim으로 쓰고 official OpenAI pricing과 분리합니다.

Access, project, organization gate

공식 docs에 모델이 있다는 사실과 모든 key가 사용할 수 있다는 사실은 다릅니다. Image API access는 organization verification, project scope, region/account state, key permissions의 영향을 받을 수 있습니다. ChatGPT나 Codex product access도 Platform API access를 보장하지 않습니다.

direct OpenAI도 실패한다면 아래 evidence를 모으세요.

• endpoint와 base URL
• model name
• request id 또는 response headers
• organization과 project
• verification state
• timestamp와 timezone
• region, network path, proxy
• 가장 작은 reproducible request

이 evidence pack은 support가 owner를 Codex, OpenAI API, provider, network, access gate로 분리하게 해 줍니다.

Status resolved 이후 순서

Status가 resolved인데 Codex가 계속 실패하면 짧은 ladder를 사용합니다.

1. 같은 Codex task를 한 번만 retry합니다.
2. fresh Codex session 또는 auth refresh를 합니다.
3. Codex CLI / app을 update합니다.
4. 같은 network에서 direct Image API test를 실행합니다.
5. provider를 쓰면 model list와 base URL을 별도로 확인합니다.
6. request id와 minimal repro를 가지고 support/provider ticket을 엽니다.

하나의 surface가 통과하면 문제 확장을 멈추세요. direct OpenAI pass + provider fail은 provider owner입니다. fresh Codex pass는 session/route state입니다. direct OpenAI access error는 org/project owner입니다.

자주 묻는 질문

gpt-image-2는 실제 OpenAI 모델인가요?

예. 이 run에서 OpenAI image generation docs는 gpt-image-2를 나열합니다. Codex error만으로 모델 부재를 판단하면 안 됩니다.

다른 모델명으로 바꿔야 하나요?

첫 조치로는 아닙니다. 실제 route docs가 다른 supported model 또는 alias를 요구할 때만 바꿉니다.

Direct API는 성공하지만 Codex만 실패합니다

application route가 첫 owner가 아닐 가능성이 큽니다. Codex session을 refresh하고 stable status 이후 retry하며 direct API success를 evidence로 남기세요.

provider가 HTTP 400 또는 model_not_found를 반환합니다

provider model list, base URL, endpoint, billing, upstream access를 확인하세요. OpenAI direct가 성공하면 provider coverage/mapping 문제입니다.

ChatGPT나 Codex plan이 Image API access를 보장하나요?

아니요. ChatGPT product, Codex tool, Platform API key는 서로 다른 surface입니다.

어떤 evidence를 저장해야 하나요?

exact error, surface, model name, base URL, endpoint, org/project, timestamp, request id, status state, minimal reproduction을 저장하세요.