Skip to content

[AISAGE-734] fix(ai-gateway): use the Responses API for OpenCode Go Muse models - #7782

Merged
chrarnoldus merged 2 commits into
mainfrom
fix/opencode-go-muse-protocol
Oct 16, 2026
Merged

chrarnoldus merged 2 commits into
mainfrom
fix/opencode-go-muse-protocol

Conversation

@chrarnoldus

@chrarnoldus chrarnoldus commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Problem

The OpenCode Go direct BYOK models opencode-go/muse-spark-1.2-contributor and opencode-go/muse-spark-1.3-contributor fail every request with:

{"type":"error","error":{"type":"ModelProtocolUnsupported","message":"Model does not support this protocol."}}

Production logs show these errors for Muse Spark and for gemini-4-argon-contributor. Every one was on /api/v1/chat/completions or the legacy /api/openrouter/chat/completions. This is unrelated to #7586.

Cause

convertModel in providers/direct-byok/index.ts calls getAiSdkProvider('opencode-go/muse-spark-…', 'opencode-go'). isMuseModel only matches meta/muse-, so the model fell through to the default (OpenRouter SDK, Chat Completions). As a result, the catalog told clients to send Chat Completions, which OpenCode Go doesn't accept for Muse.

Fix

isMuseModel now matches muse- anywhere in the model ID, so opencode-go/muse-spark-* is recognized. As a result, getAiSdkProvider returns openai, which tells clients to use the Responses API. meta/muse-* IDs still match, so gateway behavior for them doesn't change.

The other isMuseModel callers now also apply to OpenCode Go Muse models:

  • removeRecursiveToolSchemaRefs strips recursive tool schema refs, which Meta rejects.
  • getFallbackReasoningOptions returns Muse effort options (none to xhigh).
  • isPdfSupportingModel returns true.

No changes were needed in opencode-go.ts:

  • supported_chat_apis already includes responses.
  • For Responses requests, transformRequest only adds the x-opencode-session header. replaceReasoningObjectWithReasoningEffort does nothing for non-Chat-Completions requests, and x-api-key is only added for Messages. This is the same path OpenCode Go gpt-* and grok-* already use.

