The following comment was made by an LLM, it may be inaccurate:

Potential Related PRs Found:

1. PR fix(opencode): run transformParams middleware unconditionally for all call types #19558 - "fix(opencode): run transformParams middleware unconditionally for all call types"

   • fix(opencode): run transformParams middleware unconditionally for all call types #19558
   • Why related: This PR addresses middleware execution issues with request transformation, similar to the LLM middleware fix in the current PR that handles v6 request param shapes (messages, input, prompt).

2. PR fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers #14973 - "fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers"

   • fix(core): prevent agent loop from stopping after tool calls with OpenAI-compatible providers #14973
   • Why related: This PR addresses the prompt loop exit issue after tool calls, which relates to the finish-reason mapping changes in the current PR.

Thanks for updating your PR! It now meets our contributing guidelines. 👍

Thanks for updating your PR! It now meets our contributing guidelines. 👍

I am keeping this branch up-to date with dev, would be thankful if this can be merged. engineers using Oracle Code Assist could not use opencode with Open AI models with responses API because of this bug. This is since version 1.3.4

@kkugot let me look over this

The LLM middleware in llm.ts targeted args.params.prompt for applying ProviderTransform.message(), but v6 Responses requests use messages or input. This meant message normalization was silently skipped on Responses requests.

Im not sure this is accurate

this pr has so many unrelated changes, i thought it'd be a 2 line pr?

Ready for your review

Alr thanks, ill double check this logic tmr I just need to make sure failure cases dont infinitely loop from this (its almost 1am here rn so too late for me to merge if im not 100% confident)

@rekram1-node no pressure here, if I can help with tesing this - let me know.

@rekram1-node I have checked with the recent code changes on dev and we are able to reproduce this issue only when any of the MCPs are enabled. With the proposed fix everything works correctly.

Hi @rekram1-node any idea when this will be merged? This is driving people out of OpenCode tool due to this issue.

/review

This was tested and works? Im just noticing that the only test seems to assert other as a stop reason to stop rather than continue which i would have assumed was not ur intent?

Our provider emits OpenAI Responses-style structural completion events, but not enough SDK-friendly finish classification for opencode’s current parser. OpenAI Responses itself does not require finish_reason; the client must derive a finish classification from the event stream. The change in this PR works because it treats the unmapped completed function-call step as "other" instead of leaving it undefined.

To the OCA users of opencode:
I found an OCA upstream Responses streaming issue while debugging OpenCode visibility failures. For some /v1/responses stream=true post-tool requests, upstream returns HTTP 200 but then closes the SSE stream with no useful output, sometimes only lifecycle events or even bytes:0. This happens intermittently across endpoints, so it does not look like a single bad endpoint or issue with opencode. The workaround in this PR was forcing opencode to do a retry. I added OCA proxy-side protection to hide those broken attempts from the client and retry before committing downstream SSE, which resolved the OpenCode rendering issue in my local testing. We need to bring this issue to OCA team now.