DeepSeek V4 Pro 为什么不适合直接用于 Codex，但可以通过 Claude Code 使用

DeepSeek V4 Pro 为什么不适合直接用于 Codex，但可以通过 Claude Code 使用#

很多人会把问题简化成一句话：DeepSeek V4 Pro 会写代码，那它是不是也能直接当 Codex 的模型？

更准确的答案是：不一定。DeepSeek V4 Pro 这类模型如果主要以 OpenAI-compatible chat completions 形态提供服务，它可以完成大量代码问答、重构建议、补全和普通工具调用任务；但 Codex 不是一个普通聊天客户端。Codex 更像一个依赖特定协议语义的 agent runtime，尤其依赖 /v1/responses、reasoning state、工具调用事件和多轮上下文续写。

所以，DeepSeek V4 Pro 不能很好地直接用于 Codex，核心通常不是“模型不会写代码”，而是“模型接口不完全符合 Codex 需要的运行协议”。

相反，Claude Code 的兼容路径通常更容易把 DeepSeek 这类模型跑起来。原因也不是 Claude Code 原生支持 DeepSeek，而是很多中转网关可以接收 Claude Code 的 /v1/messages 请求，再把它转换成 OpenAI-compatible chat completion，最后把模型输出转换回 Claude Code 能读的 Claude Messages 流式事件。

Last updated: 2026-07-05.

Quick Answer#

DeepSeek V4 Pro 不适合直接用于 Codex，主要因为 Codex 当前更依赖 OpenAI Responses API 语义，而 DeepSeek V4 Pro 在 2026-07-05 的 Crazyrouter 实测中只声明 openai endpoint，POST /v1/chat/completions 可用，但 POST /v1/responses 返回 HTTP 400。Codex 需要的不只是文本回复，还包括稳定的工具调用、reasoning item、多轮 continuation、流式事件和上下文状态。

DeepSeek V4 Pro 可以用于 Claude Code，通常是因为网关把 Claude Code 的 /v1/messages 协议转换成 OpenAI-compatible chat completion，再把 DeepSeek 的输出转换回 Claude Code 期望的 Claude content blocks。本轮实测中，/v1/messages 文本请求、tool_use 请求和 tool_result 续写都返回 HTTP 200。这个方式可用，但属于兼容层适配，不等于 DeepSeek 原生支持 Claude Code。

What We Checked#

本文不是 DeepSeek V4 Pro 性能评测，而是协议适配解释。检查范围包括：

本轮使用本地 CRAZYROUTER_API_KEY 访问 https://cn.crazyrouter.com/v1/models，接口返回 HTTP 200。deepseek-v4-pro 当前存在，并且模型对象显示：

{
  "id": "deepseek-v4-pro",
  "supported_endpoint_types": ["openai"],
  "public_endpoint_types": ["openai"]
}

这个结果很关键：它说明 DeepSeek V4 Pro 当前可作为 OpenAI-compatible 模型使用，但模型列表没有把它声明成 native Responses 模型。

Real Test Results#

测试时间：2026-07-05，Base URL：https://cn.crazyrouter.com/v1。

The small-token chat test is also useful: DeepSeek V4 Pro returned reasoning_content and counted reasoning_tokens, so very low output budgets can truncate visible answers even when the API call itself succeeds.

The Three Endpoints Matter#

这类问题最容易混淆的地方，是把所有“OpenAI-compatible”都当成同一种能力。实际至少要区分三个入口：

POST /v1/chat/completions
POST /v1/responses
POST /v1/messages

它们看起来都能“发消息，拿回复”，但 agent 客户端关心的是更细的语义：

DeepSeek V4 Pro 如果只稳定支持第一类，它就能在普通 API 调用里工作，但不自动等于能在 Codex 里工作。

Why Codex Is Harder#

Codex 的关键点是：它不是把一段 prompt 发给模型，然后等一段文本。Codex 要在本地仓库里规划、读文件、改文件、运行命令、接收工具结果，再继续下一轮。

一个典型 Codex custom provider 配置会长这样：

model_provider = "custom"
model = "gpt-5.5"

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

这里最重要的是 wire_api = "responses"。它意味着 Codex 会按 Responses API 语义来和后端通信，而不是只按 chat completions 语义通信。

在真实多轮任务中，Codex 可能依赖：

• reasoning_effort
• response output items
• function/tool call item
• tool result continuation
• 多轮 input item
• reasoning.encrypted_content 这类续写状态
• 流式事件顺序
• 失败后的重试和同会话路由粘性

如果某个模型只会返回普通 chat completion，它可能会在简单问答中表现不错，但在 Codex agent workflow 里出现这些问题：

这就是为什么“DeepSeek V4 Pro 能写代码”和“DeepSeek V4 Pro 适合作为 Codex 后端”是两件事。

