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

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

Start Ollama locally on 127.0.0.1:11434
Configure OpenCode with the Ollama provider through @ai-sdk/openai-compatible
Use model ollama/qwen2.5-coder:7b-opencode-32k
Start OpenCode
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

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.

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.

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.

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.

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.

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.

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

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).

opencode 1.16.2 with ollama 0.30.6 and gemma4:latest exhibits the same problem

On 1.17.11 and Ollama version 0.30.11 the same issue is present.

I can reproduce this on OpenCode 1.17.13 with Ollama 0.22.1.

Environment:

OpenCode 1.17.13
Ollama 0.22.1
Debian 13
Intel Core i5-1035G4
16 GB RAM

Configuration:

Provider: @ai-sdk/openai-compatible
Base URL: http://localhost:11434/v1
Model: gemma4:e2b-32k

Steps to reproduce:

Restart Ollama.
Start OpenCode.
Select gemma4:e2b-32k.
Send a single prompt:
"Say OK"

Expected:
The model should immediately answer "OK".

Actual:
OpenCode never returns a response.

Observations:

While OpenCode is hanging, ollama ps shows gemma4:e2b-32k running at 100% CPU.
If I send a second request using curl to /v1/chat/completions while OpenCode is still waiting, that request also hangs.
After restarting Ollama, the exact same curl request succeeds.
/v1/chat/completions works correctly outside OpenCode.
Both stream: false and stream: true work correctly with curl.

Example:

curl http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model":"gemma4:e2b-32k",
"messages":[{"role":"user","content":"Say OK"}],
"stream":true
}'

Response times after restarting Ollama:

first request: ~21 s
second request: ~8 s

The problem only appears after OpenCode sends its request. It looks like the request issued by OpenCode causes Ollama to stop completing subsequent chat requests until Ollama is restarted.

any updates on this?

any updates on this?
Not an actual solution, but pi+llama.cpp is a valid alternative.

@madjestic

Not an actual solution, but pi+ollama.cpp is a valid alternative.

@madjestic Did you mean llama.cpp?

In any case, Pi + Ollama does work!

Yes, I've mistyped. Glad that ollama works with pi too!

Same core symptom here (opencode fails/hangs with a local Ollama provider via @ai-sdk/openai-compatible, while POST /v1/chat/completions to the same model is rock-solid), but I isolated two things I haven't seen in the thread. Sharing in case they help narrow it down.

Env: opencode 1.18.2, Ollama 0.32.0, macOS 26.5 (Darwin 25.5, arm64), qwen3:14b @ num_ctx 16384, provider @ai-sdk/openai-compatible @ http://localhost:11434/v1. Driving opencode run headless (spawned from another process), with custom agents.

1. Headless: opencode blocks on inherited stdin (a distinct "hang")

When opencode run is spawned programmatically (parent's stdin is a pipe — daemon/orchestrator/CI), it blocks and never returns. It never reaches the model: Ollama's access log shows no POST /v1/chat/completions during the hang, only the GET /api/ps probe.

Workaround — give it /dev/null as stdin:

opencode run --agent myagent -m ollama/qwen3:14b "..." < /dev/null

or stdin=DEVNULL on the subprocess. Inherited-pipe stdin → hangs; /dev/null → does not. This likely accounts for "hangs on simple prompts" whenever opencode runs outside an interactive TTY.

2. With stdin fixed, an intermittent fast-fail in `createUserMessage` remains

After the stdin fix, a fraction of runs fail in ~1s — again before any Ollama request (no POST in Ollama's log) — with:

{"type":"error","error":{"name":"UnknownError","data":{"message":"Unexpected server error. Check server logs for details.","ref":"err_..."}}}

--print-logs --log-level DEBUG gives the server-side stack:

level=ERROR message=failed ref=err_... error="UnknownError: UnknownError"
    at SessionPrompt.createUserMessage (...)
    at SessionPrompt.prompt (...)
    at SessionHttpApi.prompt (...)

i.e. it dies while creating the user message, before the provider call.

3. It's phase-intermittent, not input-dependent

The identical invocation (same flags, same custom agent, same fresh git dir, same prompt) passes 5/5 in one window and fails 0/5 in another. Ruled out as determinants: stdin mode, dir freshness, pipe-vs-file output capture, --pure / --format json, the prompt text, custom-vs-default agent, and the doc workarounds (apiKey dummy + tools: true + 127.0.0.1) — none made it reliable. Ollama stays healthy throughout (curl /v1/chat/completions succeeds during the failures).

Happy to share a minimal repro harness if that's useful.

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

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

Description

Summary

Environment

What I tested

OpenCode config

Steps to reproduce

Actual behavior

Expected behavior

Relevant log excerpt

Notes

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

1. Headless: opencode blocks on inherited stdin (a distinct "hang")

2. With stdin fixed, an intermittent fast-fail in `createUserMessage` remains

3. It's phase-intermittent, not input-dependent

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Description

Summary

Environment

What I tested

OpenCode config

Steps to reproduce

Actual behavior

Expected behavior

Relevant log excerpt

Notes

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Apr 12, 2026

Luporosso76 commented on Apr 12, 2026

Luporosso76 commented on Apr 15, 2026

Luporosso76 commented on Apr 15, 2026

Luporosso76 commented on Apr 16, 2026

Luporosso76 commented on Apr 24, 2026

LukeShortCloud commented on Apr 30, 2026

madjestic commented on May 2, 2026

Bazmundi commented on Jun 8, 2026

vladanan commented on Jun 29, 2026

toldk98 commented on Jul 4, 2026

xchrisbradley commented on Jul 11, 2026

madjestic commented on Jul 12, 2026

djmaxus commented on Jul 12, 2026

madjestic commented on Jul 12, 2026

akiramotoai commented on Jul 16, 2026

1. Headless: opencode blocks on inherited stdin (a distinct "hang")

2. With stdin fixed, an intermittent fast-fail in createUserMessage remains

3. It's phase-intermittent, not input-dependent

github-actions commented on Sep 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

2. With stdin fixed, an intermittent fast-fail in `createUserMessage` remains