opencode subagent: SessionRunner throws ModelUnavailableError for a model listed in /config/providers (opencode 1.18.29)

[yulong-ge]

Environment

• devspace: 1.0.8 (npm global, @waishnav/devspace)
• opencode: 1.18.29 (upgraded from 1.14.30 while debugging)
• @opencode-ai/sdk bundled with devspace 1.0.8: 1.18.29
• OS: Ubuntu 22.04 (x86_64), Node v24.14.0
• Subagent provider: opencode (enabled in ~/.devspace/config.json), agent profile with an explicit model: in its frontmatter

What happened

With subagents enabled and a profile that pins a model (e.g. model: alibaba-token-plan-cn/glm-5.2), every devspace agents run <profile> "..." fails at session drain time with:

SessionRunnerModel.ModelUnavailableError: Model unavailable: alibaba-token-plan-cn/glm-5.2

The run surfaces as either PROVIDER_EXECUTION_ERROR: OpenCode agent execution failed. or PROVIDER_PROTOCOL_ERROR: OpenCode did not finish the session before the provider timeout. — the prompt is admitted, but the turn never produces an assistant message.

What I verified (to rule out the obvious causes)

1. The model is present in the spawned server's /config/providers — confirmed by querying http://127.0.0.1:4096/config/providers on the daemon-spawned instance: alibaba-token-plan-cn lists glm-5.2, status active.
2. opencode run -m alibaba-token-plan-cn/glm-5.2 "..." in the same project directory works fine and returns a reply — so auth for the provider is valid.
3. Session creation via SDK v2 succeeds: client.v2.session.create({ location: { directory: <project> }, agent: "devspace_read_only" | "devspace_allowed", model: { providerID, id } }) returns a session id, and the session row in opencode's sqlite DB stores exactly {"id":"glm-5.2","providerID":"alibaba-token-plan-cn","variant":"default"}.
4. The failure happens right after booting location services in the opencode log, with Failed to drain Session ... ModelUnavailableError — i.e. the server-side SessionRunner rejects the model reference even though that same model id is listed under that provider.
5. Creating the session without an explicit model (letting the agent/project default apply) gets past model resolution — the turn then runs and reaches the LLM (in my case it then failed on an unrelated free-tier 429 from the default model). So the problem looks specific to resolving the explicit model ref handed over by devspace, not auth or networking.
6. Tried the model ref with and without variant (no variant / variant: "high"); both fail the same way.

Minimal repro

# ~/.devspace/config.json
{ "subagents": { "enabled": true }, "providers": [ { "id": "opencode", "enabled": true } ] }

# ~/.devspace/agents/my-profile.md
---
schema: devspace-agent/v1
name: my-profile
description: ...
provider: opencode
model: alibaba-token-plan-cn/glm-5.2
---

cd <some git project under allowedRoots>
devspace agents run my-profile "What language is this project?"
# -> agent run fails; opencode log shows ModelUnavailableError for that model

The provider in question is a custom OpenAI-compatible provider defined in ~/.config/opencode/opencode.json (aliyun token-plan endpoint) — but the same behaviour appeared with deepseek/deepseek-v4-flash (official DeepSeek provider), so it does not look provider-specific.

Happy to provide full daemon logs (~/.local/share/devspace/agentd.log) or opencode server logs if useful.

[Waishnav]

Tell your agent to fix the description of this, i won’t be able to read this crap

[yulong-ge]

Sorry about that — the original body was accidentally submitted as a raw JSON blob. It's now rewritten as proper markdown: env, symptom, what was ruled out (model present in /config/providers, auth fine via CLI, session create OK, no-model sessions pass), and a minimal repro. Happy to attach daemon/opencode logs if useful.

[Waishnav]

ohh never mind.

anyway i'm currently caught up with other work, will you work on this issue and file the PR?

[yulong-ge]

Root cause found — and it's an upstream opencode bug, not a devspace model-parsing problem.

What's actually happening

Deep-dived with a local opencode serve instance + raw v2 SDK. The turn does run — it fails at the provider call with HTTP 401 from the model provider:

{
  "id": "msg_...",
  "type": "assistant",
  "model": {"id": "glm-5.2", "providerID": "zhipuai-coding-plan", "variant": "default"},
  "finish": "error",
  "error": {
    "type": "unknown",
    "message": "Provider request failed with HTTP 401: {\"error\":{\"code\":\"1001\",\"message\":\"Header中未收到Authorization参数，无法进行身份验证。\"}}"
  }
}

The provider key is not attached to the outgoing LLM request when the session was created through the v2 API (POST /api/session + POST /api/session/{id}/prompt) against a opencode serve instance.

Evidence matrix

Path	Auth	Result
opencode run -m zhipuai-coding-plan/glm-5.2 "..." (CLI, same machine, same dir)	works	✅ reply
v2 SDK: session.create (with variant: "default") + session.prompt → serve	401	❌ finish: "error"
v2 SDK: session.create without explicit model (default model from agent config) → serve	401	❌ same error
delivery: "queue" / resume: true variants	401	❌ same error

Key observations:

• /config/providers on the serving instance lists the provider with source: "api", key: "0e64..." (from ~/.local/share/opencode/auth.json) — so the config layer sees the key.
• Yet the actual LLM HTTP call leaves without the Authorization header → provider returns 1001 (missing auth header).
• This reproduces with any source: "api" provider (auth.json-based): zhipuai-coding-plan, deepseek, alibaba-token-plan-cn. source: "config" providers (key embedded in opencode.json custom provider config) reportedly still work, which matches the original report's alibaba-token-plan-cn… in our latest tests that one (api-source) fails too.
• The assistant message row lands with finish: "error" immediately (~10ms after creation), but no error event is emitted on the session SSE stream — the client just sees the turn stall until it times out. That's why devspace's waitForOpencodeSession hits PROVIDER_PROTOCOL_ERROR ... before the provider timeout instead of surfacing the 401.

So the ModelUnavailableError framing in my original report was misleading — the model resolution itself is fine; the underlying provider call 401s, and the error surfaces through a different path in older opencode builds.

Where this leaves devspace

Fix belongs upstream (opencode serve must attach auth.json keys to provider requests made on behalf of v2-API-created sessions). I'll file the issue there and link it here.

Two things devspace could consider regardless (not blockers for this issue):

1. Surfacing finish: "error" + error.message from the assistant message (it's visible via GET /api/session/{id}/message) instead of timing out — would have turned a day of debugging into a minute.
2. The docs' claim that CLI opencode run working rules out auth problems doesn't hold when serve-mode v2 API is involved.

[yulong-ge]

Upstream issue filed: anomalyco/opencode#47888 (opencode serve: provider auth not attached to LLM requests for v2-API-created sessions). Also confirmed the v1 API ( via the SDK's client.session.*) works correctly against the same serving instance, end-to-end with custom agents injected through OPENCODE_CONFIG_CONTENT — so a devspace-side mitigation would be switching the opencode runtime from the v2 endpoints to the v1 ones until this is fixed upstream.

[yulong-ge]

Fix proposed in #327 — switches the opencode runtime to the v1 session endpoints (verified end-to-end against a real serve instance: agent run completes where the v2 path 401'd). Happy to rebase or adjust.