Local Gateway Evidence#

在本地网关代码里，/v1/responses 被当成独立能力处理。路由选择会检查请求是不是 native Responses request，并跳过不支持 native Responses 的渠道。

简化后的逻辑可以理解为：

if request path starts with /v1/responses:
  require channel/model to support native Responses
else:
  use normal chat or provider-specific route

对应的用户提示也很直接：如果一个非 Claude 模型不支持 /v1/responses，应该使用 POST /v1/chat/completions。

本地测试里甚至有一个 DeepSeek V4 系列相邻模型的语义测试，预期错误就是：

Model deepseek-v4-flash does not support /v1/responses.
Use POST /v1/chat/completions instead.

2026-07-05 对 deepseek-v4-pro 的线上实测与这条工程判断一致：模型本身在线，/v1/chat/completions 可用，但 /v1/responses 返回 HTTP 400 convert_request_failed。也就是说，问题不是“DeepSeek V4 Pro 不存在”，而是它当前不应该被当作 Codex native Responses 模型使用。

Why Claude Code Can Work#

Claude Code 的情况不同。Claude Code 客户端通常走 Anthropic Messages 形态：

POST /v1/messages

Claude Messages 的结构以 content blocks 为核心，比如：

{
  "model": "claude-sonnet-4-6",
  "messages": [
    {
      "role": "user",
      "content": "Read this repository and summarize the API routes."
    }
  ],
  "tools": [
    {
      "name": "Read",
      "input_schema": {
        "type": "object",
        "properties": {
          "file_path": { "type": "string" }
        },
        "required": ["file_path"]
      }
    }
  ]
}

如果中转网关支持 Claude Messages 兼容层，它可以做两次转换：

Claude Code
  -> /v1/messages
  -> gateway converts Claude request to OpenAI-compatible chat request
  -> DeepSeek V4 Pro generates text/tool calls
  -> gateway converts output back to Claude content blocks / SSE
  -> Claude Code receives a Claude-like stream

这个路径绕开了 Codex 最依赖的 /v1/responses 原生语义。DeepSeek 只需要在 chat completions 层面足够稳定，网关负责把它包装成 Claude Code 能读的形态。

本轮实测证明这条路径至少在基础层面成立：

POST /v1/messages
model: deepseek-v4-pro
text request: HTTP 200, returned [{"type":"text","text":"DS_V4_PRO_MESSAGES_OK"}]
tool_use request: HTTP 200, returned tool_use get_city_timezone({"city":"Beijing"})
tool_result continuation: HTTP 200, returned final text

But Claude Code Compatibility Is Not Free#

DeepSeek V4 Pro 能通过 Claude Code 使用，不代表它没有限制。兼容层至少要处理这些细节：

本地代码里有专门的 Claude handler、Claude tool_use 校验、OpenAI-to-Claude stream 转换和 Claude cache usage 修复。这说明 Claude Code 兼容不是“把 base_url 换一下”这么简单，而是需要完整协议适配。

Why The Same Model Feels Better In Claude Code#

从使用体验看，DeepSeek V4 Pro 可能在 Claude Code 中“能跑”，在 Codex 中“别扭”，根本原因是两个客户端对模型的要求不同。

Codex 要的是一个能参与 Responses agent loop 的模型。Claude Code 兼容层要的是一个能在网关帮助下产生足够稳定文本和 tool call 的模型。

这就是差异。

Recommended Setup#

如果你要在生产环境里用 DeepSeek V4 Pro，建议分开配置，而不是让它同时承担所有 agent 客户端。

用于普通 API#

Base URL: https://cn.crazyrouter.com/v1
Endpoint: POST /v1/chat/completions
Model: deepseek-v4-pro

2026-07-05 实测中，该路径返回 HTTP 200。注意给 DeepSeek V4 Pro 留足 max_tokens：max_tokens=30 时，reasoning tokens 占用 28 个 completion tokens，导致可见输出被截断；max_tokens=128 时，exact-output 测试正常返回。

用于 Claude Code 兼容层#

Claude Code -> /v1/messages -> gateway -> /v1/chat/completions -> DeepSeek V4 Pro

2026-07-05 实测中，POST /v1/messages 对 deepseek-v4-pro 的文本请求、tool_use 请求和 tool_result 续写都返回 HTTP 200。这说明 Claude Code 兼容层不是只会普通聊天，至少能跑一个基础工具闭环。

重点验证：

• Claude Code 是否能收到非空流式输出；
• tool_use 是否能正确回传；
• tool_result 后模型是否能继续；
• 长任务是否会丢失工具状态；
• usage / cache 记录是否正确；
• 超时后是否能安全重试。

不建议直接用于 Codex#

除非你已经确认 DeepSeek V4 Pro 后端完整支持：

POST /v1/responses
response output items
tool call items
tool result continuation
reasoning effort
multi-turn reasoning state
streaming Responses events

2026-07-05 实测中，POST /v1/responses 对 deepseek-v4-pro 返回 HTTP 400 convert_request_failed。因此，不要只因为模型能走 /v1/chat/completions，就把它配置成 Codex 的 Responses provider。

Production Validation Checklist#

上线前至少跑这些检查：

最重要的判断规则是：

HTTP 200 != agent workflow success

对于 Codex，至少要验证：

HTTP 200 + valid Responses items + tool call loop + non-empty output + successful continuation

对于 Claude Code，至少要验证：

HTTP 200 + valid Claude SSE/content blocks + tool_use/tool_result loop + non-empty output

When To Use DeepSeek V4 Pro#

适合：

• 普通代码解释；
• 单文件重构建议；
• API 文档问答；
• SQL / shell / regex 辅助；
• 通过 Claude Code 兼容层跑轻量 agent 任务；
• 成本敏感、但可以接受兼容层验证的场景。

不适合：

• 直接作为 Codex 主力 Responses 模型；
• 依赖复杂 tool loop 的长任务；
• 需要稳定 reasoning continuation 的多轮任务；
• 不能容忍工具状态丢失的自动修改任务；
• 没有日志、没有 fallback、没有空输出检测的生产环境。

如果要在一个统一网关里管理这些模型，可以先查看 Crazyrouter models 和 Crazyrouter pricing，再用自己的 prompt 做小样本验证。

FAQ#

1. DeepSeek V4 Pro 是不是完全不能用于 Codex？#

不是绝对不能。准确说法是：如果它没有完整支持 Codex 当前需要的 Responses API 语义，就不适合直接作为 Codex 主模型。可以通过专门 adapter 做转换，但需要验证 tool loop、reasoning continuation 和 streaming events。

2. 为什么普通 OpenAI-compatible 不够？#

因为 OpenAI-compatible 经常只表示兼容 /v1/chat/completions。Codex 需要的是 /v1/responses 这一层的 agent workflow 语义。两者不是同一个合同。

3. Claude Code 为什么反而可以跑 DeepSeek？#

因为 Claude Code 可以通过 /v1/messages 进入中转网关。网关把 Claude Messages 转成 OpenAI-compatible chat completion，再把 DeepSeek 输出转回 Claude content blocks。真正起作用的是兼容层，不是 Claude Code 原生识别 DeepSeek。

4. 这种 Claude Code 兼容方式稳定吗？#

取决于网关实现和模型输出稳定性。必须测试 tool_use、tool_result、流式输出、usage、长上下文和重试。只测一句 hello 没意义。

5. 如果一定想把 DeepSeek V4 Pro 用在 Codex，应该怎么做？#

先不要直接替换模型。应该先搭一个测试 provider，记录 Codex 发出的真实 /v1/responses payload，再确认你的网关能把 Responses items、tool calls、tool outputs、reasoning state 都正确转换。没有这些验证，不建议用于真实仓库自动修改。

6. DeepSeek V4 Pro 在 Claude Code 中能替代 Claude Sonnet 吗？#

不能简单替代。Claude Code 的交互和工具格式是 Claude 生态原生设计的，DeepSeek 通过兼容层能跑，不代表在长任务规划、工具使用和上下文保持上完全等价。

7. Crazyrouter 在这里的价值是什么？#

这类问题本质是多协议网关问题。一个实用网关需要同时理解 /v1/chat/completions、/v1/responses、/v1/messages，并对模型能力、endpoint 支持、工具调用、fallback 和计费做区分。你可以从 Crazyrouter quickstart 开始，再按客户端分别验证。

Final Verdict#

DeepSeek V4 Pro 不能很好地直接用于 Codex，主要不是模型能力问题，而是协议问题。2026-07-05 的 Crazyrouter 实测显示：deepseek-v4-pro 在线，声明 endpoint type 为 openai，/v1/chat/completions 可用，但 /v1/responses 返回 HTTP 400 convert_request_failed。Codex 需要的是 OpenAI Responses agent loop，而 DeepSeek V4 Pro 当前更适合作为 OpenAI-compatible chat 模型使用。

Claude Code 可以用 DeepSeek V4 Pro，通常是因为中转网关承担了 Claude Messages 到 OpenAI chat 的转换工作。本轮实测中，/v1/messages 文本请求、tool_use 请求和 tool_result 续写都成功。因此这个方案可以实用，但仍要把它当成兼容层方案来测试：确认流式事件、长上下文、空输出、多轮续写和计费字段都可靠，再进入生产使用。