Agent stops after tool execution with OpenAI-compatible providers (Gemini, LiteLLM)

[valenvivaldi]

Description

When using OpenAI-compatible providers (e.g., Gemini 3 Flash via @ai-sdk/openai-compatible, LiteLLM), the agent loop stops after executing a tool call instead of continuing to process.

Root cause: These providers return finish_reason: "stop" even when the response contains tool calls. The OpenAI standard returns "tool_calls", but providers like Gemini and LiteLLM don't follow this convention.

In packages/opencode/src/session/prompt.ts, the loop exit condition only checks finish_reason:

if (
  lastAssistant?.finish &&
  !["tool-calls", "unknown"].includes(lastAssistant.finish) &&
  lastUser.id < lastAssistant.id
) {
  break // Agent stops here even though tools were called
}

Since finish_reason is "stop" (not "tool-calls"), the loop exits prematurely.

Steps to reproduce

1. Configure an OpenAI-compatible provider with Gemini (e.g., gemini-3-flash-preview) or LiteLLM
2. Send a prompt that triggers tool usage (e.g., "read file X")
3. The agent executes the tool but then stops instead of continuing to process the tool result

Expected behavior

After executing a tool call, the agent should continue processing (make another LLM call with the tool results) regardless of the provider's finish_reason.

Actual behavior

The agent stops after executing the tool. The user sees the tool output but the agent never processes it further.

Related issues

• Gemini models in Task (subagent) session immediately stopped with @ai-sdk/openai-compatible #14063 (Gemini models in Task/subagent session immediately stopped)

OpenCode version

1.2.11

Operating System

macOS

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• OpenCode stops generation after tool call #14842: Same symptom — OpenCode stops generation after a tool call (also macOS, also involves tool execution stopping prematurely)

If your issue is specifically about the finish_reason: "stop" root cause with OpenAI-compatible providers (as you've identified), it may be worth noting that in #14842 as additional context, or confirming whether they share the same underlying cause.

[alexsmirnov]

I did test provided PR with litellm router and openai gpt-5.2-codex, gemini-3-flash, gemini-3.1-pro. Initially, all models stopped conversations after any tool call response from LLM.
The PR fixed that, I did not affect other models that worked without it. Tested: anthropic sonnet-4.6 and opus-4.6 with bedrock provider, opensource models kimi, glm, qwen, and minimax from openrouter.
All request made through litellm router
Vote to merge PR ASAP

[lalanikarim]

This is a major blocker for using local LLMs. Please advise on timeline to address this. TIA

[peaster]

Echoing the local LLM sentiment. Especially with the new Qwen 3.5 models that are otherwise excellent in OpenCode

[omavi]

Prioritizing support for local models also feels like it should be core to the OpenCode ethos.

At least in situations like this where someone has a small and reasonable fix with big impact.

Nothing more open than running open source models on local compute which I expect to get more and more popular as the space develops.

[peltax]

#14973 fixed Qwen3.5-9B toolcalls for me.
Before the model would output xml and halt like this (task was to edit a single html file):

Output

Thinking: <tool_call>
  ┃  <function=edit>
  ┃  <parameter=filePath>
  ┃  /var/home/homepc/projects/blog/index.html
  ┃  </parameter>
  ┃  <parameter=oldString>
  ┃  <li><a href="#section-one">Section One</a></li>
  ┃  </parameter>
  ┃  <parameter=newString>
  ┃  <li><a href="/articles.html">Articles</a></li>
  ┃  </parameter>
  ┃  </function>
  ┃  </tool_call>

[valenvivaldi]

Hey everyone, thanks for all the thumbs up! 👍

I've been keeping the PR branch (#14973) updated with the latest dev — the bug is still present upstream as of today.

On our end, we need this fix since our team uses a LiteLLM proxy to route requests to Gemini, OpenAI, and other providers. Without it, the agent stops after every tool call, which makes it essentially unusable for agentic workflows.

Great to see this is also helping folks running local LLMs — glad it's not just us!

Hoping a maintainer gets a chance to review this at some point. The fix is minimal (7 lines) and all CI checks pass.

[whuanle]

I also think this is the case. Using the opencode free model is normal. Using the OpenAI model, it works fine in the "plan" mode, but there will be issues in the "build" mode.