OpenAI-compatible gpt-5.5 aborts mid-stream with unexpected EOF while same endpoint works in Codex #29187

Summary

[email protected] intermittently crashes or aborts with unexpected EOF when using a custom OpenAI-compatible provider with gpt-5.5. The same endpoint and same model work reliably in OpenAI Codex, and other models such as gpt-5.4 and DeepSeek work in opencode.

This looks like an opencode compatibility/regression issue in the OpenAI-compatible / Responses streaming or session handling path, not a provider outage.

Environment

• OS: Windows
• Install method: npm install -g opencode-ai
• OpenCode version: 1.15.10
• Provider package: @ai-sdk/openai-compatible
• Model: gpt-5.5
• Endpoint: custom OpenAI-compatible /v1 endpoint

Config shape

{
  "provider": {
    "mygpt": {
      "name": "mygpt",
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://<redacted>/v1"
      },
      "models": {
        "gpt-5.5": { "name": "gpt-5.5" },
        "gpt-5.4": { "name": "gpt-5.4" }
      }
    }
  },
  "model": "mygpt/gpt-5.5"
}

I also tried increasing provider timeouts:

"options": {
  "baseURL": "https://<redacted>/v1",
  "timeout": 900000,
  "chunkTimeout": 120000
}

That does not appear to address the underlying issue.

Behavior

1. Configure a custom OpenAI-compatible provider.
2. Set default model to mygpt/gpt-5.5.
3. Start a normal opencode session.
4. Ask for a response long enough to stream for a while.
5. opencode starts outputting normally, then aborts with unexpected EOF.

Expected:

• opencode should continue streaming to completion, as Codex does with the same endpoint and same model.

Actual:

• opencode aborts mid-output with unexpected EOF.

Why this seems opencode-specific

• Same model and same endpoint work in Codex for long-running usage.
• gpt-5.4 and DeepSeek work in opencode with the same general setup.
• This resembles existing opencode issues where Unexpected EOF is a secondary symptom after stricter parsing or session/SSE errors:
  • bug: Kimi/Moonshot provider crashes with 'undefined is not an object (evaluating $.annotations)' since v1.14.23 #26156
  • session_diff read/write race can trigger Unexpected EOF and local server exit #27843
  • Server becomes unresponsive after external client disconnects during SSE streaming #15149

Suspected cause

While investigating, one likely compatibility issue stood out in the Responses adapter:

packages/core/src/github-copilot/responses/openai-responses-language-model.ts

The non-streaming Responses schema currently treats output_text.annotations as required:

z.object({
  type: z.literal("output_text"),
  text: z.string(),
  logprobs: LOGPROBS_SCHEMA.nullish(),
  annotations: z.array(...)
})

Some OpenAI-compatible providers omit annotations when there are no annotations. Codex appears tolerant of this shape. If opencode routes gpt-5.x through a Responses-compatible path, a missing annotations field could trigger a validation failure that later surfaces as unexpected EOF.

A minimal compatibility fix may be to default omitted annotations to an empty array:

annotations: z.array(...).default([])

and keep the existing loop unchanged:

for (const annotation of contentPart.annotations) { ... }

A regression test could simulate a /responses JSON response containing:

{
  "type": "message",
  "role": "assistant",
  "id": "msg-1",
  "content": [
    { "type": "output_text", "text": "Hello", "logprobs": null }
  ]
}

and assert that doGenerate() returns the text instead of throwing.

Notes

I am not fully certain this is the only path causing the EOF, since the visible error is only unexpected EOF. But given the Codex comparison and the related issues above, the bug appears to be in opencode parsing/session handling rather than the model endpoint itself.