[Bug] muse-spark-1.3-contributor-free: reasoning encrypted_content was not issued to this caller when switching models in same session

[Joelincn]

Description

muse-spark-1.3-contributor-free (provider opencode / Console / Zen) consistently fails mid-session when switching models, with:

Error from provider (Console): Upstream request failed: [invalid_request_error] reasoning `encrypted_content` was not issued to this caller

muse-spark-1.2-contributor-free does not trigger this in the same workflow.

Reproduction

1. opencode 1.18.30 (both ~/.opencode/bin/opencode and ~/.npm-global/bin/opencode are 1.18.30, plugin @opencode-ai/plugin@1.18.30)
2. Start a session with muse-spark-1.2-contributor-free (provider opencode)
3. Chat for a few turns (reasoning enabled by default: transform.ts sets include: ["reasoning.encrypted_content"] for providerID.startsWith("opencode"))
4. Switch model in the same session to muse-spark-1.3-contributor-free and send next message

Result: every subsequent request fails (see logs below). Also reproducible in reverse (start with 1.3 then switch to 1.2/other models) — symmetric cross-model replay issue.

Fresh session starting directly with 1.3 works fine; failure only occurs when session history contains reasoning.encrypted_content issued by a different caller/model and is replayed.

Logs

~/.local/share/opencode/log/opencode.log (30+ occurrences, same session IDs):

timestamp=2026-09-13T08:22:14.112Z level=ERROR run=99d847df message="stream error" providerID=opencode modelID=muse-spark-1.3-contributor-free session.id=ses_f6c6b96a9ffePiDYbHphIWblIr small=false agent=build mode=primary error.error="AI_APICallError: Error from provider (Console): Upstream request failed: [invalid_request_error] reasoning `encrypted_content` was not issued to this caller"
timestamp=2026-09-13T08:46:43.962Z level=ERROR run=0ac5e92c message="stream error" providerID=opencode modelID=muse-spark-1.3-contributor-free session.id=ses_f66192d6bffe1g2Y9nnuRNruxP small=false agent=build mode=primary ...
# (full log has 30+ identical errors for ses_f6c6b96a9ffePiDYbHphIWblIr and ses_f66192d6bffe1g2Y9nnuRNruxP)

Root cause (suspected)

