Cerebras (OpenAI-compatible): every multi-turn request fails with '400 status code (no body)' — reasoning_content rejected on input

[mdm-sfo]

Qwen Code + Cerebras: every multi-turn request fails with 400 status code (no body)

Summary

When using a Cerebras-hosted model (any model) via the OpenAI-compatible provider, the first turn succeeds but every subsequent turn in the session fails with 400 status code (no body). The CLI's own background subagents (e.g. managed-auto-memory-extractor) fail the same way, since they replay session history.

Environment

• qwen-code 0.23.0 (@qwen-code/qwen-code npm package)
• Provider config: OpenAI-compatible, baseUrl: https://api.cerebras.ai/v1, model qwen-3.8-27b (also reproduced with gpt-oss-120b)
• Linux x64

Root cause

The Gemini→OpenAI history converter writes the model's thinking back into request history as an assistant.reasoning_content field:

// packages/core/src/core/openaiContentGenerator/provider/... (converter)
const reasoningContent = reasoningParts.join("");
if (reasoningContent) {
  assistantMessage.reasoning_content = reasoningContent;
}

Cerebras returns thinking in a field named reasoning (and accepts reasoning back on input), but rejects reasoning_content on input with HTTP 400 — for every model, not just thinking ones:

{"message": "messages.2.assistant.reasoning_content: property 'messages.2.assistant.reasoning_content' is unsupported",
 "type": "invalid_request_error", "param": "validation_error", "code": "wrong_api_format"}

The CLI surfaces this as 400 status code (no body), which hides the actual validation message.

Minimal reproduction

# Turn 1 — succeeds
curl https://api.cerebras.ai/v1/chat/completions \
  -H "Authorization: Bearer $CEREBRAS_KEY" -H "Content-Type: application/json" \
  -d '{"model":"qwen-3.8-27b","messages":[{"role":"user","content":"test"}]}'

# Turn 2 — 400, exactly what qwen-code sends on the follow-up
curl https://api.cerebras.ai/v1/chat/completions \
  -H "Authorization: Bearer $CEREBRAS_KEY" -H "Content-Type: application/json" \
  -d '{"model":"qwen-3.8-27b","messages":[
        {"role":"user","content":"test"},
        {"role":"assistant","content":"Hey! How can I help?","reasoning_content":"The user said test."},
        {"role":"user","content":"follow-up question"}
      ]}'
# → 400 wrong_api_format: messages.2.assistant.reasoning_content unsupported

Note: substituting the field name reasoning (Cerebras's own response field) is accepted on input; only reasoning_content is rejected.

Proposed fix

The codebase already solves this exact problem for Mistral: MistralOpenAICompatibleProvider.buildRequest() maps history through stripReasoningContent(), which deletes reasoning_content from outgoing messages. Cerebras needs the identical treatment — Cerebras endpoints currently fall through to DefaultOpenAICompatibleProvider, which sends the field verbatim.

Add a Cerebras provider (or extend the strip heuristic), following the existing Mistral pattern:

// provider/cerebras.ts
const CEREBRAS_API_HOST = "api.cerebras.ai";

function isCerebrasProvider(config): boolean {
  try {
    const hostname = new URL(config?.baseUrl ?? "").hostname.toLowerCase();
    return hostname === CEREBRAS_API_HOST || hostname.endsWith(`.${CEREBRAS_API_HOST}`);
  } catch { return false; }
}

class CerebrasOpenAICompatibleProvider extends DefaultOpenAICompatibleProvider {
  buildRequest(request, userPromptId) {
    const baseRequest = super.buildRequest(request, userPromptId);
    return { ...baseRequest, messages: baseRequest.messages.map(stripReasoningContent) };
  }
}

// in determineProvider():
if (isCerebrasProvider(config)) {
  return new CerebrasOpenAICompatibleProvider(contentGeneratorConfig, cliConfig);
}

(stripReasoningContent would need to be exported from the Mistral module or moved to a shared util.)

Trade-off to note: stripping thinking from history means the model no longer sees its own prior reasoning across turns. That is already the accepted behavior for Mistral, and is strictly better than every multi-turn request failing. Cerebras accepts reasoning (no _content) on input, so renaming rather than deleting would also work — but deletion matches the existing pattern and is provider-safe.

Verified workaround

Locally patching the installed chunk (~/.local/lib/qwen-code/lib/chunks/chunk-F33GFWPR.js) with the detection + strip above fixes multi-turn sessions against Cerebras — confirmed by resuming a previously failing session and completing follow-up turns with no 400s.

Secondary issue (worth a separate ticket?)

EnhancedErrorHandler reports Cerebras 400s as 400 status code (no body) even though the response does have a JSON body with a precise validation message. Surfacing error.message from the body would have made this diagnosable in seconds instead of requiring session-telemetry archaeology.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Triage

• Type: bug — root cause confirmed by source inspection, reproduction is clear and specific
• Labels: type/bug, category/core, scope/content-generation, priority/P1
• Next: ready for a fix PR — follow the existing Mistral strip pattern, keeping the strip at the outbound request boundary rather than in the converter

Root cause verified

Checked against main @ 74fe3a65. Your analysis holds on every point:

• converter.ts writes assistantMessage.reasoning_content on any assistant turn that carried reasoning parts — matches the code you quoted.
• determineProvider() routes DashScope → DeepSeek → Zai → MiMo → ModelScope → MiniMax → Mistral → else DefaultOpenAICompatibleProvider. There is no Cerebras branch (cerebras has zero matches under packages/), so api.cerebras.ai falls through to the default provider exactly as you describe.
• stripReasoningContent() in provider/mistral.ts already does what you propose, and you are right that it is module-local and would need exporting or moving to a shared util. provider/utils.ts is already that shared home — it currently holds ensureReasoningContentOnAssistantMessage, the opposite concern.

One detail worth adding, because it explains why the default provider's existing reasoning handling does not save you: DefaultOpenAICompatibleProvider.buildRequest() mirrors reasoning_content → reasoning only for models matching isQwen3Model() (model.includes('qwen3')). qwen-3.8-27b does not contain that substring (it is qwen-3), so the mirror never fires — and even when it does fire it adds reasoning while keeping reasoning_content, so the rejected field still ships.

Constraint for whoever fixes this

The codebase carries both requirements at once, so this has to stay per-provider:

• DeepSeek / Qwen thinking-mode endpoints require reasoning_content replayed on every prior assistant turn (ensureReasoningContentOnAssistantMessage, the model-switch history comment in config.ts, closed Deepseek v4: API Error: 400 The reasoning_content in the thinking mode must be passed back to the API #3658 / BUG: DeepSeek API 400 error — reasoning_content in thinking mode must be passed back #3579 / Deepseek V4 API Error: 400 The reasoning_content in the thinking mode must be passed back to the API #3695 / DeepSeek V4 Pro + thinking mode: 400 error — reasoning_content not relayed by CLI (v0.15.5) #3750).
• Mistral — and per this report Cerebras — reject it with a 400.

A global strip, or a strip inside the converter, would regress the DeepSeek family. Keep it in a provider subclass at the request boundary. Your read ("deletion matches the existing pattern and is provider-safe") is correct.

On rename-vs-delete: you note Cerebras accepts reasoning on input, which would preserve cross-turn thinking — the outcome #4285 wanted for vLLM, and what produced the qwen3 mirroring. Delete is simpler and matches Mistral; rename keeps more context. Both are defensible; worth stating the choice explicitly in the PR.

Broader question for maintainers (not a gate decision): reasoning_content is a vendor extension, yet the converter emits it unconditionally and the default — i.e. generic, unknown-endpoint — provider passes it through. Mistral needed a subclass to opt out, Cerebras now needs one too, and the next strict endpoint will need a third. Is "emit by default, patch per provider" still the shape we want, or should the default stay spec-clean and only known-thinking providers opt in? Fixing this issue either way is fine; the question is whether we keep adding provider #N.

Secondary issue (error message)

Agreed, and it belongs in its own ticket. The literal 400 status code (no body) appears nowhere in this repo, so it originates in the openai SDK — we could not verify the SDK's body handling here (node_modules is not installed in the triage environment). The repo side is verifiable and supports your complaint: EnhancedErrorHandler.buildErrorMessage() returns the SDK's error.message, which is what reaches you, while buildDiagnostics() already extracts the provider's real message as providerMessage via getRateLimitErrorDetails() — and hands it only to the debug logger. The precise validation text is recovered and then logged at debug level instead of surfaced. Folding providerMessage into the user-visible message when present looks like the fix.

Not a duplicate

• API Error: 400 status code (no body) - Cerebras #646 (closed 2025-10-01, status/need-information, CLI v0.0.12) — same symptom string and provider, but never diagnosed and closed for lack of information.
• Fails to connect to Cerebras OpenAI endpoint #179 (closed 2025-08-02) — config error: OPENAI_BASE_URL included /chat/completions, giving a 404.
• Outgoing requests send reasoning_content instead of reasoning — vLLM ≥ 0.20 strips the field, leaving prior <think> blocks empty #4285 (closed 2026-05-19) — closest prior art: same field, opposite failure mode (vLLM silently discards reasoning_content; Cerebras hard-400s on it).

Reproduction status

Not executed. This was an unattended CI triage run, where the gate is static, and your curl repro needs a Cerebras key we do not hold. What is verified is the client half: the code path provably emits reasoning_content to a Cerebras baseUrl. The Cerebras-side rejection rests on your curl transcript, which is specific and quotes a real validation payload.

中文说明

• 类型：bug —— 根因已通过源码核对确认，复现步骤清晰具体
• 标签：type/bug、category/core、scope/content-generation、priority/P1
• 下一步：可以直接提修复 PR —— 参照现有 Mistral 的 strip 模式，把 strip 放在出站请求边界，不要改 converter

根因已核实（对照 main @ 74fe3a65，你的分析每一点都成立）：

• converter.ts 在任何带 reasoning part 的 assistant 轮次上写入 assistantMessage.reasoning_content，与你引用的代码一致。
• determineProvider() 的路由顺序是 DashScope → DeepSeek → Zai → MiMo → ModelScope → MiniMax → Mistral → 其余走 DefaultOpenAICompatibleProvider；不存在 Cerebras 分支（packages/ 下 cerebras 零匹配），所以 api.cerebras.ai 如你所述落到默认 provider。
• provider/mistral.ts 里的 stripReasoningContent() 正是你提议的做法；你说它没有导出也是对的。provider/utils.ts 已经是共享工具的位置——它目前放的是相反需求的 ensureReasoningContentOnAssistantMessage。

补充一个细节，可以解释为什么默认 provider 现有的 reasoning 处理救不了这个场景：DefaultOpenAICompatibleProvider.buildRequest() 只对匹配 isQwen3Model()（即 model.includes('qwen3')）的模型做 reasoning_content → reasoning 镜像。qwen-3.8-27b 不含该子串（是 qwen-3），所以镜像根本不触发；即便触发，它也只是新增 reasoning 而保留 reasoning_content，被拒的字段照样发出去。

修复时需要遵守的约束：代码库同时背负两种相反的要求，因此必须按 provider 分别处理——

• DeepSeek / Qwen 思考模式端点要求每个历史 assistant 轮次回传 reasoning_content（见 ensureReasoningContentOnAssistantMessage、config.ts 中模型切换保留历史的注释，以及已关闭的 Deepseek v4: API Error: 400 The reasoning_content in the thinking mode must be passed back to the API #3658 / BUG: DeepSeek API 400 error — reasoning_content in thinking mode must be passed back #3579 / Deepseek V4 API Error: 400 The reasoning_content in the thinking mode must be passed back to the API #3695 / DeepSeek V4 Pro + thinking mode: 400 error — reasoning_content not relayed by CLI (v0.15.5) #3750）。
• Mistral——以及按本 issue 的 Cerebras——则用 400 拒绝该字段。

所以全局 strip 或在 converter 里 strip 会让 DeepSeek 系列回归，请保留在 provider 子类的请求边界上。你对此的判断（"deletion matches the existing pattern and is provider-safe"）是正确的。

关于"改名还是删除"：你提到 Cerebras 入参接受 reasoning，改名可以保留跨轮思考内容——这正是 #4285 对 vLLM 想要的结果，也是 qwen3 镜像逻辑的由来。删除更简单且与 Mistral 一致，改名保留更多上下文。两者都说得通，建议在 PR 里明确写出取舍理由。

给 maintainer 的更大范围问题（不是准入判断）：reasoning_content 是厂商扩展字段，但 converter 无条件写入，而默认（即通用、未知端点）provider 原样透传。Mistral 需要一个子类才能退出，现在 Cerebras 也需要，下一个严格校验的端点还会需要第三个。"默认发送、按 provider 打补丁"是否还是我们想要的形态？还是应该让默认路径保持规范干净，只让已知需要思考回传的 provider 主动加入？本 issue 两种做法都可以修，问题在于我们是否要一直增加第 N 个 provider。

次要问题（错误信息）：同意，应该单独开一个 issue。400 status code (no body) 这个字面量在本仓库中完全不存在，因此来自 openai SDK——本次无法核实 SDK 的 body 处理（triage 环境未安装 node_modules）。仓库这一侧是可以核实的，也支持你的判断：EnhancedErrorHandler.buildErrorMessage() 返回的是 SDK 的 error.message（也就是你看到的那句），而 buildDiagnostics() 其实已经通过 getRateLimitErrorDetails() 把 provider 的真实信息取成了 providerMessage——却只交给了 debug logger。也就是说，精确的校验信息已经被拿到，但只记在 debug 日志里而没有呈现给用户。看起来修复方向就是：当 providerMessage 存在时把它并入用户可见的错误信息。

不是重复 issue：

• API Error: 400 status code (no body) - Cerebras #646（2025-10-01 关闭，status/need-information，CLI v0.0.12）——症状字符串和 provider 相同，但从未定位到根因，因缺少信息被关闭。
• Fails to connect to Cerebras OpenAI endpoint #179（2025-08-02 关闭）——配置错误：OPENAI_BASE_URL 带了 /chat/completions，导致 404。
• Outgoing requests send reasoning_content instead of reasoning — vLLM ≥ 0.20 strips the field, leaving prior <think> blocks empty #4285（2026-05-19 关闭）——最接近的先例：同一个字段，相反的失败方式（vLLM 静默丢弃 reasoning_content，Cerebras 直接 400）。

复现状态：未执行。本次是无人值守的 CI triage，评审为静态分析，且你的 curl 复现需要我们没有的 Cerebras key。已核实的是客户端这一半：代码路径确实会把 reasoning_content 发往 Cerebras 的 baseUrl。Cerebras 侧的拒绝行为依据的是你的 curl 记录——内容具体，并引用了真实的校验报错。

--- Qwen Code

[yiliang114]

Reproduced against main @ 74fe3a65 with a local stand-in for Cerebras — an OpenAI-compatible endpoint that rejects any request body containing reasoning_content, returning the same validation payload as api.cerebras.ai.

Evidence:

• determineProvider() has no Cerebras branch, so https://api.cerebras.ai/v1 falls through to DefaultOpenAICompatibleProvider, whose buildRequest ships reasoning_content verbatim. The qwen3 reasoning mirror never fires for qwen-3.8-27b (substring is qwen3), and even when it does fire it adds reasoning without removing reasoning_content.
• Driving the real path end to end (session history with a thought part → OpenAIContentConverter → provider boundary → wire), the follow-up turn fails with exactly 400 status code (no body); the strict endpoint's 400 body confirms messages.1.assistant.reasoning_content ... is unsupported as the trigger.

Fix direction: same shape as the existing Mistral handling (provider/mistral.ts) — a hostname-detected Cerebras provider subclass that strips reasoning_content at the outbound request boundary only. Session history stays intact, and DeepSeek/Qwen thinking-mode replay (which requires the field) is untouched. PR incoming.