Qwen3.5 series models fail with 'System message must be at the beginning' error in v0.9.14

[allanchan339]

Issue

After updating from v0.9.2 to v0.9.14, Qwen3.5 series models (e.g., Qwen3.6 plus, Qwen3.5 27B) throw the error:

Reproduction Steps

1. Use oh-my-opencode-slim v0.9.14
2. Configure a Qwen3.5 series model
3. Run opencode

Expected Behavior

System prompt should be placed at the beginning of the message array.

Actual Behavior

System prompt appears to be placed incorrectly, causing the error.

Workaround

Removing the plugin resolves the issue immediately.

Suggestion

Please check if the system prompt is being inserted at the correct position in the message array for Qwen3.5 models.

[ReqX]

This is the same stale cache issue as #301 — see @allanchan339's investigation there. Clearing the cache fixes it:

CACHE_ROOT="${XDG_CACHE_HOME:-$HOME/.cache}/opencode"
rm -rf "$CACHE_ROOT"

Then restart opencode. PRs #289 and #292 fixed the auto-update logic going forward, but machines stuck with a broken cache from before those fixes still need a one-time manual cleanup.

PS: Leaving open for now in case there's a different issue after clearing the cache.

Edit: oh wow, missed you linked the issue yourself lol :)

[allanchan339]

This is the same stale cache issue as #301 — see @allanchan339's investigation there. Clearing the cache fixes it:

CACHE_ROOT="${XDG_CACHE_HOME:-$HOME/.cache}/opencode"
rm -rf "$CACHE_ROOT"

Then restart opencode. PRs #289 and #292 fixed the auto-update logic going forward, but machines stuck with a broken cache from before those fixes still need a one-time manual cleanup.

PS: Leaving open for now in case there's a different issue after clearing the cache.

Edit: oh wow, missed you linked the issue yourself lol :)

No, two issue are not the same. And two issues are raised by me.

Cleaning cache can only fix update issue #301. The system prompt leak still exist in this repo so that jinja template throw error. It is specially critical for qwen series as qwen training puts system prompt at the top with strict supervision.

[ReqX]

You're right, I was wrong to dismiss this as a cache issue. My apologies @allanchan339.

I traced it through both codebases and this is a real bug, not related to #301.

Root cause: two-part chain.

1. slim hooks push multiple entries into output.system[]:

• todo-hygiene.ts pushes a todo reminder
• post-file-tool-nudge/index.ts pushes a file tool nudge

So the system array goes from ["orchestrator prompt"] to ["orchestrator prompt", "todo reminder", "file nudge"].

2. OpenCode core (session/llm.ts) converts each array element to a separate system message:

...system.map((x): ModelMessage => ({
  role: "system",
  content: x,
}))

Before hooks run, everything is joined into one string. But after hooks push new entries, OpenCode sends 3 separate system messages to the API. This works for most providers (OpenAI, Anthropic) but Qwen3.5 rejects multiple system messages.

This is also a design gap in OpenCode's hook contract: it does not document that output.system should stay single-element, and it does not defensively merge after hooks return. The most practical fix is on slim's side though.

Fix: Collapse the system array back to one element at the end of the system.transform hook:

output.system = [output.system.join('\n\n')];

PR: #336

[Pinockel]

Unfortunately, I'm still seeing the error in version 1.0.0.
I'm running Qwen3.6-35B-A3B with VLLM as the engine behind a Litellm proxy.

When I disable OMO Slim, it works.

[ReqX]

Root cause found. PR #336's fix is a no-op due to JS reference semantics.

The collapse at src/index.ts:724-725 does this:

const joined = output.system.join('\n\n');
output.system = joined ? [joined] : [];

This reassigns the property on the output object, but OpenCode core (session/llm.ts:114-118) passes the system array as { system }, a local const that still points to the original array object after the hook returns. The core then reads that local system variable at lines 120, 144, and 153 (system.map(x => ({ role: "system", content: x }))), completely bypassing our replacement.

Result: multiple system messages still get sent to the API. Providers like Qwen via VLLM (strict Jinja2 chat template) reject them.

Fix: mutate the original array in-place instead of replacing it:

const joined = output.system.join('\n\n');
output.system.length = 0;
if (joined) output.system.push(joined);

This modifies the same array object the core holds a reference to. Will have a PR up shortly.

@Pinockel, thanks for the report. This confirms the issue is real and was not fixed in v1.0.0.

[ReqX]

@mumuyizhou reported still seeing multiple system messages with Qwen on OMO-Slim 1.0.1 (dev).

Quick question — could you check which commit you're on?

git log --oneline -1

The fix landed in 345c06b on master, which sits on top of the 1.0.1 version bump — so even with the latest master, it still shows as 1.0.1. If you're on 65cba43 or earlier, the fix isn't in your build.

If you are on 345c06b and still seeing multiple system messages, could you have your agent run through these checks? (or check yourself ;-))

Debug why multiple system messages still reach Qwen. Step by step:

1. Verify the fix is in place: check that src/utils/system-collapse.ts 
   exists and collapseSystemInPlace(output.system) is called in the 
   experimental.chat.system.transform hook in src/index.ts around line 725.

2. If the fix IS there, add temporary logging. In src/index.ts, right 
   before the collapseSystemInPlace call (~line 725), add:
     console.log('[OMO-DEBUG] before collapse:', output.system.length, output.system.map(s => s?.substring(0, 80)))
   And right after:
     console.log('[OMO-DEBUG] after collapse:', output.system.length)

3. If the fix is NOT there or the file doesn't exist, report what commit 
   is checked out and whether there are any other plugins in the 
   opencode.jsonc that might also push to output.system.

After the agent adds the logs (or you do), rebuild and restart OpenCode (bun run build, then restart), trigger a Qwen call, and share the [OMO-DEBUG] lines from the output. That'll tell us exactly where things stand.

I don't have a Qwen setup to test with, so this would really help narrow it down 🙏