OpenCode 1.4.3 hangs with local Ollama provider on simple prompts, while /v1/chat/completions works

[Luporosso76]

Description

Title:
OpenCode 1.4.3 hangs with local Ollama provider on simple prompts, while /v1/chat/completions works

Body:

Summary

OpenCode hangs when using a local Ollama provider configured through @ai-sdk/openai-compatible.

The issue happens even with a very simple prompt like ciao.

Important detail: the same model works correctly when called directly through Ollama's OpenAI-compatible endpoint (/v1/chat/completions), so the problem does not appear to be Ollama itself.

Environment

• OpenCode: 1.4.3
• Ollama: 0.20.5
• OS: Ubuntu 25.10
• Kernel: 6.17.0-20-generic
• CPU: AMD Ryzen 7 6800H
• RAM: 30 GiB
• GPU: AMD Radeon 680M (integrated)
• Ollama running as a systemd service
• Provider backend: local Ollama via http://127.0.0.1:11434/v1

What I tested

I created dedicated Ollama models for OpenCode with larger context windows, because the docs/issues suggest OpenCode needs more context than Ollama's defaults.

Created models:

• qwen2.5-coder:7b-opencode-32k
• qwen2.5-coder:7b-opencode-64k
• qwen3.5:9b-opencode-32k
• qwen3.5:9b-opencode-64k

Example Modelfile:

FROM qwen2.5-coder:7b
PARAMETER num_ctx 32768

Ollama works correctly with these models.

Example:

ollama run qwen2.5-coder:7b-opencode-32k "Rispondi solo con OK"

returns:

OK

Also this works:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen2.5-coder:7b-opencode-32k",
    "messages": [
      { "role": "user", "content": "Rispondi solo con OK" }
    ]
  }'

Response:

{"id":"chatcmpl-...","object":"chat.completion","choices":[{"index":0,"message":{"role":"assistant","content":"OK"},"finish_reason":"stop"}], ...}

So Ollama itself is responding correctly.

OpenCode config

~/.config/opencode/opencode.json

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama",
      "options": {
        "baseURL": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama",
        "timeout": 120000,
        "chunkTimeout": 15000,
        "setCacheKey": true
      },
      "models": {
        "qwen2.5-coder:7b-opencode-32k": {
          "name": "qwen2.5-coder:7b-opencode-32k"
        },
        "qwen2.5-coder:7b-opencode-64k": {
          "name": "qwen2.5-coder:7b-opencode-64k"
        },
        "qwen3.5:9b-opencode-32k": {
          "name": "qwen3.5:9b-opencode-32k"
        },
        "qwen3.5:9b-opencode-64k": {
          "name": "qwen3.5:9b-opencode-64k"
        }
      }
    }
  },
  "model": "ollama/qwen2.5-coder:7b-opencode-32k",
  "small_model": "ollama/qwen2.5-coder:7b-opencode-32k"
}

I also tested with a cleaner/minimal config and still reproduced the same behavior.

Steps to reproduce

1. Start Ollama locally on 127.0.0.1:11434
2. Configure OpenCode with the Ollama provider through @ai-sdk/openai-compatible
3. Use model ollama/qwen2.5-coder:7b-opencode-32k
4. Start OpenCode
5. Send a very simple message like:

ciao

Actual behavior

OpenCode hangs indefinitely.

CPU usage goes up (Ollama works), but no final response is shown in OpenCode, even though direct curl requests to /v1/chat/completions return normally.

Expected behavior

OpenCode should return a normal text response for a simple prompt, just like the direct Ollama API call does.

Relevant log excerpt

This is the part that looks suspicious to me:

service=llm providerID=ollama modelID=qwen2.5-coder:7b-opencode-32k sessionID=... small=true agent=title mode=primary stream
...
service=session.processor process
service=llm providerID=ollama modelID=qwen2.5-coder:7b-opencode-32k sessionID=... small=false agent=build mode=primary stream
...
service=bus type=session.updated publishing

After that, the UI remains stuck.

I also noticed that even for a trivial prompt, OpenCode still appears to enter the build flow.

Notes

• This does not look like an Ollama connectivity issue, because:
  • ollama run ... works
  • curl /v1/chat/completions works
• This may be related to the OpenAI-compatible provider flow, agent/tool loop, or streaming/session finalization.

Happy to provide more logs if needed.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions]

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

• Ollama: User message content arrives as empty array - model cannot see user input #5187: Same setup (Ollama via @ai-sdk/openai-compatible, similar config, model receives empty/incorrect content and hangs) — very similar symptoms and configuration
• Default agent is brittle against local OpenAI-compatible tool-call quirks #20669: Local OpenAI-compatible backends causing session hang/loop behavior when the model returns unexpected responses

Please review those issues and see if any of the workarounds or findings there apply to your situation. If your issue is distinct, feel free to note the differences.

[Luporosso76]

Thanks, I checked both issues.

#5187 looks especially close to my case:

• same general setup: Ollama via @ai-sdk/openai-compatible
• direct calls to Ollama work correctly
• OpenCode hangs or behaves incorrectly on very simple prompts

#20669 also seems related, especially because my logs show OpenCode entering the default agent flow (agent=title and then agent=build) before getting stuck, which seems consistent with local OpenAI-compatible/tool-call brittleness.

What seems most relevant in my case is:

• OpenCode version: 1.4.3
• Ollama version: 0.20.5
• model: ollama/qwen2.5-coder:7b-opencode-32k
• direct ollama run ... works
• direct POST /v1/chat/completions works
• OpenCode hangs even on a trivial prompt like ciao

So I agree this is likely related to #5187, with #20669 also looking relevant for the default agent/tool-call path.

If helpful, I can provide the exact config and logs from my reproduction.

[Luporosso76]

I found several additional Ollama-related issues that seem consistent with the same broader failure cluster around local Ollama / OpenAI-compatible integration:

• ollama launch opencode --model gemma4 #20908: terminal hangs with ollama launch opencode --model gemma4
• Ollama context stuck at 0% #21736: context stays stuck at 0% while agent is working
• [BUG] Ollama integration: Invalid maxOutputTokens error #21858: invalid maxOutputTokens with local Ollama, while direct Ollama API calls work
• Integration with Ollama Local #19948: local Ollama returns invalid JSON / pseudo-tool output instead of normal text
• Gemma 4 (e4b) tool calling fails via Ollama OpenAI-compatible API — streaming tool_calls not recognized #20995: Gemma 4 tool calls via Ollama OpenAI-compatible are returned but not recognized by OpenCode
• Local Ollama subagents return tool calls as text instead of executing them in task/delegate #21181: local Ollama subagents return tool calls as text instead of executing them
• not compatible to ollama/qwen2.5-coder:7b #10402: older report with ollama/qwen2.5-coder:7b and no response

This makes my issue look less like a single model/config problem and more like a broader OpenCode ↔ Ollama local integration problem.

[Luporosso76]

I tested again after upgrading to OpenCode 1.4.6, and the issue is still reproducible.

Current status:

• OpenCode: 1.4.6
• Ollama: 0.20.5
• local provider via @ai-sdk/openai-compatible
• model: ollama/qwen2.5-coder:7b-opencode-32k

Behavior is unchanged:

• direct ollama run ... works
• direct POST /v1/chat/completions works
• inside OpenCode, even a trivial prompt like ciao still hangs
• CPU usage increases, but no final response is shown in the UI

So at least on my setup, this is still present in 1.4.6.

[Luporosso76]

I narrowed this down further.

With the same Ollama setup and the same model:

• Chat mode works correctly
• Plan mode hangs
• Build mode hangs

So this is not a general Ollama connectivity or basic text-generation problem.

The failure seems specific to the agentic flow used by Plan/Build (tool orchestration, tool-call parsing, or agent loop handling), while plain chat completions work correctly.

This seems consistent with the broader local OpenAI-compatible / Ollama issues discussed in #5187 and #20669.

[Luporosso76]

I manually tested all relevant Ollama endpoints with the same model and trivial prompt, and they all work correctly.

Successful manual tests:

• POST /v1/chat/completions -> 200 OK
• POST /v1/messages -> 200 OK
• POST /v1/messages?beta=true -> 200 OK

So this is not caused by:

• the endpoint path itself
• the ?beta=true query parameter
• basic Ollama compatibility for these APIs

This strongly suggests Opencode is sending a problematic request payload or using a client-side flow that differs from the simple successful manual requests.

Given the Ollama logs also show:

• aborting completion request due to client closing the connection

the issue now looks much more like a Opencode request construction / streaming / tools / client-handling problem, not an Ollama endpoint problem.

[LukeShortCloud]

Possibly related: in Nanocoder the fix was to disable some timeouts: Nano-Collective/nanocoder#441 (comment) . OpenCode might have similar configurable options.

[madjestic]

Possibly related: in Nanocoder the fix was to disable some timeouts: Nano-Collective/nanocoder#441 (comment) . OpenCode might have similar configurable options.

I am experiencing a very similar issue. I've tried the suggested workaround, but that did not fix it for me. Here's my config:

{
  "$schema": "https://opencode.ai/config.json",
  "tools": {
      "task": false,
      "webfetch": false,
      "todowrite": false
  },
  "model": "ollama/qwen3.5-32k-nothink",
  "small_model": "ollama/qwen3.5-32k-nothink",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
          "baseURL": "http://localhost:11434/v1",
	  "requestTimeout": -1,
	  "socketTimeout": -1,
          "apiKey": "ollama"
      },
      "models": {
        "qwen3.5-32k-nothink": {
          "tools": true
        }
      }
    }
  }
}

Also I noticed that while looking at the Opencode - ollama communication by redirecting the url to a 8080 proxy via mitmdump I see that the responce message gets dumped only after the Opencode prompt is cancelled (by pressing Escape twice after sending a simple prompt).