Evidence for the Responses API

  • OpenCode Go docs (https://opencode.ai/docs/go/, "Endpoints" table): both Muse Spark models use https://opencode.ai/inference/go/openai/v1/responses with @ai-sdk/openai. That's the same endpoint as Grok 4.7 and GPT 6/5.6 Luna.
  • models.dev (https://models.dev/api.json, provider opencode-go): muse-spark-1.2-contributor and muse-spark-1.3-contributor have provider.npm = "@ai-sdk/openai". The provider default is @ai-sdk/openai-compatible. OpenCode chooses its SDK from this field, and @ai-sdk/openai defaults to Responses.
  • Direct probe: inconclusive. Our test key (OPENCODE_GO_API_KEY) gets This Go model trains on request data. Allow paid endpoints that train on request data… on /chat/completions, /responses, and /messages. That check runs before the protocol check.
  • Prod errors: only seen on Chat Completions paths, which matches the cause above.

Not fixed: gemini-4-argon-contributor

The OpenCode Go docs and models.dev list this model only on Google's native API (https://opencode.ai/inference/go/google/v1beta/models/gemini-4-argon-contributor, @ai-sdk/google). None of our supported APIs (Chat Completions, Messages, Responses) are documented for it. I couldn't probe it either, because the test key hits the same training-consent check. This PR doesn't touch it, and it will keep failing until we either support that protocol or hide the model.

Verification

  • pnpm exec jest ../../packages/web-shared/src/lib/ai-gateway/ (from apps/web): 102 suites, 1881 tests passed. New tests:
    • getAiSdkProvider returns openai for both OpenCode Go Muse Spark models.
    • meta/muse-* through the gateway still returns openai.
    • An OpenCode Go Muse Responses request body is forwarded unchanged, gets the session header, and gets no x-api-key.
  • pnpm --filter @kilocode/web-shared typecheck: passed.
  • oxlint --config .oxlintrc.json on the changed files: 0 warnings, 0 errors.
  • oxfmt on the changed files: no changes.
  • git diff --check: clean.

Not verified end to end: there was no OpenCode Go key with training-data endpoints enabled.

@chrarnoldus chrarnoldus self-assigned this Oct 16, 2026
@kilo-code-bot

kilo-code-bot Bot commented Oct 16, 2026 •

Copy link
Copy Markdown
Contributor

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

The net change at HEAD is a one-line broadening of isMuseModel to match muse- anywhere in the model id, plus new tests; the opencode-go Muse routing fix is correct, matches the existing substring-predicate convention for model families, and introduces no memory-leak or security concerns.

Files Reviewed (2 files)
  • packages/web-shared/src/lib/ai-gateway/providers/meta.ts
  • packages/web-shared/src/lib/ai-gateway/providers/direct-byok/opencode-go.test.ts

Review Notes

  • Scope at HEAD f4bb5f895f4865a6904ac2b25af57fb7191cfbf3 is narrower than the PR narrative: model-settings.ts was changed in commit 1 and reverted in commit 2, so it is net-unchanged and out of scope.
  • isMuseModel (meta.ts:2) now returns model.includes('muse-'). The only ids in the repo containing muse- are meta/muse-* and opencode-go/muse-*, both of which correctly require the Responses API, so no live false positive exists. The substring style matches the sibling predicates (isMinimaxModel, isQwenModel, isGeminiModel, isGrokModel), so it is consistent with codebase convention.
  • getAiSdkProvider (model-settings.ts:80) now returns openai for opencode-go/muse-*, which is the intended fix; convertModel calls it with the full opencode-go/<model> id (direct-byok/index.ts:66), so the routing change actually applies.
  • The new test forwards Muse Responses requests without rewriting the body is valid: replaceReasoningObjectWithReasoningEffort returns early for non-chat_completions kinds (request-helpers.ts:384) and x-api-key is only added for messages (opencode-go.ts:23), so the assertions hold.
  • No memory leaks in the changed code (string predicate only; no timers, listeners, caches, or retained references). No security-relevant behavior in the changed lines.

Not run: Jest suite could not be executed in this read-only session; the tests were assessed statically.

Fix these issues in Kilo Cloud

Previous Review Summary

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)
  • packages/web-shared/src/lib/ai-gateway/providers/model-settings.ts
  • packages/web-shared/src/lib/ai-gateway/providers/direct-byok/opencode-go.test.ts

Reviewed the targeted fix in getAiSdkProvider (model-settings.ts:74-81). The new nested branch inside directProviderId === 'opencode-go' preserves the existing MiniMax/Qwen → anthropic behavior and only adds opencode-go/muse-* → openai; the fall-through to the Claude/OpenAI/Grok/Muse checks is unchanged, so no other provider routing regresses. The prefix matches the id produced by formatDirectByokModelId (provider id + / + lowercased model id), and meta/muse-* gateway models still route to openai via the existing isMuseModel check. opencode-go already advertises responses in supported_chat_apis, and transformRequest only rewrites Chat Completions bodies (replaceReasoningObjectWithReasoningEffort returns early for other kinds) and adds x-api-key for Messages only, so response-kind requests are forwarded with just the session header, as the new test asserts. No memory-leak or security concerns in the changed code. New tests cover both Muse models, the gateway meta/muse-* path, and the Responses body/header behavior. Note: only the diff at HEAD 685b4ea6c260a4add9569e4be578ae6b91514de2 was reviewed; I could not run the Jest suite in this read-only session, so the tests were assessed statically.


Reviewed by deepseek-v4.1-flash · Input: 62K · Output: 10.5K · Cached: 562.3K

Review guidance: REVIEW.md from base branch main

@joshburt
joshburt self-requested a review October 16, 2026 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants