Repository navigation
Bug: Custom provider definitions in opencode.json are ignored (local Ollama provider cannot load) #54109
Description
Activity
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, theopencodecommand), 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 asopencode.json.txt. - Or put the same
opencode.jsonin your project root, or point to it explicitly, e.g.$env:OPENCODE_CONFIG="C:\path\to\opencode.json"before runningopencode models. - Ollama doesn't need a real key, so the
auth.jsonentry is optional.
These related issues are not the same problem:
- Ollama custom provider error : agent configured model is not valid #8950: custom Ollama model rejected when set in an agent's config
- Auto-discover models from OpenAI-compatible provider endpoints #6231 / feat(provider): add dynamic model discovery for custom providers #42660: requests to auto-discover models from openai-compatible endpoints
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.
- Make sure the global config is at
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.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:
- Try v2. Install
@opencode/cliand run the same steps with the same provider config. If v2 also ignores the customollamaprovider, please reply here. Then it goes through the normal bug flow and we'll try to reproduce it. - If you need to stay on v1 for now: run
$env:OPENCODE_CONFIG="C:\full\path\to\opencode.json"; opencode modelsin PowerShell. This shows whether the problem is the global config location or provider loading itself. Please also share the full path where your globalopencode.jsonis saved.
If the provider still doesn't appear on v2, please share the exact config file and the output of
opencode --versionandopencode models.- Try v2. Install
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/aihas 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— noproviders/openai-compatibleexport - Its
dev/betabuilds 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→200and returns bothqwen2.5:7banddeepseek-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_providersdoes not appear to come from the config file at all:- I deleted the
enabled_providerskey from the config file entirely, restarted, and queried the running server:GET /configstill returns"enabled_providers": ["opencode", "opencode-go"]. GET /config/providersreturns only built-in providers — nolmstudio, noollama, nomodelsDiscovery, even thoughGET /configshows myprovider.lmstudioblock correctly parsed (baseURL, apiKey,modelsDiscovery.enabled: true).- 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.jsoncis loaded (noOPENCODE_CONFIGenv var, no project-level config in the working directory)
Question / request
Is
provider.<id>.modelsfor openai-compatible providers supposed to work in v1, and is@opencode-ai/aimeant 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.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 modelslistedollama/qwen2.5:7bandollama/deepseek-r1:7bopencode 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
ollamaprovider. Could you try:opencode service status, thenopencode service restart(oropencode service stopand run again)opencode modelstwice in a row (just after the service starts, the first call can show an incomplete list), thenopencode run --model ollama/qwen2.5:7b "hi"
If it still fails, please share:
- the output of
opencode --versionandopencode service status - where the config file is and whether
XDG_CONFIG_HOME(or anyOPENCODE_*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
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.
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 modelsoutput. 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