Stream parsing: "text part <uuid> not found" when provider is OpenAI-compatible proxy (LiteLLM) #25487

Description

opencode-ai@1.14.29 aborts mid-run with Error: "text part <uuid> not found" when the configured provider is an OpenAI-compatible proxy (LiteLLM v1.83.7-stable). The error fires on the second LLM round-trip, immediately after the first tool result is streamed back to the model.

The same proxy, queried via curl against /v1/chat/completions with stream:true, returns well-formed SSE, and the same proxy serves Aider, Codex, and mini-swe-agent without issue, so the misbehavior appears specific to opencode's stream-part-id reconciliation.

Provider config

~/.config/opencode/opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "openai": {
      "name": "LiteLLM proxy (compatible mode)",
      "options": {
        "baseURL": "http://host.containers.internal:6666/v1",
        "compatibility": "compatible"
      },
      "models": {
        "deepseek-chat": { "name": "DeepSeek via LiteLLM" }
      }
    }
  }
}

Expected behavior

The second round-trip completes and the agent applies edits, as it does against compatibility="default" upstream OpenAI traffic.

Hypotheses (educated guesses, not verified)

• The 1.14.x runtime tracks streamed text parts by id (introduced alongside Responses-API integration). When the upstream SSE shape is OpenAI Chat Completions–style (no id per delta) and is re-marshalled by @ai-sdk/openai in compatibility=compatible mode, the part id used at parse time may not match the id used at reassembly time.
• Alternatively, LiteLLM's SSE re-encoding may strip / rename a field opencode relies on. (We have not bisected this; happy to run any logging knobs you want.)

Cross-checks that DO work

• curl against /v1/chat/completions with stream:true returns well-formed SSE.
• Aider 0.86.2, Codex 0.125.0, and mini-swe-agent 2.2.1 all run successfully against the same proxy.

Adjacent SDK attempts

• Built-in @ai-sdk/openai with compatibility=compatible → fails with text part <uuid> not found
• @ai-sdk/openai-compatible@1.0.21 (provider override) → fails earlier with L.responses is not a function

Offered

• A minimal harness (≈30-line shell script) that spins up LiteLLM in a container, points opencode at it, and runs the prompt above.
• Full stderr + a packet capture / LITELLM_LOG=DEBUG trace if you can point at which framing detail is most useful.

Would either help triage?

Plugins

None

OpenCode version

1.14.29 (also reproduced on 1.14.17 and 1.14.31)

Steps to reproduce

1. Start LiteLLM v1.83.7-stable as OpenAI-compatible proxy on port 6666 routing deepseek-chat to DeepSeek's API.
2. Configure opencode at ~/.config/opencode/opencode.json with the provider config shown in Description (baseURL pointing at the LiteLLM proxy, compatibility="compatible").
3. In a fresh git clone with a single trivial Python file foo.py, run: opencode run --log-level ERROR --model openai/deepseek-chat with prompt "add a one-line module docstring to foo.py".
4. Observe: opencode initializes; reads provider config; resolves model.
5. First model round-trip succeeds. Model emits a Glob (or Read) tool call.
6. Tool result is streamed back.
7. Model begins second round-trip with text: "Let me find the file first."
8. Runtime aborts with: Error: "text part 972b8e3b-ac35-4b6f-a8a3-17302a05066b not found"
9. Process exits non-zero; no patch is written.

Logs: Error: "text part 972b8e3b-ac35-4b6f-a8a3-17302a05066b not found"
Additional context: Reproduced on opencode 1.14.17, 1.14.29, and 1.14.31. Same LiteLLM proxy works fine with Aider 0.86.2, Codex 0.125.0, mini-swe-agent 2.2.1.

Screenshot and/or share link

No response

Operating System

Linux (Debian-based container, Node 22-slim)

Terminal

No response