Skip to content

fix(providers): correct opencode-zen muse-spark context length and Responses auth header (#12681, #12633) - #13247

Merged
diegosouzapw merged 1 commit into
release/v3.8.51from
fix/12681-opencode-registry
Sep 12, 2026
Merged

diegosouzapw merged 1 commit into
release/v3.8.51from
fix/12681-opencode-registry

Conversation

@diegosouzapw

Copy link
Copy Markdown
Owner

Summary

Two related, small OpenCode Zen registry/executor bugs fixed together (both files: open-sse/config/providers/registry/opencode/zen/index.ts / open-sse/config/providers/registry/opencode/index.ts for #12681, open-sse/executors/opencode.ts for #12633):

Closes #12681
Closes #12633

#12681 — wrong context_length for Muse Spark 1.2 (200000 vs real ~1M)

Root cause: muse-spark-1.2 and muse-spark-1.2-contributor-free were declared in the opencode and opencode-zen registry entries without their own contextLength — unlike sibling models in the same list. With no per-model window, contextManager.resolveTokenLimit() fell back to the provider-wide defaultContextLength: 200000.

Fix: declared the real window (contextLength: 1048576, maxOutputTokens: 131072) on both Muse Spark 1.2 entries in both files. This value is not invented — it mirrors the same model family already declared correctly on opencode-go's muse-spark-1.2-contributor* entries (open-sse/config/providers/registry/opencode/go/index.ts), which are exercised by existing tests (tests/unit/opencode-go-catalog-alignment.test.ts).

Regression test: tests/unit/issue-12681-opencode-muse-spark-context.test.ts

  • RED (before fix): muse-spark-1.2/-contributor-free had contextLength === undefined in both registries; getTokenLimit("opencode", "muse-spark-1.2-contributor-free") resolved to 200000.
  • GREEN (after fix): both entries declare contextLength: 1048576; getTokenLimit() resolves to 1048576 on both opencode and opencode-zen.

Note: the plan-file also flagged a second, architecturally larger bug — vendor-prefixed passthrough ids reached through nous-research/kilocode (e.g. poolside/laguna-s-2.1) not cross-referencing the vendor's own registry entry in contextManager.resolveTokenLimit(). That is a separate, larger design change (a new cross-reference resolution step) that is out of scope for this small, TDD-scoped fix and is not addressed here.

#12633 — OpenCode Zen Responses models reject the OmniRoute auth header

Root cause: OpencodeExecutor.buildHeaders() only special-cased x-api-key for _requestFormat === "claude"; every other format — including "openai-responses", used by Muse Spark Contributor models routed to /v1/responses — fell through to Authorization: Bearer <key>. OpenCode Zen's /v1/responses endpoint actually requires x-api-key, matching the reporter's live upstream 401.

Fix: added a usesZenApiKeyAuth() helper that also emits x-api-key when _requestFormat === "openai-responses" and the executor's baseUrl is the main Zen host (https://opencode.ai/zen/v1, shared by the opencode and opencode-zen registry entries). Scoped by baseUrl rather than provider id/alias so opencode-go — a separate upstream (https://opencode.ai/zen/go/v1) that already works with Bearer for its own Responses-routed models (grok-4.5, deepseek-v4-pro, muse-spark-1.2-contributor) — is unaffected.

Regression test: tests/unit/issue-12633-opencode-zen-responses-auth.test.ts

  • RED (before fix): openai-responses format on opencode/opencode-zen sent Authorization: Bearer, no x-api-key.
  • GREEN (after fix): both send x-api-key, no Authorization; opencode-go (negative control, different upstream) still correctly sends Authorization: Bearer; claude format behavior unchanged.

Scope note: the plan-file's open "Scope Question" (is x-api-key required only for Muse Contributor, or every Zen Responses model?) is answered by scoping to the whole Zen host rather than guessing per-model — any current or future model routed to openai-responses on the main Zen host now gets the correct header, without touching opencode-go. The plan-file's secondary checkbox (adding muse-spark-1.3/muse-spark-1.3-contributor-free registry entries) is not included here — that model's real capability metadata is unconfirmed and is already the subject of a separate open contributor PR (#12675, opencode-go's 1.3 registration), so adding it here as well would risk a conflicting/duplicate registration.

Gates run

  • node --import tsx/esm --test tests/unit/issue-12681-opencode-muse-spark-context.test.ts tests/unit/issue-12633-opencode-zen-responses-auth.test.ts — 7/7 pass
  • Existing area tests (buildHeaders, target-format, muse-spark routing/output, opencode-go catalog alignment, account rotation, ambient proxy, stream payload collector, etc. — ~289 tests across 24 files) — all pass, unchanged
  • node scripts/check/check-file-size.mjs — OK
  • node scripts/check/check-complexity.mjs — OK (2798 vs baseline 3218)
  • node scripts/check/check-cognitive-complexity.mjs — OK (1265 vs baseline 1437)
  • npm run typecheck:core — exit 0
  • npx eslint --suppressions-location config/quality/eslint-suppressions.json <changed files> — exit 0
  • node scripts/check/check-changelog-integrity.mjs — OK

⚠️ base-red inherited: #12732 — unit #12058, integration codex-cache, package-artifact, tarball-smoke, agent-skills-sync

…sponses auth header (#12681, #12633)

- Declare the real ~1M contextLength/maxOutputTokens on the muse-spark-1.2 /
  muse-spark-1.2-contributor-free registry entries (opencode + opencode-zen)
  instead of silently falling back to the 200000 provider default (#12681).
- Send x-api-key instead of Authorization: Bearer for the openai-responses
  format on the main OpenCode Zen host, fixing a 401 on Muse Spark
  Contributor's /v1/responses route; scoped by baseUrl so opencode-go (a
  different upstream) keeps Bearer (#12633).
@diegosouzapw
diegosouzapw merged commit 954f12b into release/v3.8.51 Sep 12, 2026
15 of 21 checks passed
Githab-capibara added a commit to Githab-capibara/OmniRoute that referenced this pull request Sep 17, 2026
…sponses auth header (diegosouzapw#12681, diegosouzapw#12633) (diegosouzapw#13247)

Merged as part of the 39-PR owner batch of 2026-09-11, validated as a unit.

Boarded into one consolidated worktree cut from `release/v3.8.51` with the other 38 — zero conflicts between them.

- ESLint over every changed file: no errors (the only finding was one suppression entry the batch emptied, pruned on diegosouzapw#13243)
- `typecheck:core` clean; `check:dashboard-typecheck` OK (206 pre-existing, within baseline); `check:changelog-integrity` OK
- complexity 2821 / baseline 3218 and cognitive-complexity 1272 / baseline 1437 — both under baseline
- 256 assertions green: 246 under node:test and 10 under vitest, which is where `tests/unit/**/*.test.tsx` actually runs
- `check-file-size`: `chatCore.ts` rebaselined 6144 → 6146 for diegosouzapw#13278 and diegosouzapw#13276, annotated and landed on diegosouzapw#13243

⚠️ base-red inherited: diegosouzapw#12732 — the provider count (356 in the docs vs the 358 the modules define) and `open-sse/utils/stream.ts` at 3115 > frozen 3098 both reproduce on the pure tip with zero contribution from this batch.
muhamadgalihsaputra pushed a commit to niyatna/NiyatnaRoute that referenced this pull request Sep 27, 2026
…sponses auth header (diegosouzapw#12681, diegosouzapw#12633) (diegosouzapw#13247)

Merged as part of the 39-PR owner batch of 2026-09-11, validated as a unit.

Boarded into one consolidated worktree cut from `release/v3.8.51` with the other 38 — zero conflicts between them.

- ESLint over every changed file: no errors (the only finding was one suppression entry the batch emptied, pruned on diegosouzapw#13243)
- `typecheck:core` clean; `check:dashboard-typecheck` OK (206 pre-existing, within baseline); `check:changelog-integrity` OK
- complexity 2821 / baseline 3218 and cognitive-complexity 1272 / baseline 1437 — both under baseline
- 256 assertions green: 246 under node:test and 10 under vitest, which is where `tests/unit/**/*.test.tsx` actually runs
- `check-file-size`: `chatCore.ts` rebaselined 6144 → 6146 for diegosouzapw#13278 and diegosouzapw#13276, annotated and landed on diegosouzapw#13243

⚠️ base-red inherited: diegosouzapw#12732 — the provider count (356 in the docs vs the 358 the modules define) and `open-sse/utils/stream.ts` at 3115 > frozen 3098 both reproduce on the pure tip with zero contribution from this batch.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant