You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[V2] "Unsupported package for ollama/<model>" when Ollama /api/tags takes longer than 1 s (hardcoded discovery timeout) #53341
With a remote Ollama server (GPU host reached through an SSH tunnel, providers.ollama.settings.baseURL set to the
tunnel's local port), the first prompt of a session sometimes fails with:
Session failed: Unsupported package for ollama/qwen3.8:27b-ctx262144:
(log: SessionRunnerModel.UnsupportedPackageError: Unsupported package for ollama/...: -- the package name after the colon is empty.)
Cause, as far as I can tell from the source (packages/core/src/plugin/provider/ollama.ts, v2.0.18): model discovery calls GET /api/tags with Effect.timeout("1 second") (line 128, also each POST /api/show, line 147). If that times out,
no models are loaded, so the provider transform never sets provider.package (line 77), and the configured model has no
package. Discovery retries every 30 s (line 181); once one attempt finishes under 1 s, everything works and the result is kept.
On our remote setup /api/tags (17 local models) typically takes about 1 s through the tunnel. Measured from a logging
proxy in front of the tunnel: on one host median 971 ms (2 of 5 calls > 1 s), on another median 1113 ms (23 of 25 calls > 1 s).
Ollama itself answers all of them with HTTP 200. We hit the error 3 times in about a week (Windows and macOS).
The 1 s limit is unchanged in v2.0.19 and v2.0.22 (and on the v2 branch at the time of writing).
Suggestion: make the discovery timeout configurable (e.g. a provider setting) or use a higher default for non-loopback
base URLs; alternatively let a configured providers.ollama entry keep a package while discovery has not succeeded yet.
Plugins
None relevant (only a local TUI status-line plugin).
OpenCode version
2.0.18 (--standalone); also checked the source of 2.0.19 and 2.0.22.
Steps to reproduce
Run Ollama 0.34.2 on a remote host with a dozen or more models; reach it through an SSH tunnel so that GET /api/tags takes slightly over 1 s.
Config: "providers": { "ollama": { "settings": { "baseURL": "http://127.0.0.1:<port>/v1" }, "models": { ... } } }, default model one of them.
Start OpenCode and send a prompt within the first ~30 s.
-> "Unsupported package for ollama/:". Sending the prompt again after a later discovery attempt succeeds works.
Operating System
Windows 11, macOS
Terminal
Windows Terminal; on macOS Terminal.app or the VS Code integrated terminal (not terminal-specific)
Reacted by qdii, jwefers, Tomás Gutiérrez L., John Ahlroos and Sven Seeberg
Adding a case from vLLM, which uses the same helper (local.ts):
The same hard-coded 1s timeout affects vllm.ts and lmstudio.ts, not only Ollama. vLLM discovery calls /health first, so a slow /health blocks the model request too.
Our endpoint is reached through a security-related router that gives very poor network conditions: TCP connect about 9s, measured with curl, versus about 20 ms without it. A higher default or a configurable timeout is needed, not only a marginal fix.
The failure is silent. With a bare provider config (no models), discovery returns zero models, and the default INFO log has no WARN or ERROR entry. Logging discovery failures at WARN would make this diagnosable, as you suggested.
Thanks for the detailed report and the timings. I could reproduce this on 2.0.18, and it still happens on the latest dev (6e978118c).
Steps:
Run a mock Ollama server whose GET /api/tags takes 1.5 s.
Configure providers.ollama with settings.baseURL set to http://127.0.0.1:<port>/v1 and qwen3:test listed under models.
Run opencode run --standalone -m ollama/qwen3:test "hi".
The result is Error: Unsupported package for ollama/qwen3:test: with an empty package name. The server only ever sees the /api/tags call. With a 100 ms delay, the same setup works on dev. The script below reproduces both cases.
On current dev the discovery logic is shared by Ollama, LM Studio and vLLM in packages/core/src/plugin/provider/local.ts, and it still has the hard-coded Effect.timeout("1 second").
/edit: my problem was actually something else. I still had an outdated line in my opencode config JSON file. I had to replace the "npm": key/value with "package": "@opencode/ai/providers/openai-compatible",
Activity
jwefers commentedon Oct 8, 2026
same now for me in v2.0.22 for llama.cpp. Still workis in v2.0.18. I have not tested the versions in between
ynohat commentedon Oct 24, 2026
Adding a case from vLLM, which uses the same helper (
local.ts):vllm.tsandlmstudio.ts, not only Ollama. vLLM discovery calls/healthfirst, so a slow/healthblocks the model request too.models), discovery returns zero models, and the default INFO log has no WARN or ERROR entry. Logging discovery failures at WARN would make this diagnosable, as you suggested.Reproduction and measurements are in #58558.
opencodejr commentedon Oct 27, 2026
Thanks for the detailed report and the timings. I could reproduce this on 2.0.18, and it still happens on the latest
dev(6e978118c).Steps:
GET /api/tagstakes 1.5 s.providers.ollamawithsettings.baseURLset tohttp://127.0.0.1:<port>/v1andqwen3:testlisted undermodels.opencode run --standalone -m ollama/qwen3:test "hi".The result is
Error: Unsupported package for ollama/qwen3:test:with an empty package name. The server only ever sees the/api/tagscall. With a 100 ms delay, the same setup works ondev. The script below reproduces both cases.On current
devthe discovery logic is shared by Ollama, LM Studio and vLLM inpackages/core/src/plugin/provider/local.ts, and it still has the hard-codedEffect.timeout("1 second").Related:
Reproduction script (repro.sh)
Run it:
bash repro.shsvenseeberg commentedon Nov 11, 2026
Did anyone already come up with a workaround?
/edit: my problem was actually something else. I still had an outdated line in my opencode config JSON file. I had to replace the
"npm":key/value with"package": "@opencode/ai/providers/openai-compatible",