Repository navigation
Bug: OpenAI provider fails with GPT-5.4 after reasoning/todowrite in v1.15.7 (OpenAI Responses assistant messages only support text and tool-call content) #28750
Description
Summary
After upgrading to opencode v1.15.7, multi-step agent runs fail when using the openai provider with gpt-5.4.
The failure happens after a reasoning step and a todowrite tool call, on the next model request:
ProviderShared.request:
OpenAI Responses assistant messages only support text and tool-call content for nowThe same workflow works with the GitHub Copilot provider using the same model family, which suggests this is specific to OpenCode's OpenAI provider / Responses serialization path.
Environment
- OpenCode:
1.15.7 - OS:
macOS(Apple Silicon M2) - Provider:
openai - Model:
gpt-5.4 - MCP:
context7,tavily - LSP: disabled
- Formatters: disabled
Reproduction
Prompt example:
检查服务器所有连接方式Equivalent English prompt:
Check all available server connection methodsObserved flow:
- reasoning starts
- reasoning ends
todowriteruns successfully- next loop begins
- next OpenAI request fails immediately
Relevant logs
From my local log 2026-05-22T011848.log:
- OpenCode version:
version=1.15.7
- Native OpenAI runtime selected:
llm.runtime=native llm.provider=openai llm.model=gpt-5.4
- Reasoning lifecycle:
session.next.reasoning.startedsession.next.reasoning.ended
- Todo tool executed successfully:
service=tool.registry status=started todowriteservice=tool.registry status=completed duration=0 todowrite
- Next OpenAI request starts:
service=llm providerID=openai modelID=gpt-5.4 ... agent=explainer mode=primary stream
- Immediate failure:
ProviderShared.request: OpenAI Responses assistant messages only support text and tool-call content for now
Relevant excerpt:
INFO service=default version=1.15.7
INFO service=default llm.runtime=native llm.provider=openai llm.model=gpt-5.4 llm runtime selected
INFO service=bus type=session.next.reasoning.started publishing
INFO service=bus type=session.next.reasoning.ended publishing
INFO service=tool.registry status=started todowrite
INFO service=tool.registry status=completed duration=0 todowrite
INFO service=llm providerID=openai modelID=gpt-5.4 session.id=... agent=explainer mode=primary stream
ERROR service=session.processor session.id=... messageID=... error=ProviderShared.request: OpenAI Responses assistant messages only support text and tool-call content for nowExpected behavior
The session should continue normally after reasoning and todowrite, and proceed to the next agent loop.
Actual behavior
The session aborts on the next OpenAI request.
Provider comparison
openai+gpt-5.4: failsgithub-copilot+gpt-5.4: works
This makes it look specific to the OpenAI Responses route / message-history replay rather than the model itself.
Regression note
This started after upgrading to v1.15.7. I did not encounter this before the upgrade.
Suspected cause
The error strongly suggests that, on the next loop, OpenCode is replaying an assistant message containing a content part that the OpenAI Responses route in v1.15.7 does not support.
Given the timing, the likely candidates are:
- reasoning replay
todowrite/ tool-only assistant turn replay- continuation metadata serialization
- explainer-agent history formatting
Question
Was there any change around v1.15.7 in one of these areas?
- OpenAI Responses API request construction
- reasoning replay / continuation state
todowriteserialization- explainer agent history formatting
- assistant tool/history lowering
If helpful, I can provide the full log file and help test a patch or nightly build.
Activity
[-]Bug: OpenAI provider fails with GPT-5.4 after reasoning/todowrite in v1.15.7 ()[/-][+]Bug: OpenAI provider fails with GPT-5.4 after reasoning/todowrite in v1.15.7 (`OpenAI Responses assistant messages only support text and tool-call content`)[/+]github-actions commentedon May 22, 2026
This issue might be a duplicate of existing issues. Please check:
tool_callsfield, breaking OpenAI-compatible providers #24090: Assistant messages in history replay are missingtool_callsfield, breaking OpenAI-compatible providers — same general area (assistant message history replay to OpenAI being malformed), though that issue was on v1.14.22 via Chat Completions; your issue is on v1.15.7 via the Responses API. They may share the same underlying root cause.If you have already checked these and confirmed this is distinct, feel free to note that and a maintainer will review.
lightrao commentedon May 22, 2026
I checked #24090 and it looks related but distinct.
My issue appears to be on the OpenAI
Responses/ native runtime path inv1.15.7, while #24090 is about missingtool_callsduring history replay on an OpenAI-compatible / Chat Completions path inv1.14.22.In my case, the failure is specifically triggered after:
todowriterunsSo this looks like the same general assistant-history replay area, but likely a distinct regression on the Responses route rather than the exact
tool_callsomission described in #24090.i7N3 commentedon May 22, 2026
Confirming the issue, it started appearing after updating to 1.15.7.
You can roll back for now until it’s fixed:
curl -fsSL https://opencode.ai/install | bash -s -- --version 1.15.6lightrao commentedon May 22, 2026
I checked the git history around
v1.15.6 -> v1.15.7, and this does look like a likelyv1.15.7regression.Relevant changes included:
Refactor LLM route-first provider API(41f6daf96)fix(llm): restore OpenAI reasoning streams(16fb6dac8)refactor(opencode): extract session LLM request prep(fb9d69ef6)From the code diff,
v1.15.7started handling OpenAI Responses reasoning stream events, but the assistant-message replay/lowering path inpackages/llm/src/protocols/openai-responses.tsstill only accepted assistant content typestextandtool-call.That matches the runtime error exactly:
Also, later work on
devappears to address this area directly:fix(llm): preserve native continuation metadata(61390dbb4)So this looks less like an old pre-existing bug and more like a regression introduced during the
v1.15.7OpenAI Responses/native-runtime changes.rekram1-node commentedon May 22, 2026
This will be fixed in next release but for now I recommend u stop using the experimental code paths, try this:
export OPENCODE_EXPERIMENTAL=0
ZanzyTHEbar commentedon May 22, 2026
I have the same issue with all Responses API endpoints - v1.15.7
When using models that route through the OpenAI Responses API (e.g. gpt-5.5 with provider openai), opencode fails with:
I think that this happens because internal opencode scaffolding parts (reasoning, step-start, step-finish) present in assistant role messages are not being stripped before the request is sent to the Responses endpoint.
Reproduction
Use a model that triggers the Responses path (e.g. openai/gpt-5.5)
Run a long agentic session with many tool calls and internal reasoning steps (common in tech-lead or complex multi-step tasks)
After some time, attempting to continue the session triggers the above error on the next assistant turn.
The session works fine with models that use the traditional Chat Completions path.
Related
Similar message normalization work was done for Anthropic reasoning blocks in PR #23755 (src/provider/transform.ts).
Existing user demand for a Chat Completions fallback: #7793.
Expected behavior
Internal opencode parts (reasoning, step-start, step-finish, etc.) should be filtered out for any provider/API path that only accepts text + tool-call content in assistant messages, with fallback to Chat Completions API if Responses throws an error.
OpenCode version
1.15.7
Steps to reproduce
Use a model that triggers the Responses path (e.g. openai/gpt-5.5)
Run a long agentic session with many tool calls and internal reasoning steps (common in tech-lead or complex multi-step tasks)
After some time, attempting to continue the session triggers the above error on the next assistant turn.
The session works fine with models that use the traditional Chat Completions path.