Codex, Claude Code, DeepSeek V4 Pro를 테스트하다 보면 다음과 같이 겉보기에 모순된 현상을 마주할 때가 있습니다.

동일한 deepseek-v4-pro임에도 불구하고:
일반적인 API 호출로는 응답함;
Claude Code에서도 작동함;
...

이는 모델 성능의 문제처럼 보입니다.

DeepSeek V4 Pro는 코딩에 취약한가?
모델이 약한가?
Codex는 서드파티 모델을 거부하고 있는가?

실제로 검증한 결과, 원인은 그곳에 있지 않았습니다. Codex, Claude Code, 일반적인 OpenAI-compatible API는 동일한 프로토콜 계층이 아닙니다.

DeepSeek V4 Pro가 코드 질문에 답할 수 있다는 것과, Codex가 기대하는 Responses API의 agent loop를 직접 충족할 수 있다는 것은 별개의 문제입니다.

2026-07-05 실측 결과는 다음과 같습니다.

deepseek-v4-pro는 /v1/models에 존재함;
/v1/chat/completions는 동작함;
/v1/responses는 HTTP 400 convert_request_failed를 반환함;
...

현시점에서의 권장 사항은 다음과 같습니다.

용도	권장 사항
일반적인 코드 Q&A	/v1/chat/completions를 사용
Claude Code	/v1/messages 호환 레이어를 통해 테스트
Codex	/v1/responses 모델로 직접 사용하지 말 것

이는 DeepSeek V4 Pro가 코드를 작성하지 못한다는 의미가 아닙니다. Codex native Responses 모델로 취급해서는 안 된다는 의미입니다.

많은 개발자는 "OpenAI-compatible"을 다음과 같이 이해하기 쉽습니다.

OpenAI 스타일의 API를 지원한다면, 모든 OpenAI 클라이언트에서 사용할 수 있다.

하지만 실제로는 다릅니다.

적어도 다음 3가지는 구분해서 생각해야 합니다.

1. /v1/chat/completions
2. /v1/responses
3. /v1/messages

모두 "메시지를 보내고 응답을 받는다"는 점은 같아 보이지만, 규약(contract)이 다릅니다.

Endpoint	주요 클라이언트	핵심 구조	적합 난이도
/v1/chat/completions	일반적인 채팅, OpenAI SDK 앱	messages / choices	낮음
/v1/responses	Codex / OpenAI agent workflow	input items / output items / tool events	높음
/v1/messages	Claude Code / Anthropic SDK	content blocks / tool_use / tool_result	중간

모델이 openai endpoint만을 선언하고 있는 경우, 대부분은 OpenAI-compatible chat을 사용할 수 있다는 의미입니다. Responses API의 완전한 대응을 의미하는 것은 아닙니다.

확인한 API:

GET https://cn.crazyrouter.com/v1/models

deepseek-v4-pro의 반환 예시:

{
"id": "deepseek-v4-pro",
"object": "model",
...
}

중요한 점은 다음과 같습니다:

supported_endpoint_types: ["openai"]

이는 모델이 온라인 상태이며, OpenAI-compatible 모델로서 공개되어 있음을 나타냅니다.

하지만 다음 사항을 증명하는 것은 아닙니다:

/v1/responses 지원
Codex tool call item 지원
Responses streaming events 지원
...

첫 번째 판단 기준은 이것입니다.

/v1/models에 나타난다는 것은 "보인다"는 것을 의미할 뿐, 모든 agent 클라이언트에 적합하다는 것을 의미하지 않습니다.

일반적인 OpenAI 호환 (OpenAI-compatible) chat을 시도합니다.

curl https://cn.crazyrouter.com/v1/chat/completions \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
...

결과는 성공이었습니다.

HTTP: 200
Visible content: DS_V4_PRO_CHAT_OK
finish_reason: stop

즉, chat 모델로서는 동작합니다.

하지만 max_tokens: 30으로 설정하면, 보이는 출력은 이것뿐이었습니다.

DS

usage에는 다음과 같이 나타났습니다.

finish_reason: length
completion_tokens: 30
reasoning_tokens: 28

DeepSeek V4 Pro는 reasoning tokens (추론 토큰)를 소비합니다. 출력 예산이 너무 작으면 HTTP 200 응답이 오더라도 실용적인 결과를 얻을 수 없습니다.

코딩 에이전트 (coding agent)에서는 반드시 다음 사항을 확인해야 합니다.

finish_reason
visible content
completion_tokens
...

Codex에서 중요하게 작용하는 Responses API를 시도합니다.

curl https://cn.crazyrouter.com/v1/responses \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
...

결과:

HTTP: 400
Error code: convert_request_failed
Error type: new_api_error
...

이것이 핵심입니다.

Codex의 provider 설정이 다음과 같은 경우:

[model_providers.custom]
wire_api = "responses"
base_url = "https://your-router.example/v1"

