GPT-5.4 via custom @ai-sdk/openai LiteLLM provider crashes with activeReasoningPart.summaryParts, while direct /v1/responses succeeds #21346

Summary

OpenCode fails to run GPT-5.x models through a custom @ai-sdk/openai provider backed by LiteLLM, even though LiteLLM /v1/responses works correctly for the same model.

Direct LiteLLM calls succeed.
OpenCode crashes while parsing the response.

Environment

• OpenCode version: 0.0.0-beta-202604071044
• LiteLLM proxy exposing GitHub Copilot-backed models
• Model tested: gpt-5.4
• Custom provider npm SDK: @ai-sdk/openai
• Reproduced inside a Paperclip container, but the failure is in OpenCode itself

OpenCode config

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "litellm-responses": {
      "npm": "@ai-sdk/openai",
      "name": "LiteLLM via Copilot (Responses)",
      "options": {
        "baseURL": "http://127.0.0.1:4000/v1",
        "apiKey": "test-key"
      },
      "models": {
        "gpt-5.4": {
          "name": "GPT-5.4 via Copilot (Responses)"
        }
      }
    }
  },
  "model": "litellm-responses/gpt-5.4"
}

Direct LiteLLM test

This succeeds:

curl -s -X POST http://127.0.0.1:4000/v1/responses \
  -H "Authorization: Bearer test-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4",
    "input": "Reply with exactly: ok"
  }'

The response completes successfully and returns ok.

These also succeed:

• reasoning.effort = none
• reasoning.effort = low
• reasoning.effort = medium
• reasoning.effort = high

Example request:

curl -s -X POST http://127.0.0.1:4000/v1/responses \
  -H "Authorization: Bearer test-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.4",
    "input": "Reply with exactly: ok",
    "reasoning": { "effort": "low" }
  }'

OpenCode repro

Run:

opencode run --model litellm-responses/gpt-5.4 "Reply with exactly: ok"

Observed behavior

OpenCode crashes with:

Error: undefined is not an object (evaluating 'activeReasoningPart.summaryParts')

If reasoning-related options are forced in config, the failure can also become:

Error: "text part ... not found"

Control case

In the same exact setup, a non-GPT model works.

This custom provider works fine through OpenCode:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "litellm": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LiteLLM via Copilot",
      "options": {
        "baseURL": "http://127.0.0.1:4000/v1",
        "apiKey": "test-key"
      },
      "models": {
        "claude-sonnet-4.6": {
          "name": "Claude Sonnet 4.6 via Copilot"
        }
      }
    }
  }
}

And this succeeds:

opencode run --model litellm/claude-sonnet-4.6 "Reply with exactly: ok"

Result:

• OpenCode returns ok
• no parser crash
• same LiteLLM proxy
• same Copilot-backed setup
• same Paperclip/container environment

Why this matters

This suggests the problem is not:

• general connectivity to LiteLLM
• general custom provider support
• general GitHub Copilot proxying
• general OpenCode execution through this setup

It appears specific to GPT-5 responses handling/parsing in OpenCode.

Expected behavior

If LiteLLM /v1/responses succeeds for the model, OpenCode should return the assistant output normally instead of crashing during response parsing.

Related

This seems adjacent to existing issues in the GPT-5/custom-provider area:

• #9628
• #21237
• #18882
• #20815