Skip to content

Local models via Ollama take 60-90s to respond to simple prompts like 'hi', while direct API calls take 3s #18428

Closed as not planned

Description

@dneuhaus76

Description

Environment:

  • OpenCode 1.2.27
  • Debian GNU/Linux 13 (trixie)
  • Intel Core Ultra 7 155H, Intel Arc iGPU (Vulkan)
  • Ollama 0.17.7 / llama.cpp 8455

Problem:
Any local model (tested: qwen2.5-coder:3b, glm-4.7-flash, llama3.2) takes 60-90s
to respond to a simple "hi" prompt via OpenCode.

Direct API calls to the same backend return in ~3s:
time curl http://127.0.0.1:11434/v1/chat/completions ... → real 3.304s

The same delay occurs with llama-server (llama.cpp) as backend,
ruling out Ollama as the cause.

Cloud models (Anthropic, OpenAI) respond instantly — confirming
the issue is specific to local model handling inside OpenCode.

Suspected cause:
OpenCode adds ~75s of internal overhead when processing local model responses,
possibly related to event loop blocking or empty string handling in the streaming logic.

Additional symptom:
SQLiteError: SQLITE_MISUSE on startup with multiple models defined in opencode.json

Plugins

No response

OpenCode version

1.2.27

Steps to reproduce

  1. Install Ollama and pull any local model:
    $ ollama pull qwen2.5-coder:3b-instruct-q4_K_M

  2. Configure opencode.json with Ollama as provider:
    {
    "$schema": "https://opencode.ai/config.json",
    "provider": {
    "ollama": {
    "name": "Ollama",
    "npm": "@ai-sdk/openai-compatible",
    "options": { "baseURL": "http://127.0.0.1:11434/v1" },
    "models": {
    "qwen2.5-coder:3b-instruct-q4_K_M": {
    "name": "qwen2.5-coder:3b-instruct-q4_K_M"
    }
    }
    }
    }
    }

  3. Start OpenCode and send "hi" in a new session

  4. Measure response time → ~60-90s

Expected behavior:
Response within 5-10s (model warm-up) then <5s for subsequent messages

Actual behavior:
Every message takes 60-90s regardless of prompt complexity or model size

Verification that backend is not the bottleneck:
$ time curl -s http://127.0.0.1:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{"model":"qwen2.5-coder:3b-instruct-q4_K_M",
"messages":[{"role":"user","content":"hi"}],
"max_tokens":20}'
| python3 -c "import sys,json; r=json.load(sys.stdin);
print(r['choices'][0]['message']['content'])"

real 0m3.304s ← backend responds in 3s, OpenCode takes 90s

Screenshot and/or share link

No response

Operating System

debian 13 (trixie)

Terminal

QTerminal

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Mar 20, 2026
  2. V13Axel commented on Mar 20, 2026

    @V13Axel

    OpenCode starts with a very large prompt, some ~13k tokens in my testing even before any MCPs or skills are installed. On my local system with GLM-4.7-Flash, the first time I send something to the model (especially resuming a particularly long existing session) can take minutes. After that initial processing time though, it responds near-instantly.

    Sounds to me like your local models are just taking that long to process the initial request into the kv cache.

  3. schell commented on Mar 21, 2026

    @schell

    Yeah, this happens to me as well but only on the first message. After that it's business as usual.

  4. removed
    bugSomething isn't working
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  5. gibbitz commented on May 17, 2026

    @gibbitz
    Image

    I'm seeing exponentially slower results. Note the model took 10s to determine the answer here with 32k context window, but Opencode took 22 minutes! The follow-up response was 22x faster, but still ~5x slower than the model itself.

    Note that the session name showed the translated math within 30s of the initial prompt.

    Are there debugging tools I can use to see what is happening here to try to configure slow steps out with these local models?

  6. github-actions commented on Jul 17, 2026

    @github-actions
    Contributor

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

  7. schell commented on Jul 18, 2026

    @schell

    Seems silly to close an active issue without fixing it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions