Repository navigation
agents: frontmatter model cached per session — unavailable model silently pins all later subagents to a fallback provider #53060
Description
Description
An agent's frontmatter model: is resolved once when a session starts and never refreshed. Worse, when that model can't be resolved the failure is silent: the subagent is switched to a different model on a different provider and keeps using it for the rest of the session.
I had 7 agents pinned to opencode-go/muse-spark-1.3-free. That model disappeared from the catalog, and the log showed:
SessionRunnerModel.ModelUnavailableError: Model unavailable: opencode-go/muse-spark-1.3-free
From that point, subagents spawned in an already-open session switched to muse-spark-1.3-contributor-free on provider opencode — a different provider than my configured opencode-go, and a model string that appears in no config file of mine (git log -S'contributor-free' over the agents dir finds nothing). Nothing was surfaced to me or to the parent agent; the only trace was the server log.
I then repinned all 7 agents to opencode-go/space-bunny-free. New sessions picked it up immediately. The open session never did: 63 consecutive subagents from it ran on the fallback provider over the following three days, most recently today. The only workaround I found was starting a new session.
This is the same impact as #52333 — traffic silently going to an unintended third-party provider and staying there — but a different trigger: agent frontmatter rather than provider.use policies during hot-reload. It is also not #49765/#50925: the configured model is applied correctly in new sessions (I verified five subagents resolve to it), it is just frozen in already-open ones. The "needs a restart to apply config" part overlaps #39987, but a silent switch to the wrong provider seems like a bug rather than a feature request.
Plugins
None
OpenCode version
2.0.22 (also observed on 2.0.18)
Steps to reproduce
- Open a session and spawn a subagent; confirm it uses its configured model.
- Make that model unresolvable in the catalog (or pin a model that isn't in it) while the session stays open — the
ModelUnavailableErrorabove appears in the log. - Spawn the subagent again: it runs on a different model, on a different provider, with no error shown to the user or the parent agent.
- Correct the config to a valid model. Spawning from the same session still uses the fallback; spawning from a new session uses the corrected model.
Screenshot and/or share link
The TUI surfaces the fallback model in the subagent title, which is how I noticed. I can provide a share link if that's useful.
Operating System
Linux 7.2.5-3-omarchy (x64)
Terminal
Ghostty
Activity
vpteruel commentedon Oct 4, 2026
Edited: the body now uses the Bug report template (required
Descriptionfield present) and is substantially shorter — the earlier version was a generic write-up rather than the template.The compliance bot's comment above is from issue creation and refers to the previous body, which had a
Summarysection instead ofDescription.github-actions commentedon Oct 4, 2026
Thanks for updating the issue with the required description and reproduction details!
opencode-agent commentedon Oct 4, 2026
I tested this on current V2 (
origin/v2at0a46301e36, package version 2.0.22) in an isolated instance. I configured areviewersubagent withmodel: simulation/agent-only, launched it successfully, then used a plugin model transform to remove that model while keeping the parent's model available. The catalog confirmed the agent model was gone. Launchingreviewerwithout a model override from both the already-open parent session and a fresh parent session produced a subagent tool failure:Model unavailable: simulation/agent-only. Neither run silently selected another model/provider. The same test passed twice; this is not a reproduction of the specificopencode-gocatalog change.One plausible explanation for the observed alternate provider is a parent-agent choice after the error, rather than an automatic fallback: the
subagenttool accepts an optionalmodelargument, and an explicit override takes precedence over the agent's frontmatter model. The parent could have listed available models and then retried the subagent withmodel: opencode/muse-spark-1.3-contributor-free, which wouldn't need to appear in your config. Can you check whether the affected parent calledmodelsand whether its subsequentsubagentcalls contained amodelargument? A redacted tool-call trace around the first failure would distinguish that from a runtime fallback. This is a hypothesis, not a claim about what happened in your session.rekram1-node commentedon Oct 4, 2026
the parent can choose what model to make a subagent with, this was likely due to a combination of factors but once u had a model configured that didnt work, rhe agent likely found a workaround and continued to use the workaround for the remainder of the session unless u inform it otherwise
kinda a weird edge case
opencodejr commentedon Oct 27, 2026
Thanks for the detailed report. The 2.0.22 code doesn't fall back to another provider by itself. When an agent's frontmatter model isn't in the catalog, the subagent call fails with
Model unavailable: <provider>/<model>. That's also what the earlier reproduction attempt here found, from both an already-open session and a new one.There are two ways the parent agent could have ended up on
opencode/muse-spark-1.3-contributor-freeand stayed there:subagenttool takes an optionalmodelargument, and it wins over the agent's frontmatter model. After the first failure, the parent may have looked up an available model with themodelstool and passed it on every later call. That would explain a model ID that isn't in any of your config files, and why fixing the config didn't change that session.sessionID), those children keep the model already stored on them.To tell these apart from a real runtime fallback, could you share a redacted trace of the parent session around the first
ModelUnavailableError? The useful parts are:modelstool.subagentcalls before and after the switch, especially whether they include amodeland/orsessionIDargument.A share link would also work if it shows the tool-call inputs. 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.
Related issues, ordered by how closely they match:
opencodejr commentedon Oct 30, 2026
We're closing this issue for now because we haven't heard back. We needed the parent session's tool-call trace to tell whether the parent agent itself chose
opencode/muse-spark-1.3-contributor-freeor OpenCode fell back to it. The parent could have passed an explicitmodelargument tosubagent, or kept continuing child sessions withsessionID. We couldn't reproduce an automatic fallback on 2.0.22, so we can't take this further without the trace.If it happens again, please reply here with a redacted trace around the first
Model unavailableerror, or a share link that shows thesubagentcall inputs. We'll gladly reopen and look into it. Thanks for the detailed report.Related: #59177, #52333, #59238.