[BUG] OpenAI Responses: assistant messages sent as {role:"assistant", content:[{type:"output_text"}]} rejected by strict OpenAI-compatible servers

[j34ni]

Summary

When a conversation history contains an assistant text message and opencode sends it
to an OpenAI Responses (/responses) endpoint, the request body uses:

{"role": "assistant", "content": [{"type": "output_text", "text": "..."}]}

This shape is not valid per OpenAI's Responses input schema. Real api.openai.com
tolerates it, but strict OpenAI-compatible servers that validate with the official
OpenAI SDK types (e.g. a self-hosted Qwen server exposing /v1/responses) reject it
with a 422/400 validation error, so switching a session to such a model fails.

Environment

• opencode 1.18.18 (Snap, stable)
• Default runtime (AI SDK path), @ai-sdk/openai 3.0.84
• Server: self-hosted OpenAI-compatible /v1/responses endpoint (validates with
  openai Python SDK pydantic types)

Repro

1. Configure a custom provider/model pointing at an OpenAI-compatible /responses
   server.
2. Switch an existing session to that model so the history (including prior
   assistant text) is resent.
3. The request fails with a pydantic ValidationError on the input array, e.g.:

loc: ('body', 'input', 'list[union[EasyInputMessageParam, Message, ResponseOutputMessageParam, ...]]', 2, 'ResponseFunctionToolCallParam', 'call_id')
msg: 'Field required'
input: {'role': 'assistant', 'content': [{'type': 'output_text', 'text': '...'}]}

Root cause

@ai-sdk/openai builds assistant input items as
{ role: "assistant", content: [{ type: "output_text", text }], id }
(convertToOpenAIResponsesMessages, dist/index.js ~3127).

Per the official OpenAI schema (openai-python types):

• EasyInputMessageParam allows role: "assistant" but content must be
  str | list[input_text | input_image | input_file] — output_text is not
  a valid easy-input content part.
• output_text is only valid inside a full output item
  { type: "message", role: "assistant", id, status, content: [...] }
  (ResponseOutputMessageParam, where type/id/status are required).

OpenAI's own API is lenient and accepts the non-conformant shape, which is why
this has gone unnoticed. The same bug also exists in the native llm protocol
(packages/llm/src/protocols/openai-responses.ts, lowerMessages).

Proposed fix

Emit assistant text as an easy-input message with input_text parts:

{"role": "assistant", "content": [{"type": "input_text", "text": "..."}]}

or, when an item id is available, the complete
{"type": "message", "role": "assistant", "id", "status": "completed", "content": [{"type": "output_text", "text": "..."}]}.

A local fix for the native protocol is ready and tests pass
(59 tests, packages/llm). The AI SDK path will additionally need a fix in
vercel/ai (or a bumped @ai-sdk/openai) to fix the released builds.

[github-actions]

This issue might be related to an existing issue. Please check:

• Zen /v1/responses drops array-format assistant content -> 400 "Invalid assistant message: content or tool_calls must be set" #41766: Zen /v1/responses drops array-format assistant content — same Responses API assistant message problem family (server-side Zen gateway bug vs. the client-side output_text type bug reported here). Different root causes and fix locations, but worth cross-referencing.

[j34ni]

Thanks for the cross-reference. Confirming the relationship:

#41766 (server-side, Zen gateway): the gateway rejects the standards-compliant full output item {"type": "message", "role": "assistant", "content": [{"type": "output_text"}]} — the sender is doing the right thing per the Responses schema.

#42613 (client-side, opencode): opencode sends the non-conformant easy-input {"role": "assistant", "content": [{"type": "output_text", "text": ...}]}, which the official openai SDK types only accept as input_text (or string) in that position. Real OpenAI tolerates it; strict OpenAI-compatible servers reject it.

Different root causes and fix locations (server gateway vs. client message lowering), but same assistant-content-array family. For completeness, the client-side fix (emit input_text) is in PR #42614.