Codex는 /v1/responses의 의미론 (semantics)에 따라 요청을 보냅니다. 백엔드는 Responses의 input/output, tool events, multi-turn continuation (다회차 대화 지속)을 이해해야 합니다.

이번 테스트에서 DeepSeek V4 Pro는 /v1/responses를 통과하지 못했습니다. 따라서 Codex의 Responses 모델로 직접 다루어서는 안 됩니다.

Codex는 단순히 prompt (프롬프트)를 보내고 텍스트를 기다리는 것이 아닙니다.

실제 태스크는 다음과 같은 흐름으로 진행됩니다.

리포지토리의 컨텍스트를 읽음
-> 변경 사항을 계획함
-> 파일 읽기 도구 (file reading tool)를 호출함
...

이를 위해서는 안정적인 구조화된 이벤트 (structured events)가 필요합니다.

필요한 능력	결여될 시 발생하는 현상
Responses input/output items	클라이언트가 출력 단계를 분류할 수 없음
...

chat completions가 성공하더라도, Codex workflow가 성공한다는 보장은 없습니다.

Claude Code는 보통 Anthropic Messages 형식을 사용합니다.

POST /v1/messages

이번에 deepseek-v4-pro는 /v1/messages를 통해 다음 3단계를 통과했습니다.

1. 텍스트 요청 성공
2. tool_use 성공
3. tool_result 이후의 지속 성공

tool call은 다음과 같이 반환되었습니다.

{
"type": "tool_use",
"id": "call_00_85VnDZJN9knCdt3l4aX67165",
...

그다음 이것을 반환합니다.

{
"type": "tool_result",
"tool_use_id": "call_00_85VnDZJN9knCdt3l4aX67165",
...

최종 응답:

The timezone for Beijing is Asia/Shanghai.

즉, Claude Code 호환 경로에서는 기본적인 tool loop (도구 루프)가 통과됩니다.

올바른 경로는 다음과 같습니다.

Claude Code
-> /v1/messages
-> gateway (게이트웨이)가 Claude Messages를 OpenAI-compatible chat (OpenAI 호환 채팅)으로 변환
...

호환 레이어 (compatibility layer)는 text blocks, tool_use, tool_result, stop reasons, SSE events, usage를 처리합니다.

관점	Codex	Claude Code 호환 레이어
입구	/v1/responses	/v1/messages
중심 프로토콜	OpenAI Responses	Anthropic Messages
모델에 대한 요구	Responses agent item semantics	Claude content blocks로 변환 가능
DeepSeek V4 Pro의 결과	400 convert_request_failed	텍스트와 tool loop는 성공
권장 사항	직접 연결하지 말 것	gateway를 통해 테스트 가능

Codex가 필요로 하는 것은 Responses agent runtime입니다. Claude Code 호환 레이어가 필요로 하는 것은 변환 가능한 Messages / tool_use 구조입니다.

• /v1/models를 확인하여 supported_endpoint_types를 본다.
• /v1/chat/completions를 확인하여 content, finish reason, usage, reasoning tokens를 본다.
• /v1/responses를 확인한다. 여기서 실패한다면 Codex에 직접 연결하지 않는다.
• Claude Code에서는 text, tool_use, tool_result, final answer를 확인한다.

일반적인 코드 Q&A:

/v1/chat/completions를 사용한다

Claude Code:

/v1/messages 호환 방식을 사용한다
실제 리포지토리 작업을 수행하기 전에 tool_use -> tool_result를 확인한다

Codex:

먼저 /v1/responses를 검증한다
그 다음 tool calls, tool results, streaming events, reasoning state를 확인한다
마지막으로 실제 리포지토리에서 사용한다

절대적인 것은 아닙니다. 다만 이번 테스트에서는 /v1/responses 모델로서 작동하지 않았습니다. 전용 Responses adapter가 있다면 별도로 검증할 수 있겠지만, tools, streaming, continuation에 대한 확인이 필요합니다.

Claude Code는 /v1/messages를 통하며, gateway가 Claude content blocks와 OpenAI-compatible chat 사이를 변환할 수 있습니다. Codex는 /v1/responses를 사용하며, 다른 agent item semantics를 기대합니다.

다릅니다. 작은 token budget (토큰 예산) 테스트에서는 HTTP 200이었으나, visible content (가시적 콘텐츠)는 DS뿐이었습니다. reasoning tokens (추론 토큰)가 출력 예산을 모두 소비했기 때문입니다.

문제는 코드 능력이 아니라 프로토콜 적합성입니다.

deepseek-v4-pro는 보임;
/v1/chat/completions는 작동함;
/v1/responses는 400 convert_request_failed;
...

따라서:

일반 API: 이용 가능
Claude Code: Messages compatibility를 통해 테스트
Codex: Responses model로서 직접 연결하지 말 것

코딩 에이전트 (coding agent)에서는 모델명이 아니라 endpoint (엔드포인트)의 동작과 tool-loop의 실측을 통해 호환성을 판단해야 합니다.

원문 기사 및 테스트 기록: