Background
If you’ve been running OpenClaw and tried to upgrade to DeepSeek’s latest models, you may have run into a frustratingly silent failure: channels stop responding, and the gateway log fills with FailoverError: LLM request failed: provider rejected the request schema or tool payload. Here is a full account of what went wrong and how we fixed it.
OpenClaw’s AI gateway was previously configured with two DeepSeek models:
deepseek-chat— the standard chat modeldeepseek-reasoner— the reasoning/thinking model
In April 2026, DeepSeek released V4, introducing deepseek-v4-pro and deepseek-v4-flash as the new generation. Both legacy model names will be deprecated on 2026-07-24.
Issue 1: HTTP 400 — Provider Rejected the Request Schema or Tool Payload
After registering deepseek-v4-pro in the OpenClaw config with reasoning: true, every message to any channel (Telegram, Discord, WeixinWork) would trigger a 400 error:
LLM request failed: provider rejected the request schema or tool payload.
reason: format, status: 400Root Cause
When reasoning: true is set in OpenClaw, the gateway appends a thinking/reasoning parameter to the API request. Combined with OpenClaw tool call payload (function definitions), DeepSeek V4 Pro API rejected the combined request format. Key insight from the DeepSeek docs: thinking mode with tool calls is supported from V3.2 onwards, but the exact parameter format matters. OpenClaw reasoning: true flag was sending a format that V4 Pro did not accept alongside tool definitions.
Fix
Set reasoning: false for deepseek-v4-pro. The model still performs internal chain-of-thought reasoning by default — we just do not instruct it explicitly via the API parameter, which prevents the format conflict:
{
"id": "deepseek-v4-pro",
"api": "openai-completions",
"reasoning": false,
"contextWindow": 1000000,
"maxTokens": 32768
}Issue 2: maxTokens Set Too High
The initial configuration had maxTokens: 393216 (DeepSeek V4 Pro theoretical 384K output ceiling). This caused the API to reject requests outright.
Fix
Set maxTokens: 32768, the safe default for a single request. DeepSeek extended output capability is controlled through a per-request override when needed, not by the model registration default.
Issue 3: Context Window Displaying as 200K Instead of 1M
After setting contextWindow: 1000000 in the model definition, the OpenClaw TUI still showed 200k as the context ceiling.
Root Cause
OpenClaw resolves context window size at two levels: the model definition and the agent-level model entry in agents.defaults.models. The agent-level entry was empty ({}), so it fell back to a 200K default rather than picking up the 1M from the model definition.
Fix
Add an explicit override in agents.defaults.models:
"agents": {
"defaults": {
"models": {
"deepseek/deepseek-v4-pro": {
"contextWindow": 1000000
}
}
}
}Summary of Config Changes
| Parameter | Before | After |
|---|---|---|
reasoning |
true | false |
maxTokens |
393216 | 32768 |
contextWindow (model) |
1000000 | 1000000 ✓ |
contextWindow (agent override) |
missing | 1000000 |
| Primary model | deepseek/deepseek-reasoner | deepseek/deepseek-v4-pro |
| Fallback model | deepseek/deepseek-reasoner | deepseek/deepseek-chat |
Takeaways
- reasoning: true conflicts with tool calls — If your gateway sends tool definitions, disable the reasoning flag and let the model handle it internally.
- Do not set maxTokens to the model theoretical ceiling — Use a conservative default (32768); override per-request when you actually need extended output.
- Context window has two resolution layers in OpenClaw — Model definition alone is not enough; add the agent-level override too.
- Use a stable fallback — While debugging a new model, keep
deepseek-chatordeepseek-v4-flashas fallback so other channels stay responsive.
背景
如果你正在使用 OpenClaw，并尝试升级到 DeepSeek 最新模型，可能会遇到一个令人困惑的现象：所有通道突然停止回应，网关日志里不断刷出 FailoverError: LLM request failed: provider rejected the request schema or tool payload。本文记录了我们遇到的所有问题及其解决过程。
OpenClaw 网关原先配置了两个 DeepSeek 模型：
deepseek-chat— 标准对话模型deepseek-reasoner— 推理/思考模型
2026 年 4 月，DeepSeek 发布了 V4 版本，带来了新一代模型 deepseek-v4-pro 和 deepseek-v4-flash。原有的两个旧模型名将于 2026-07-24 废弃。
问题一：HTTP 400 — Provider Rejected the Request Schema or Tool Payload
在 OpenClaw 配置文件中注册 deepseek-v4-pro 并设置 reasoning: true 后，所有通道（Telegram、Discord、企业微信）发来的消息都触发 400 错误：
LLM request failed: provider rejected the request schema or tool payload.
reason: format, status: 400根本原因
当 OpenClaw 设置 reasoning: true 时，网关会在 API 请求中附加 thinking/reasoning 参数。与此同时，OpenClaw 还会在请求中附带 tool call 的函数定义。两者叠加后，DeepSeek V4 Pro 的 API 拒绝了该请求格式。DeepSeek 文档指出：从 V3.2 开始才支持 thinking 模式下的工具调用，但参数格式有严格要求。OpenClaw 的 reasoning: true 所发送的格式与 tool definitions 并存时不被 V4 Pro 接受。
解决方案
将 deepseek-v4-pro 的 reasoning 设为 false。模型本身默认仍会进行内部推理——我们只是不在 API 层面显式指定，从而避免格式冲突：
{
"id": "deepseek-v4-pro",
"api": "openai-completions",
"reasoning": false,
"contextWindow": 1000000,
"maxTokens": 32768
}问题二：maxTokens 设置过大
初始配置中 maxTokens 被设为 393216（即 DeepSeek V4 Pro 理论上限 384K），导致 API 直接拒绝请求。
解决方案
将 maxTokens 改为 32768。如确实需要超长输出，应在具体请求时按需覆盖，而不是写在模型注册配置里。
问题三：上下文窗口显示 200K 而非 1M
在模型定义中设置 contextWindow: 1000000 后，OpenClaw TUI 仍然显示 200k。
根本原因
OpenClaw 的上下文窗口大小在两个层级分别解析：模型定义层 和 agents.defaults.models 的 agent 级条目。由于 agent 级条目为空对象 {}，实际取值回退到了 200K 默认值，而非模型定义里的 1M。
解决方案
在 agents.defaults.models 中为 v4-pro 添加显式覆盖：
"agents": {
"defaults": {
"models": {
"deepseek/deepseek-v4-pro": {
"contextWindow": 1000000
}
}
}
}配置变更汇总
| 参数 | 修改前 | 修改后 |
|---|---|---|
reasoning |
true | false |
maxTokens |
393216 | 32768 |
contextWindow（模型定义） |
1000000 | 1000000 ✓ |
contextWindow（agent 层覆盖） |
缺失 | 1000000 |
| 主模型 | deepseek/deepseek-reasoner | deepseek/deepseek-v4-pro |
| 备用模型 | deepseek/deepseek-reasoner | deepseek/deepseek-chat |
经验总结
- reasoning: true 与 tool calls 会产生冲突 — 如果网关需要发送工具定义，请关闭 reasoning 标志，让模型默认行为自行处理推理。
- 不要把 maxTokens 设为模型理论上限 — 注册配置中保守地使用 32768；真正需要超长输出时再按需覆盖。
- OpenClaw 的 context window 有两个解析层 — 仅在模型定义中设置是不够的，还需要在 agent 层添加覆盖。
- 保留一个稳定的 fallback 模型 — 调试新模型期间，保持
deepseek-chat或deepseek-v4-flash作为备用，确保其他通道不受影响。
了解 ~/jintaoblog/朝夕见闻志⚡️ 的更多信息
订阅后即可通过电子邮件收到最新文章。