Opencode Zen critical errors on Muse Spark family when model recieves a image/does a tool call

Description

Error: Error from provider (Console): Upstream request failed: [invalid_request_error] reasoning encrypted_content was not issued to this caller when requesting any Muse Spark model on Zen.

Plugins

None

OpenCode version

0.0.0-beta-18050

Steps to reproduce

Make a request to any Muse Spark model, and attach a image or get it to read a file.

Screenshot and/or share link

Operating System

Windows 11 25H2, build 26200.9445

Terminal

Windows Terminal

This also affects OpenCode version 1.18.30

https://opncd.ai/share/CGqRyjoi

I have confirmed that this is a Zen upstream issue, and is not local.

On some responses, I experience this issue, however some are succeeding right now

so far can't reproduce...

I am also getting same error right now. opencode v1.18.30

Still reproduces on 1.18.30, OpenCode Desktop, Windows 11.

model: muse-spark-1.3-contributor-free via Console (Zen), Meta Muse Spark
session ses_f669f220cffeXi8TfKAMDScGtv, first fail 2026-09-13T06:20:52Z, then sticky on every retry in the same session
error: Error from provider (Console): Upstream request failed: [invalid_request_error] reasoning 'encrypted_content' was not issued to this caller
other model (Mimo) works fine in the same setup

Filtered excerpt from ~/.local/share/opencode/log/opencode.log for this session attached

muse-spark-encrypted-content-ses_f669f220.txt

I am getting it on arch linux, with muse. And it's effecting old chats too. On 1.18.29.

started for me too same windows on OpenCode 1.18.30. Same error: Error from provider (Console): Upstream request failed: [invalid_request_error] reasoning encrypted_content was not issued to this caller

also here, it happens when resuming a session. But not with new sessions.

Getting same error on Muse Spark 1.3 free. Using OpenCode Desktop on Windows, and using ACP with Zed Editor (also on Windows). Same problem.
Fixed by creating new session, but even on this new session it will have this problem again so I can't have long sessions.