muse-spark-1.3 returns reasoning items with encrypted_content (opaque, caller-bound, see also #43584 where muse-spark-1.2 already returns encrypted_content with summary:[]). transform.ts:447 enables include: ["reasoning.encrypted_content"] for all opencode providers, so history replay includes that blob.

When switching models mid-session, opencode replays the previous model's encrypted_content to the new model. Upstream Console validates the caller and rejects (was not issued to this caller). Same class as recent Claude fix in v1.18.27 (thinking.blockBinding tolerance for stale blocks), but no equivalent tolerance for OpenAI-style reasoning.encrypted_content on the opencode provider path.

PRs #45050/#45032/#44997 fixed similar store:false replay for openai/azure providers, but native-runtime.ts allowlist and transform handling for opencode provider's muse-spark family does not yet strip/isolate encrypted_content on model switch.

Expected

Cross-model switch in same session should not fail. Similar to Claude fix, opencode should drop encrypted_content (keep only summary) when replaying reasoning across different models/callers, or isolate reasoning per model.

Environment

• opencode 1.18.30 (latest as of 2026-09-13), also tested after fresh curl -fsSL https://opencode.ai/install | bash
• ~/.opencode plugin 1.18.30
• OS: Linux (Ubuntu), opencode web --port 4096 and TUI

Workaround

Start a new session (/new) when switching between muse-spark-1.2 and 1.3 (or any reasoning model). /clear before switch also avoids the replay.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [BUG] Forking an existing session replays incompatible reasoning.encrypted_content #37444: Same root cause — replaying incompatible reasoning.encrypted_content from a prior session (fork scenario), same encrypted_content caller-binding rejection mechanism
• provider: stale composite reasoning item id (rs_A:rs_B) replayed after restart → invalid_request_error #48319: Stale composite reasoning item ID replayed after restart causes invalid_request_error on the same opencode provider path — same class of stale/mismatched encrypted reasoning replay
• Responses multi-turn fails on strict gateways: replayed reasoning items drop provider id (input.N.id: expected a value) #48441: Replayed reasoning items missing provider IDs cause failures on strict gateways — related reasoning history replay class

If your issue is distinct (specifically the cross-model switch case within the same session for muse-spark on the opencode provider), please note that distinction in a comment so maintainers can track it separately.

[Joelincn]

Distinct from #37444 / #48319 / #48441 — this is cross-model switch in the SAME session.

Update with latest verification on opencode 1.18.30:

• Config applied to try to suppress new blobs (backup kept at opencode.jsonc.bak.20260914010412):

{
  "$schema": "https://opencode.ai/config.json",
  "provider": { "opencode": { "models": {
    "muse-spark-1.3-contributor-free": { "options": { "include": [] } },
    "muse-spark-1.3": { "options": { "include": [] } },
    "muse-spark-1.2-contributor-free": { "options": { "include": [] } },
    "muse-spark-1.2": { "options": { "include": [] } }
  } } }
}

• New session starting directly with muse-spark-1.3-contributor-free works fine, no encrypted_content error (session ses_f643dfaedffesBqtvGAsRpeffn, logs clean after 2026-09-13T17:12Z).
• Old polluted sessions (ses_f66202cd9ffeCze6vsn4v6gz1U, ses_f6c6b96a9ffePiDYbHphIWblIr) failed symmetrically in BOTH directions (1.2 -> 1.3 and 1.3 -> 1.2), 30+ reasoning encrypted_content was not issued to this caller errors. Polluted session deleted via opencode session delete, DB verified clean (session / message / part count 0).
• include: [] only prevents requesting NEW encrypted_content, it does NOT strip history. So it cannot fix already-polluted sessions.

Why not a dup:

• [BUG] Forking an existing session replays incompatible reasoning.encrypted_content #37444 is fork + same model (rsn_ / smry_ prefix), mine is same session + different model, no fork.
• provider: stale composite reasoning item id (rs_A:rs_B) replayed after restart → invalid_request_error #48319 is restart + expired composite rs_A:rs_B, mine reproduces without restart.
• Responses multi-turn fails on strict gateways: replayed reasoning items drop provider id (input.N.id: expected a value) #48441 is missing id on strict gateways, mine has the blob but caller mismatch.

Suggestion: same tolerance as the Claude fix in v1.18.27 (thinking.blockBinding), but for OpenAI-style reasoning.encrypted_content on the providerID.startsWith("opencode") path — drop encrypted_content and keep only summary when replaying across different models/callers.

[1837620622]

Also happens without a model switch: idle/resume of a Muse 1.3 session on 1.18.30 bricks the chat with the same Console encrypted_content caller error.

#48915

[1837620622]

Same class of stale encrypted_content replay. Fix: #48918

[Joelincn]

Confirming a third trigger of the same root cause, no model switch involved:

• opencode 1.18.30, default config, single session on muse-spark-1.3-contributor-free
• Egress rotates across 3 Singapore ASNs (load-balanced); every failure is preceded by socket connection was closed unexpectedly, then ~10s later reasoning encrypted_content was not issued to this caller. The "8-10 rounds" pattern matches keep-alive lifetime, not turn count.
• Once hit, the session is permanently bricked; switching to 1.2 in the same session fails identically (replays 1.3-issued blobs).

This matches #48915 (thanks for linking). Endorsing its ask here: on this specific 400, drop reasoningEncryptedContent/itemId, persist cleaned parts, and retry once — same class as the Claude stale-thinking recovery in v1.18.27 — instead of blind retry. Plus either sticky routing for Console sessions or a doc note that free models do not tolerate caller/egress rotation. Happy to provide logs.

[cwkeam]

Same root cause as #37444, and I hit it without any model switch: plain restart + resume (opencode --continue) of a long muse-spark-1.3-contributor-free session (Console/Zen path, xhigh) reproduces the identical 400 immediately — the first resumed turn fails and every retry in that session fails. The stored reasoning parts carry caller-bound continuation state minted by the previous opencode process; replayed into a fresh caller connection, the gateway rejects them. That's #48319's restart trigger, same family, just our error message instead of rs_A:rs_B not found.

DB evidence (stock ~/.local/share/opencode/opencode.db, pre-cleanup snapshot):

• part.data reasoning rows look like:
  {"type":"reasoning","text":"<summary>","metadata":{"openai":{"itemId":"rs_…","reasoningEncryptedContent":"Q-Pa…"}}}
• 233 parts across 7 sessions carried those two fields.
• message.data error rows: APIError · 400 · "reasoning \encrypted_content` was not issued to this caller"from gatewayhttps://opencode.ai/zen/v1/responses`.

Workaround that works today (no upstream change): delete metadata.openai.itemId and metadata.openai.reasoningEncryptedContent from stored reasoning parts. The visible reasoning summary/text is preserved, and resumed sessions continue cleanly after restart. I made it durable by installing persistent AFTER INSERT/UPDATE triggers on the part table so the fields never get persisted again — re-runnable stdlib script, idempotent, re-run after any opencode upgrade that rebuilds the store.

On the proper fix: agree with #37444's patch direction — the request-normalization layer should treat itemId/reasoningEncryptedContent as non-durable continuation state: replay it only for the current in-flight turn (same connection, tool-loop continuation), and keep only the visible summary for historical reasoning when reconstructing input across fork/resume/restart boundaries. The auto-retry fallback in #31236 (on this specific 400, resend once with stale reasoning references dropped) would make all these triggers transparent for every provider.

One more signal worth triaging separately: #49188 (filed today) reports this now happens in fresh short sessions after 2–3 messages, no resume/compact involved — suggests the Console gateway started enforcing stricter validation/expiry on the replayed encrypted_content. If the normalization fix lands and that repro persists, it points at the gateway side.

[goainwo0]

Building directly on what is already in this thread, since the groundwork here is the best of all the related issues. @Joelincn, you deleted polluted sessions outright to escape this, which works but costs the whole history. @cwkeam, your manual cleanup plus persistent triggers is exactly the right shape, and your DB evidence matches mine field for field. I packaged the same idea into a one-file stdlib-only script so nobody has to hand-edit SQLite or install triggers: it finds the data dir on its own (asks opencode db path first, then the usual spots on Windows, Linux and macOS), strips only the stale caller-bound keys inside reasoning and metadata nodes, keeps messages, tool calls and history untouched, writes no backups or logs unless asked, and reruns as a no-op when clean. Two deliberate differences from the trigger approach: nothing persistent is installed in the database (no schema or trigger drift to worry about on the next opencode upgrade), and it cleans all sessions in one pass instead of one thread at a time. https://gist.github.com/goainwo0/5df39ec984904d082d77e3e4da4a5a6e Verified on a copy of a 400MB-plus database (27k rows touched across 28 sessions, zero message or tool data altered, integrity check passes) plus synthetic poisoned databases with before and after assertions. Unofficial, and the linked recovery PRs would still be the real fix, but for anyone sitting on bricked sessions with history worth keeping, this restores them in place.