Skip to content

Bug: Custom provider definitions in opencode.json are ignored (local Ollama provider cannot load) #54109

Closed as not planned
Closed as not planned
Bug: Custom provider definitions in opencode.json are ignored (local Ollama provider cannot load)#54109
Assignees
rekram1-node

Description

@qhliyp
qhliyp
opened on Oct 9, 2026

Description

Custom provider configuration defined in opencode.json is completely ignored.
Following the official documentation to set up local Ollama provider does not work on OpenCode 1.18.35.
The custom ollama provider never appears in opencode models output. Trying to use the model throws ProviderModelNotFoundError.
This fully blocks the usage of local Ollama models. Ollama runs on localhost, so this is not a network or proxy issue.

Plugins

@ai-sdk/openai-compatible

OpenCode version

1.18.35 (npm install opencode-ai, Windows)

Steps to reproduce

1.1. Create global opencode.json config exactly as documented:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": { "qwen2.5:7b": { "name": "Qwen2.5 7B" } }
    }
  }
}
2. Add corresponding credential entry for `ollama` provider in auth.json.
3. Confirm local Ollama service is running, GET [http://localhost:11434/v1/models](http://localhost:11434/v1/models) returns 200 with qwen2.5:7b.
4. Run `opencode models`.

Actual result:
Only built-in `opencode` and `opencode-go` providers show up, the custom ollama provider is missing.

5. Run command: `opencode run --model ollama/qwen2.5:7b "hi"`

Actual result:
`ProviderModelNotFoundError: Model not found: ollama/qwen2.5:7b. Did you mean: ollama-cloud?`

### Screenshot and/or share link

No screenshot share link available.
Debug logs captured with `--log-level DEBUG --print-logs` show no outbound network request before the ProviderModelNotFoundError.


### Operating System

Windows 11

### Terminal

Windows Terminal

Activity

  1. github-actions
    assigned
    rekram1-node
    on Oct 9, 2026

  2. opencode-agent commented on Oct 9, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 9, 2026 – with OpenCode Agent
    Contributor

    Thanks for the detailed report, @qhliyp!

    You're on OpenCode 1.18.35, which is v1 (opencode-ai). v1 now only gets fixes for critical bugs such as data loss, security problems or crashes with no workaround, so this is unlikely to be fixed there. We recommend upgrading to v2 (@opencode/cli, the opencode command), where active development happens.

    In the meantime, a few things to check. Custom openai-compatible providers like this usually work in v1. When the provider is missing entirely ("Did you mean: ollama-cloud?"), it often means the config file isn't being read at all:

    • Make sure the global config is at %USERPROFILE%\.config\opencode\opencode.json, is valid JSON (the snippet in the issue is missing its closing fence, so please double-check the actual file), and isn't saved as opencode.json.txt.
    • Or put the same opencode.json in your project root, or point to it explicitly, e.g. $env:OPENCODE_CONFIG="C:\path\to\opencode.json" before running opencode models.
    • Ollama doesn't need a real key, so the auth.json entry is optional.

    These related issues are not the same problem:

    If you think this is critical, or you can reproduce it on v2, please reply here with the details and we'll take another look.

  3. opencode-agent
    added
    pending close
    triaging
    on Oct 9, 2026

  4. qhliyp commented on Oct 9, 2026

    @qhliyp
    qhliyp
    on Oct 9, 2026
    Author

    I followed the official docs step by step. The Ollama service works fine locally, but OpenCode simply ignores my custom provider config in opencode.json.
    This seems to be a bug instead of a misconfiguration. Please help check.

  5. opencode-agent commented on Oct 9, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 9, 2026 – with OpenCode Agent
    Contributor

    Thanks for following up, @qhliyp. I understand you followed the docs exactly, and it may well be a bug. But 1.18.35 is v1, which only gets fixes for critical issues, so a v1 bug in loading custom providers is unlikely to be fixed there.

    Two things would move this forward:

    1. Try v2. Install @opencode/cli and run the same steps with the same provider config. If v2 also ignores the custom ollama provider, please reply here. Then it goes through the normal bug flow and we'll try to reproduce it.
    2. If you need to stay on v1 for now: run $env:OPENCODE_CONFIG="C:\full\path\to\opencode.json"; opencode models in PowerShell. This shows whether the problem is the global config location or provider loading itself. Please also share the full path where your global opencode.json is saved.

    If the provider still doesn't appear on v2, please share the exact config file and the output of opencode --version and opencode models.

  6. qhliyp commented on Oct 9, 2026

    @qhliyp
    qhliyp
    on Oct 9, 2026
    Author

    Reproduced on v2.0.26 — and the root cause is more specific than "v2 ignores it"

    I installed v2 (@opencode/cli@2.0.26, opencode v2.0.26) in an isolated directory so nothing else on the machine was touched, then ran the same steps. It does not work on v2 either, but the reason is different from what I first suspected:

    The custom-provider implementation package @opencode-ai/ai has no real release.

    • npm view @opencode-ai/ai dist-tags → latest: 0.0.0-bootstrap.0
    • That tarball contains exactly 3 files: index.js, package.json, README.md — no providers/openai-compatible export
    • Its dev/beta builds cannot be installed (npm error notarget: No matching version found for @opencode-ai/ai@0.0.0-dev-20786)

    So every openai-compatible custom provider fails on v2 with Error: Model unavailable: ollama/qwen2.5:7b — the provider implementation simply isn't published yet.

    Config used on v2 (per your v2 docs schema)

    {
  "$schema": "https://opencode.ai/config.json",
  "providers": {
    "ollama": {
      "name": "Ollama (local)",
      "package": "@opencode-ai/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "http://localhost:11434/v1"
      },
      "models": {
        "qwen2.5:7b": { "name": "Qwen2.5 7B (local)" },
        "deepseek-r1:7b": { "name": "DeepSeek R1 7B (local)" }
      }
    }
  }
}

    Ollama's OpenAI-compatible endpoint is confirmed healthy: GET http://localhost:11434/v1/models → 200 and returns both qwen2.5:7b and deepseek-r1:7b.

    Repro: opencode run --model ollama/qwen2.5:7b "hi" → Error: Model unavailable: ollama/qwen2.5:7b.

    Additional finding on v1 (1.18.35)

    This may be the more actionable half. While narrowing down the v1 failure I found that enabled_providers does not appear to come from the config file at all:

    1. I deleted the enabled_providers key from the config file entirely, restarted, and queried the running server: GET /config still returns "enabled_providers": ["opencode", "opencode-go"].
    2. GET /config/providers returns only built-in providers — no lmstudio, no ollama, no modelsDiscovery, even though GET /config shows my provider.lmstudio block correctly parsed (baseURL, apiKey, modelsDiscovery.enabled: true).
    3. Debug logs (--log-level debug --print-logs) show no network request and no provider-instantiation attempt before the error — it fails in a purely local lookup.

    In other words: the config file's provider definitions are read but never converted into usable providers, and the allowlist is (re)generated internally rather than taken from config. That makes a config-layer workaround impossible.

    Environment

    • v1: opencode 1.18.35 (opencode-ai, npm, Windows x64)
    • v2: @opencode/cli@2.0.26 (isolated install, Windows x64)
    • Ollama: local, /v1/models → 200
    • Config source of truth confirmed via debug logs: only C:\opencode\config\opencode\opencode.jsonc is loaded (no OPENCODE_CONFIG env var, no project-level config in the working directory)

    Question / request

    Is provider.<id>.models for openai-compatible providers supposed to work in v1, and is @opencode-ai/ai meant to be published before v2 custom providers can be used? If the package pending release is the blocker, that's worth calling out somewhere — right now the v2 docs example points at a package that resolves to an empty placeholder.

  7. opencode-agent
    removed
    triaging
    pending close
    on Oct 9, 2026

  8. opencode-agent commented on Oct 9, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 9, 2026 – with OpenCode Agent
    Contributor

    Thanks for testing on v2 and for the detailed write-up, @qhliyp.

    I tried to reproduce this on @opencode/cli 2.0.26 with your exact v2 config (providers.ollama, package: "@opencode-ai/ai/providers/openai-compatible", settings.baseURL: http://localhost:11434/v1). I used a local OpenAI-compatible/Ollama-style server on port 11434. It worked for me:

    • opencode models listed ollama/qwen2.5:7b and ollama/deepseek-r1:7b
    • opencode run --model ollama/qwen2.5:7b "hi" got a reply from the local server

    About @opencode-ai/ai: v2 doesn't download that package. The @opencode-ai/ai/... name is mapped to the provider bundled in the CLI (@opencode/ai/...), so the empty placeholder on npm isn't the cause.

    I tested on Linux, not Windows. One thing I noticed: v2 runs a background service on a fixed port, and the CLI reuses whatever service is already running there. If that service was started earlier, for example before your isolated install or with a different config directory, it may not see your ollama provider. Could you try:

    1. opencode service status, then opencode service restart (or opencode service stop and run again)
    2. opencode models twice in a row (just after the service starts, the first call can show an incomplete list), then opencode run --model ollama/qwen2.5:7b "hi"

    If it still fails, please share:

    • the output of opencode --version and opencode service status
    • where the config file is and whether XDG_CONFIG_HOME (or any OPENCODE_* variable) is set
    • the output of opencode run --model ollama/qwen2.5:7b "hi" --log-level debug --print-logs, especially lines mentioning config or providers

  9. melato commented on Oct 10, 2026

    @melato
    melato
    on Oct 10, 2026

    New user here, using opencode v2.0.6 on debian-13.

    I got opencode to use my localhost ollama installation at the default port (11434), if I didn't use any opencode.json file at all:
    "opencode models" displayed my local ollama models + a few opencode models.

    I was also able to get opencode to recognize an ollama installation at a nearby host, using this opencode.json file:

    {
  "model": "ollama/qwen3.6:27b-coding",
  "providers": {
    "ollama": {
      "settings": {
        "baseURL": "http://10.86.78.183:11434/v1"
      }
    }
  }
}

    But I had to try several times to get it to work.

    One problem is that if opencode.json is not a valid JSON file, opencode silently ignores it, and uses the default model.
    If opencode.json is invalid, opencode should print an error and exit immediately. Otherwise, I have no idea what's going on, especially as a first time user who does not know what to expect and what the normal behavior is.

    I also noticed a quirk: The first time I ran "opencode models", it printed nothing. I had to run it twice to get the list of models.
    This seems to happen in every working directory. If I rename the directory, I need to run "opencode models" twice to get the available models.

  10. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  11. thdxr
    closed this as not plannedon Oct 11, 2026

  12. opencode-agent commented on Oct 12, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 12, 2026 – with OpenCode Agent
    Contributor

    Closing this for now, since we couldn't reproduce it and haven't heard back. On @opencode/cli 2.0.26, your exact v2 config for the custom ollama provider worked in our test: opencode models listed both models and opencode run --model ollama/qwen2.5:7b got a reply.

    If it still fails for you, please reopen or comment here with:

    • the output of opencode --version and opencode service status (after an opencode service restart)
    • where the config file is and whether XDG_CONFIG_HOME or any OPENCODE_* variables are set
    • the debug output of opencode run --model ollama/qwen2.5:7b "hi" --log-level debug --print-logs

    Thanks again for the detailed report and for testing on v2, @qhliyp.

  13. melato commented on Oct 13, 2026

    @melato
    melato
    on Oct 13, 2026

    The problem is inadequate error reporting. Try this opencode.json, which should fail, because the url is not reachable:

    {
  "providers": {
    "ollama": {
      "settings": {
        "baseURL": "http://example.com:11434/v1"
      }
    }
  }
}

    Versions:

    opencode --version
opencode v2.0.27
opencode service restart
http://127.0.0.1:49374
opencode service status
http://127.0.0.1:49374

    Then run:

    opencode run --model ollama/phi4-mini:latest "hi" --log-level debug --print-logs
opencode run --model a/b "hi" --log-level debug --print-logs
opencode run --model opencode/none "hi" --log-level debug --print-logs

    I got:

    Error: Model unavailable: ollama/phi4-mini:latest
Error: Model unavailable: a/b
Error: Model unavailable: opencode/none

    There is no indication about what went wrong: an unknown provider, a connection failure, or an unknown model.
    In my case, I have an ollama url that works with curl api/tags or v1/models, but fails silently with opencode, and I cannot find out why.

    Do you want me to open a new issue for this, or reopen this one?

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