Repository navigation
Ollama local model becomes ~7x slower through OpenCode than direct Ollama API #46506
Description
Description
OpenCode is extremely slow when using a local Ollama Qwen3.8 27B model, even though Ollama itself is not under significant CPU load.
The important issue is not a percentage slowdown, but the additional ~4 minutes of wall-clock time added by OpenCode.
Measured comparison
Setup | Time -- | -- Qwen3.8 direct via Ollama API | ~38 sec Qwen3.8 via OpenCode | ~4 min 41 sec Qwen3.8 direct via Ollama API | ~36 sec Qwen3.8 via OpenCode | ~4 min 39 secSo OpenCode adds approximately 4 minutes per request compared with calling the same Ollama model directly.
Additional observations
The same Ollama model responds quickly when called directly through the Ollama OpenAI-compatible API.
With OpenCode, the OpenCode process can reach approximately 35% CPU.
During this time, Ollama is often at almost 0% CPU, suggesting that the delay is not caused by model inference itself.
The problem therefore appears to be somewhere in OpenCode / its AI SDK integration / request processing rather than Ollama model performance.
I am not looking for a different model. The goal is to make the existing Qwen3.8 27B + Ollama setup perform normally through OpenCode.
I am also not looking for a workaround that fundamentally changes the setup. I would prefer a simple configuration or software fix.
If OpenCode cannot use the local Ollama model without adding several minutes of latency, I will likely return to AIStudio.
Important terminal observation
The same OpenCode/Ollama setup behaves differently depending on how OpenCode is accessed:
Through iTerm2/SSH, the behaviour is noticeably different from
Through macOS Screen Sharing.
This may be relevant because the OpenCode process appears to consume significant CPU while Ollama is idle.
Direct Ollama test
Calling Ollama directly is fast:
time curl -s http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "qwen3.8:latest",
"messages": [
{"role": "user", "content": "Reply with exactly: READY"}
],
"stream": false,
"reasoning_effort": "none"
}' | python3 -m json.tool
Result: approximately 0.8 seconds.
Without reasoning_effort: "none", the same request took several seconds and returned ~37–38 reasoning tokens. With reasoning_effort: "none", it returned only 2 completion tokens and completed in ~0.8 seconds.
Environment
macOS
Mac Studio M1
OpenCode 1.18.25
Ollama 0.32.14
Model:
qwen3.8:latestQwen parameters: 27.3B
Quantization: Q4_K_M
Ollama reports the model running at 100% GPU
Ollama context shown by
ollama ps: 32768OLLAMA_MAX_LOADED_MODELS=2
OpenCode configuration
{
"$schema": "https://opencode.ai/config.json",
"model": "ollama/qwen3.8:latest",
"small_model": "ollama/gemma4:26b",
"formatter": true,
"permission": {
"external_directory": {
"~/My Drive/Development/**": "allow"
},
"edit": {
"~/My Drive/Development/AIStudio/**": "allow"
}
},
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"qwen3.8:latest": {
"name": "Qwen3.8 27B (local)",
"tool_call": true,
"reasoning": false,
"attachment": true,
"limit": {
"context": 262144,
"output": 65536
}
},
"gemma4:26b": {
"name": "Gemma 4 26B (local)",
"tool_call": true,
"reasoning": true
},
"gpt-oss:20b-cloud": {
"name": "GPT-OSS 20B (cloud)",
"tool_call": true,
"reasoning": true
}
}
}
}
}
The key point is that the model is explicitly configured in OpenCode with:
"reasoning": false
yet the direct Ollama API test showed that omitting reasoning_effort: "none" causes Qwen3.8 to generate ~37–38 reasoning tokens and adds several seconds of latency.
I would like to know whether OpenCode 1.18.25 / the @ai-sdk/openai-compatible integration is correctly disabling reasoning for Ollama/Qwen3.8, and whether there is a known issue causing OpenCode itself to spend several minutes processing a request while Ollama is essentially idle.
Plugins
No response
OpenCode version
No response
Steps to reproduce
No response
Screenshot and/or share link
No response
Operating System
Apple M1 Ultra, 26.5.1 (25F80)
Terminal
iterm2 and screen both give same issue
Activity
github-actions commentedon Sep 1, 2026
This issue might be a duplicate of existing issues. Please check:
reasoning_effortnot being correctly disabled)Your issue appears closely related to #43293 in particular, which also involves Qwen3.8,
reasoning_effort: "none", and the@ai-sdk/openai-compatibleprovider. It may be worth adding your findings there and following that issue for updates.jeremiah-cp commentedon Oct 1, 2026
Adding my findings from a duplicate report (closing mine):
Timeout behavior: Simple prompts via OpenCode to local Ollama take 67-70s, client reports "status": "timeout", but the answer is correct in transcript_tail. Direct ollama run takes 1.3s. Cloud models via OpenCode take 11s with clean "status": "idle".
Plugin isolation: Tested with Superpowers and Ponytail plugins (both hook session lifecycle) removed individually and together - no change in the slowness. Issue persisted with zero plugins.
Intermittent: After cache clear (~/.cache/opencode) + restarts, the issue became intermittent (one 7s fast, one 67s slow, then consistently fast at 6-17s).
Separate MaxListeners warning: MaxListenersExceededWarning: 11 event listeners still occurs with zero plugins installed. This is distinct from the Hindsight plugin crash (which killed the process). May be an OpenCode 1.18.30 core bug.
Environment: OpenCode 1.18.30, MacBook Pro M2 Max 32GB, qwen3-coder:30b (21GB, 100% GPU).
jeremiah-cp commentedon Oct 1, 2026
Follow-up with new findings (Oct 1):
Ruled out the database. My opencode.db had ballooned to 4.5GB, so I wiped it (deleted opencode.db, wal, shm, and the snapshot dir) and restarted the server. Fresh DB came back at 244KB. Ran the same local-model test (ollama/qwen3-coder:30b, trivial prompt) and got the exact same behavior: correct answer in the transcript, client timeout waiting for the idle signal.
The server log for that test session is the smoking gun:
07:38:49 stream starts with the model
07:39:10 "exiting loop" (model finished, ~21 seconds)
07:40:50 session cleaned up
So the model completes in ~21s and the server knows it is done, but the session.idle SSE event never reaches the client within a 120s timeout. The work is fine; the "I'm done" signal is getting lost.
Also worth noting: the MaxListenersExceededWarning (11 listeners on one EventTarget) appears with zero third-party plugins configured, so this looks like an event-emitter leak in OpenCode itself rather than a plugin problem.
Environment: OpenCode 1.18.30, local Ollama, no plugins in project or global config. Direct Ollama calls are fast (~1.3s), so inference is not the issue.
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