On session that faces this issue, can change model and it will continue to work (can't use muse spark anymore there though)

I have the same issue. NixOS, 1.18.30.

same here. windows 10 LTSC

Version: 1.18.30 (latest)
Date: 2026-09-13T15:01:08.385Z
OS: Linux 5.15.153.1-microsoft-standard-WSL2 (x64)
Terminal: xterm-256color
Session ID: ses_f64ffe89bffe45X3BTcCwd09lP
Model: opencode/muse-spark-1.3-contributor-free

Same root cause as #43557: after a restart, OpenCode replays the stale reasoning.encrypted_content blob (bound to the previous caller/key) and upstream rejects it with not issued to this caller. New chats work because they carry no stale blob.

I wrote a shim plugin that strips blobs older than the current server process before each request, keeping text summaries: https://github.com/unurgunite/opencode-sanitize-reasoning

My dead chats work again from the first message. Proper fix still belongs in core (drop + retry without the blob on invalid_encrypted_content).

It is not happening with opencode-go/muse-spark-1.3-contributor, only opencode/muse-spark-1.3-contributor-free. It's not happening when you use a particular thread continuously. Whenever you just idle it for 3 minutes or 5 minutes, the next chat will get this error.

Same root cause as #43557: after a restart, OpenCode replays the stale reasoning.encrypted_content blob (bound to the previous caller/key) and upstream rejects it with not issued to this caller. New chats work because they carry no stale blob.

I wrote a shim plugin that strips blobs older than the current server process before each request, keeping text summaries: https://github.com/unurgunite/opencode-sanitize-reasoning

My dead chats work again from the first message. Proper fix still belongs in core (drop + retry without the blob on invalid_encrypted_content).

Thank you for the workaround. Testing using ACP on Zed Editor. It fixed my old sessions However the next error will still happen, I tried two attempts and both failed, same error message. In which case I need to restart opencode and the session will work again until the next error.

Same root cause as #43557: after a restart, OpenCode replays the stale reasoning.encrypted_content blob (bound to the previous caller/key) and upstream rejects it with not issued to this caller. New chats work because they carry no stale blob.
I wrote a shim plugin that strips blobs older than the current server process before each request, keeping text summaries: unurgunite/opencode-sanitize-reasoning
My dead chats work again from the first message. Proper fix still belongs in core (drop + retry without the blob on invalid_encrypted_content).

Thank you for the workaround. Testing using ACP on Zed Editor. It fixed my old sessions However the next error will still happen, I tried two attempts and both failed, same error message. In which case I need to restart opencode and the session will work again until the next error.

Thanks for testing — very useful. The recurring in-session failure you describe (works after restart, then fails again) I can't reproduce on my side — mine fails strictly after restart. That points to a separate short-TTL / key-rotation path on the -free tier, possibly ACP/Zed-specific. If you get a chance, please share: OpenCode version, exact model, roughly how long between "works after restart" and "fails again" (idle or active?), and whether stripped N stale reasoning blob(s) lines appear in the log when it recovers. With that I can look at a max-age rule on top of the restart rule. No promises for now though — the plugin stays restart-only until there's reproducible data.

v2.0.3

Others have said the issue only occurs on continued sessions, and resolves with new sessions, but I have not seen this. On a continued session it dies immediately, and on a new session it seems to die consistently at first tool/task call, then be unrecoverable beyond first failure.

The failure also seems to extend to Spark 1.2 as well (though less frequent).

If you get a chance, please share: OpenCode version, exact model, roughly how long between "works after restart" and "fails again" (idle or active?), and whether stripped N stale reasoning blob(s) lines appear in the log when it recovers. With that I can look at a max-age rule on top of the restart rule. No promises for now though — the plugin stays restart-only until there's reproducible data.

Getting accurate timestamp would be difficult since I use it to make games. Switching between coding and editing scene manually and playing the game. Which took quite a bit of time.
Here error happened on 1:06AM, 1:56AM, 2:33AM, will be updated when it happened again. GMT+7 Bangkok Time.

Opencode Version 1.18.30 (cli, I assume it's the one used by ACP)

I am not sure about what is stripped N stale reasoning blob(s) But all of the Thinking section don't disappear. The red error disappear on restart though. In the screenshots below, the error happened in the mouse cursor position. The Thinking before these don't disappear.

Click here to see screenshot

Sorry if the information is not what you are looking for.
The workaround is good enough for me, if error happened, restarting the program (Zed Editor and then loading OpenCode ACP) is quick and I can just --continue form where I left of. It's free model anyway.

@MrSaikatS

If you get a chance, please share: OpenCode version, exact model, roughly how long between "works after restart" and "fails again" (idle or active?), and whether stripped N stale reasoning blob(s) lines appear in the log when it recovers. With that I can look at a max-age rule on top of the restart rule. No promises for now though — the plugin stays restart-only until there's reproducible data.

Getting accurate timestamp would be difficult since I use it to make games. Switching between coding and editing scene manually and playing the game. Which took quite a bit of time. Here error happened on 1:06AM, 1:56AM, 2:33AM, will be updated when it happened again. GMT+7 Bangkok Time.

Opencode Version 1.18.30 (cli, I assume it's the one used by ACP)

I am not sure about what is stripped N stale reasoning blob(s) But all of the Thinking section don't disappear. The red error disappear on restart though. In the screenshots below, the error happened in the mouse cursor position. The Thinking before these don't disappear.

Click here to see screenshot

Sorry if the information is not what you are looking for. The workaround is good enough for me, if error happened, restarting the program (Zed Editor and then loading OpenCode ACP) is quick and I can just --continue form where I left of. It's free model anyway.

Update: I reproduced the second failure mode myself — chats die a few minutes after idle even without any restart, then a rewind ("reset to this point") revives them for exactly one turn. So there are two triggers: (1) restart, (2) short upstream TTL on the -free tier.

I pushed new version of the shim plugin adds a max-age rule on top of the restart rule: https://github.com/unurgunite/opencode-sanitize-reasoning

It now strips blobs that are EITHER older than the server process OR older than OPENCODE_SANITIZE_REASONING_MAX_AGE_MINUTES (default 3, off = restart-only as before). Text summaries are always kept.

@MrSaikatS @pegasusearl @pascalthedev — your reports match this TTL path (idle minutes / recurring in-session failures / death at first tool call). If you try v0.2.0, please report: does the idle case now succeed first try, and do stripped N stale reasoning blob(s) lines appear in the log?

@unurgunite

Confirming this on V2 (opencode 2.0.3, Windows), same model, muse-spark-1.3-contributor-free via Console. In our case the poisoned turn broke mid-tool-chain, and everything after it failed for a day: service-restart drains, fresh prompts, and compaction all hit the same 400. That's both of @unurgunite's triggers in one session.

A heads-up for anyone on 2.x trying the plugin: v0.2.0 loads cleanly on V2 but is a no-op there. It walks the V1 shapes (part.metadata.openai.* with part.time.start), while V2 puts the crypto in two other places:

persisted parts: part.state.{itemId, reasoningEncryptedContent}, timestamp at part.time.created (some of ours carry reasoningEncryptedContent: null with a bare itemId)
the context-hook payload is the AI SDK shape: crypto under part.providerMetadata.openai, and part.time is empty, so blob age is unknowable on that path

I dumped the hook payload to verify: reasoning parts arrive as {type, text, providerMetadata} with no state and time: {}. The V1 relevance check (non-empty string blob) never matches, so nothing gets stripped and the poison replays untouched. This matters for @pascalthedev's 2.0.3 report above, where new sessions die at the first tool call.

One more V2 quirk: plugin console.error does not reach opencode.log on V2. We had zero [sanitize-reasoning] log lines while the hook was verifiably firing, so the README's "look for stripped N stale reasoning blob(s)" check cannot confirm anything on V2. A file dump is the only way we could see what the hook receives.

I run a local fork with V2 support added (same TTL and kill-switch semantics, upstream's 14 tests pass unmodified): V2 holders strip on any itemId/blob key, since a bare itemId is rejected as "item not found" under store=false; no-timestamp parts fail safe to strip; and the hook registers for all model-request kinds (context/compaction/generate/title), because compaction replays the same reasoning and fails the same way. With it, the one-day-dead session replies again and a tool-call round trip through Muse Spark completes. Happy to open a PR against the plugin repo with these changes if useful.

@pompompur-in's IP-binding report matches what we can see from here: whether a request fails depends only on whether the gateway's current upstream caller is the one that issued the stored blobs. A restart is just one way to end up on a different caller.

Seems to be linked to ip in some way, I turned on and off a vpn and when it's on it was hitting the error, contacted meta I think there is a bug on their end

Same error on 1.18.30 when resuming an old Muse 1.3 session after idle (no image required). OpenCode replays stored metadata.openai.reasoningEncryptedContent and Console rejects it.

Filed with logs: #48915

This also bricks idle/resume on 1.18.30. Fix ready for review: #48918

@1837620622

For anyone still hitting this issue, I tested the fix in @1837620622's fork and it worked for me.

The fix is on branch fix/stale-encrypted-reasoning at 87dd316b3fdd8abe2b11b4e4d6594aedc7fba818 (fork dev does NOT contain the fix, it's the parent of the fix. Checkout the fix branch, not dev).

OpenAI-Responses invalid_encrypted_content / encrypted_content was not issued to this caller stale-reasoning replay. This patch adds a stale-reasoning classification and a ContinueAfterStaleReasoning single-retry that strips the stale reasoning.encrypted_content + itemId and retries once.

I can't attach a prebuilt binary (don't run a random binary you can't inspect), so build from source. You'll need bun ^1.3.14 (pinned in packageManager, I used 1.4.2):

# clone the patched fork
git clone https://github.com/1837620622/opencode.git
cd opencode

# checkout the fix branch (not dev)
git checkout fix/stale-encrypted-reasoning
# pinned hash if you want it: 87dd316b3fdd8abe2b11b4e4d6594aedc7fba818

bun install && bun dev
# bun dev = bun run --cwd packages/opencode src/index.ts, same CLI as the binary

To build your own patched binary (single-platform):

./packages/opencode/script/build.ts --single

The --single flag builds only for the current platform. Without it the script builds the full 12-target matrix (linux/darwin/windows x arm64/x64 x baseline/musl).

Install side-by-side so you can run from anywhere:

./install --binary ./packages/opencode/dist/opencode-darwin-arm64/bin/opencode

You can add a localcode function in your rc if you want running to be seamless:

# Runs the local patched build from anywhere. No args = current directory.
localcode() {
  local bin="$HOME/.opencode/bin/opencode"
  if [ $# -eq 0 ]; then
    "$bin" .
  else
    "$bin" "$@"
  fi
}

Or symlink if you prefer: ln -sf ~/.opencode/bin/opencode ~/.local/bin/localcode

@pascalthedev

if someone follows @pascalthedev 's fork tutorial, chances are that ur new build of opencode doesnt find ur old sessions.
If thats the issue, please call OPENCODE_DISABLE_CHANNEL_DB=1 opencode instead.

Thanks for the report and all the follow-ups. I couldn't reproduce this here because it needs a real OpenCode Zen account with Muse Spark access, and the rejection seems to depend on the network path (a maintainer in this thread only saw it with a VPN on). This sandbox has neither.

From the code, current dev still sends the earlier turns' encrypted reasoning back to the provider for these models, and it has no recovery when the provider rejects it. That matches the symptom here: once the error appears, the session keeps failing until you start a new one. A maintainer with Zen access will need to look at this.

Related reports of the same error, most similar first:

Error from provider (Console) #50179: same Console error, also seen on v2.0.11
Error: Upstream request failed: [invalid_request_error] reasoning encrypted_content was not issued to this caller #50397: same error after upgrading to v2
Muse Spark 1.3: resuming a session after idle fails with reasoning encrypted_content not issued to this caller #48915: triggered by resuming a session after it sat idle
[Bug] muse-spark-1.3-contributor-free: reasoning encrypted_content was not issued to this caller when switching models in same session #48805: triggered by switching models in the same session
Network interruption corrupts conversation state: reasoning encrypted_content was not issued to this caller #49083: triggered by a dropped network connection

@opencodejr you can use wgcf https://github.com/ViRb3/wgcf to create a wireguard profile that allows you to connect to Cloudflare Warp for free. (wgcf creates wireguard profiles that can be used with wg-quick up/down ... https://github.com/wireguard/wireguard-tools)

Navigation Menu

Repository navigation

Opencode Zen critical errors on Muse Spark family when model recieves a image/does a tool call #48741

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Opencode Zen critical errors on Muse Spark family when model recieves a image/does a tool call #48741

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

pompompur-in commented on Sep 13, 2026

pompompur-in commented on Sep 13, 2026

pompompur-in commented on Sep 13, 2026

rekram1-node commented on Sep 13, 2026

renhiyama commented on Sep 13, 2026

Overlordshor commented on Sep 13, 2026

AshutoshGitMirror commented on Sep 13, 2026

CoGian commented on Sep 13, 2026

fareslassoued commented on Sep 13, 2026

pegasusearl commented on Sep 13, 2026

FelipeFMAvelar commented on Sep 13, 2026

arthiccc commented on Sep 13, 2026

unurgunite commented on Sep 13, 2026

2 remaining items

MrSaikatS commented on Sep 13, 2026

pegasusearl commented on Sep 13, 2026

unurgunite commented on Sep 13, 2026

pascalthedev commented on Sep 13, 2026

pegasusearl commented on Sep 13, 2026

unurgunite commented on Sep 13, 2026

darkred1145 commented on Sep 14, 2026

rekram1-node commented on Sep 14, 2026

1837620622 commented on Sep 14, 2026

1837620622 commented on Sep 14, 2026

pascalthedev commented on Sep 14, 2026

renhiyama commented on Sep 15, 2026

opencodejr commented on Oct 28, 2026

cwegener commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions