Cloud: mistral-large-4 rejects developer-role messages with HTTP 400

快速结论：调用 Ollama Cloud 的 /v1/responses（以及 /v1/chat/completions）接口时，如果消息里带有 role: "developer"，mistral-large-4 会返回 HTTP 400；把该角色改成 system 后请求立即成功。问题出在云端模型对 developer 角色的支持上，因此优先排查消息角色，而不是本地环境。

适用环境：直接请求 Ollama Cloud API（https://ollama.com/v1/responses），不经过本地 Ollama 服务；原报告客户端为桌面应用内置的 Codex CLI 0.162.0-alpha.17.2，并用 Python 标准 HTTP 客户端独立复现过。Issue 未提供操作系统、Python 版本、CUDA、显卡或依赖版本信息。

最快修复方案：该问题已由维护者修复，上报者回测确认解决。最快处理是重新发起原请求验证；若仍报 400，可优先尝试把 developer 角色的消息改为 system。

注意事项：把角色改成 system 只是 Issue 中验证过的绕行方式，并不等于修复了根因；Issue 只覆盖 mistral-large-4 等少数 Cloud 模型，其他模型的 developer 角色行为未逐一确认。此外，glm-5.3-flash 使用 developer 角色时曾返回 UNKNOWN，说明指令内容是否被正确读取还涉及模型侧行为，建议用带唯一标记的自检请求确认。

问题场景

用户通过 HTTP 直接调用 Ollama Cloud 的 /v1/responses 接口，选择模型 mistral-large-4，并在 input 里放入一条 role: "developer" 的指令消息，再附带一条 user 消息要求模型返回该指令中的诊断标记。使用 Codex 这类会发送 developer 角色指令的客户端时同样触发。Issue 还提到，mistral-large-4 通过 /v1/chat/completions 同样拒绝 developer 角色。

报错原文

HTTP 400

body.messages.0: Input tag 'developer' found using 'role'
does not match any of the expected tags:
<Roles.system: 'system'>, <Roles.user: 'user'>,
<Roles.assistant: 'assistant'>, <Roles.tool: 'tool'>

原因分析

报错明确指出，模型请求的 role 字段只接受 system、user、assistant、tool 四种取值，developer 不在允许列表中，因此请求在进入模型前就被拒绝。也就是说，问题出在 Cloud 侧对 mistral-large-4 角色的映射或校验上，而不是用户的本地环境。Issue 中横向对比显示：deepseek-v4.1-flash 接受 developer 角色并返回标记，glm-5.3-flash 接受 developer 角色但返回 UNKNOWN，glm-5.3-flash 用 system 角色则能返回标记。后者提示部分模型的指令内容可能未被正确读取，但这只是观察，Issue 未确认根本原因。

环境排查

确认请求地址是 https://ollama.com/v1/responses 或 /v1/chat/completions，不要与本地 Ollama 服务的地址混淆。
确认请求头带有有效的 Authorization: Bearer $OLLAMA_API_KEY 和 Content-Type: application/json。
确认请求体中的 model 字段确实是 mistral-large-4。
逐条检查 input（或 chat 接口的 messages）中的 role 字段，确认是否存在 developer。
检查调用方客户端（如 Codex）是否自动把系统指令写成 developer 角色。
Issue 未涉及本地 Python、CUDA、PyTorch、显卡或节点版本，若为纯 API 调用，这些项通常不是排查重点。

解决步骤

先直接用 Issue 中的最小 curl 请求复现，确认返回是否为上述 HTTP 400，以排除客户端封装层的问题。
将 input 中第一条消息的 "role": "developer" 改为 "role": "system"，内容保持不变，重新请求。
若改角色后返回 HTTP 200 并带回诊断标记（如 MAPLE-6274），说明问题确属 developer 角色不被该模型接受。
该 Issue 已关闭，维护者表示已修复，上报者也确认问题解决。因此更新后应先原样发送 developer 角色请求进行重测，无需再保留改角色的绕行。
如果客户端（如 Codex）仍无法自定义角色，可先检查客户端配置或版本中是否有将系统指令映射为 system 的选项；Issue 未给出具体配置项，以上仅为可优先尝试的方向。

验证方法

保持模型为 mistral-large-4，发送包含 role: "developer"、内容为唯一诊断标记的请求，预期返回 HTTP 200，且模型回复中包含该标记，而不是 UNKNOWN。再分别用 system 角色和 Codex 客户端各测一次，确认两种角色和客户端路径都不再报 400。若仍出现 400，记录完整响应体中的 role 校验信息用于进一步排查。