Muse Spark 1.3 free fails in DSH: Responses API routing / reasoning payload / default reasoning issues

[Kombuchameister]

I’m using @opencode2dsh/dsh-plugin with DeepSeek Harness (DSH). MiMo models work correctly through the same plugin, and muse-spark-1.3-contributor-free works correctly in official OpenCode, so this seems specific to the plugin’s Muse integration.

Environment

• macOS, Apple Silicon
• DSH web UI
• Plugin: @opencode2dsh/dsh-plugin
• Published npm version initially tested: 0.3.3
• Model: muse-spark-1.3-contributor-free

Issues encountered

1. Published npm 0.3.3 appears to lack the current Muse Responses API routing

With the published npm package, Muse Spark 1.3 failed with a generic server error, while MiMo worked.

Inspecting the installed package:

grep -RniE 'muse-spark|openai-responses' \
  ~/.dsh/profiles/web/node_modules/@opencode2dsh/dsh-plugin \
  | head -50

only showed:

catalog-....js: "muse-spark-1.2-contributor-free"

and no openai-responses implementation.

Current master, however, contains explicit routing of muse-spark-* through openai-responses. After cloning master, building it and installing the local tarball, Muse progressed past the original server error.

This suggests the npm 0.3.3 artifact may be behind the current source despite having the same version number.

---

2. Muse is routed through /responses, but reasoning effort is serialized in the Chat Completions format

After installing current master, selecting an explicit reasoning level such as Minimal produced:

OpenAI API error (400):
{
  "param": "reasoning_effort",
  "type": "invalid_request_error",
  "message": "... unknown parameter 'reasoning_effort'"
}

The relevant code in ZenAdapter.#eventsFor() applies:

reasoning_effort: effortWire

to all models.

That appears correct for Chat Completions models, but Muse is now routed through the OpenAI Responses API, which expects the nested form:

{
  "reasoning": {
    "effort": "minimal"
  }
}

rather than:

{
  "reasoning_effort": "minimal"
}

I locally patched the adapter so Responses models receive:

reasoning: {
  effort: effortWire,
}

while Chat Completions models continue to receive:

reasoning_effort: effortWire

After this patch, explicit Muse reasoning levels such as Minimal/High work.

---

3. Default / disabled reasoning still sends an unsupported "none" value

There is a separate issue with the default reasoning setting. Muse Spark 1.3 rejects "none":

OpenAI API error (400):
{
  "param": "reasoning.effort",
  "type": "invalid_request_error",
  "message": "... reasoning_effort 'none' is not supported for model 'muse-spark-1.3-contributor'. Supported values: [minimal, low, medium, high, xhigh, max]"
}

The plugin currently maps:

off -> none

which may work for some Zen models, but Muse Spark 1.3 does not support none.

For Muse/Responses models, I think the safe behavior would be:

• explicit minimal/low/medium/... → send reasoning: { effort: ... }
• default/no selection → omit the reasoning effort entirely and let the provider choose its default
• off → either not offer it for Muse, or map it to a valid Muse-specific behavior rather than sending none

The current model metadata already appears to know Muse’s valid ladder (minimal through xhigh/max), so ideally Off should not be exposed for this model at all if upstream does not support it.

Why this seems plugin-specific

• muse-spark-1.3-contributor-free works in official OpenCode.
• MiMo works in DSH using the same opencode2dsh installation.
• Muse works in DSH after locally fixing the Responses API reasoning payload.
• Explicit reasoning levels work after the patch; only default/off handling remains broken.

Suggested fix

In ZenAdapter.#eventsFor(), distinguish Responses models from Chat Completions models when injecting reasoning:

if (responsesModel) {
  // Do not send "none" for Muse.
  if (effortWire === 'none') {
    return base
  }

  return {
    ...base,
    reasoning: {
      ...(typeof base.reasoning === 'object' && base.reasoning !== null
        ? base.reasoning
        : {}),
      effort: effortWire,
    },
  }
}

return {
  ...base,
  reasoning_effort: effortWire,
}

Also, it may be worth publishing a new npm version containing the current master Muse /responses routing, since the published 0.3.3 package I initially installed did not appear to contain it.