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
I opened a new tab, let opencode rebuild Duo Auth Proxy and afterwards realized, that for whatever reason Opencode did not use the configured models but "cat-jam-free". That is highly dangerous. I need now to cycle all the passwords involved.
Absolute Feature Request:
When a Provider is configured in opencode.json, never use and never propose anything else.
Thanks for reporting this, @RalphBariz, and sorry for the trouble. If a configured setup quietly sends work to a model you never chose, that's serious, so we'd like to find out exactly how it happened. To work out which code path picked cat-jam-free (a free built-in OpenCode Zen model), could you share:
Your OpenCode version (opencode --version), and whether you used the terminal UI or the desktop app.
Your opencode.json (global and/or project) with all API keys and secrets removed. We especially need to know whether you set a top-level default model, or only configured providers.
How you opened the new tab (the + in the tab rail, /new, a fresh opencode start, etc.), and whether a model had been picked in another tab or another OpenCode window shortly before.
What the model picker or footer showed in that tab before you sent the prompt, if you remember.
Your OS and how you installed OpenCode.
If you can, run opencode models --print-logs and check for any warnings about your config file. A config file with a syntax error is currently skipped without a visible error, and OpenCode then falls back to the built-in models.
You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.
These existing issues are closely related, ordered by likelihood. One of them may already cover what happened:
On your request to never use anything other than the providers you configured: as #54686 shows, the built-in opencode provider can already be excluded in the config, so it can't be picked as a fallback. Maintainers can look at going further than that once we understand what happened here.
Thanks for the details, @RalphBariz. I tried to reproduce this on v2.0.24 with a config like yours: one custom openai-compatible provider, no top-level model, and the built-in opencode provider left enabled. I sent a prompt in the first tab, then opened a new tab with + in the tab rail. In my test environment the new tab kept the custom model. But the built-in opencode/* free models never loaded there, so the model it apparently fell back to for you (cat-jam-free) wasn't available. That means my test doesn't rule your case out. This needs to be checked by a maintainer in an environment where those built-in free models load.
From reading the v2.0.24 code: when a new tab has no model of its own, it falls back to the top-level model from your config (you don't set one), then the most recently used models shared across tabs and windows, then the first model in the list. So if your custom model was never picked explicitly from the model picker, or a different model was picked in another tab or window (see #54363), a new tab can end up on one of the built-in free models.
Until this is looked at, you can protect yourself by setting a default model at the top level of your opencode.json:
"model": "dgx/qwen3:125b"
It also helps to check the model shown under the prompt before sending in a new tab. Related issues: #54363 (a tab's model follows choices made in other tabs or windows), #43055 (default model selection in the v2 terminal UI) and #54686 (how the default model is picked, including the built-in free models).
Activity
[-][DANGER][/-][+][DANGER] Data Leak to cat-jam-free[/+]opencode-agent commentedon Oct 13, 2026
Thanks for reporting this, @RalphBariz, and sorry for the trouble. If a configured setup quietly sends work to a model you never chose, that's serious, so we'd like to find out exactly how it happened. To work out which code path picked
cat-jam-free(a free built-in OpenCode Zen model), could you share:opencode --version), and whether you used the terminal UI or the desktop app.opencode.json(global and/or project) with all API keys and secrets removed. We especially need to know whether you set a top-level defaultmodel, or only configured providers.+in the tab rail,/new, a freshopencodestart, etc.), and whether a model had been picked in another tab or another OpenCode window shortly before.opencode models --print-logsand check for any warnings about your config file. A config file with a syntax error is currently skipped without a visible error, and OpenCode then falls back to the built-in models.You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.
These existing issues are closely related, ordered by likelihood. One of them may already cover what happened:
modelfrom the config and falls back to another provider's model.opencode.jsonis ignored without any warning, which leaves only the built-inopencode/*models.On your request to never use anything other than the providers you configured: as #54686 shows, the built-in
opencodeprovider can already be excluded in the config, so it can't be picked as a fallback. Maintainers can look at going further than that once we understand what happened here.udet-at commentedon Oct 13, 2026
curl -fsSL https://opencode.ai/v2/install | bashopencode-agent commentedon Oct 13, 2026
Thanks for the details, @RalphBariz. I tried to reproduce this on v2.0.24 with a config like yours: one custom openai-compatible provider, no top-level
model, and the built-inopencodeprovider left enabled. I sent a prompt in the first tab, then opened a new tab with+in the tab rail. In my test environment the new tab kept the custom model. But the built-inopencode/*free models never loaded there, so the model it apparently fell back to for you (cat-jam-free) wasn't available. That means my test doesn't rule your case out. This needs to be checked by a maintainer in an environment where those built-in free models load.From reading the v2.0.24 code: when a new tab has no model of its own, it falls back to the top-level
modelfrom your config (you don't set one), then the most recently used models shared across tabs and windows, then the first model in the list. So if your custom model was never picked explicitly from the model picker, or a different model was picked in another tab or window (see #54363), a new tab can end up on one of the built-in free models.Until this is looked at, you can protect yourself by setting a default model at the top level of your
opencode.json:It also helps to check the model shown under the prompt before sending in a new tab. Related issues: #54363 (a tab's model follows choices made in other tabs or windows), #43055 (default model selection in the v2 terminal UI) and #54686 (how the default model is picked, including the built-in free models).