fix(provider): route OpenCode Go Luna through Responses

[Ingwannu]

Summary

• route the built-in opencode-go/gpt-5.6-luna model through the OpenAI Responses adapter
• preserve explicit modelAdapters precedence and keep sibling OpenCode Go models on their existing wires
• add resolver and end-to-end upstream-path regressions
• document the mixed-wire decision and the separate streaming-policy boundary

Root cause

OpenCode Go documents GPT 5.6 Luna at /zen/go/v1/responses, but the built-in provider had only the provider-wide openai-chat adapter. Without an explicit user override, Luna therefore reached /chat/completions.

The registry now supplies one exact-model default:

modelWireDefaults: {
  "gpt-5.6-luna": "openai-responses",
}

An explicit allowed modelAdapters entry still wins. No provider-wide adapter or sibling model behavior changes.

Streaming scope

This PR deliberately does not set modelResponsesUpstreamStreaming: false. The endpoint mismatch is proven on current dev and in OpenCode Go's published endpoint matrix. The conditional terminal-delivery report in #1482 does not include a current-dev live canary, so a built-in bounded-JSON policy should remain a separate evidence-backed change.

Validation

• OpenCode Go endpoint matrix rechecked: Luna uses /zen/go/v1/responses
• focused routing/registry/E2E tests: 51 passed
• bun run typecheck: passed
• bun run privacy:scan: passed
• documentation build: 265 pages built
• full suite: 10,961 passed, 11 skipped; the initial clean-worktree run had 6 GUI import errors before the suite's own GUI dependency install, one timing-sensitive bridge failure under a 3-core CPU cap, and one existing host-specific codex-shim token-path failure
  • all GUI-dependent files passed after the suite installed GUI dependencies
  • the bridge lifecycle file passed on rerun
  • the unchanged codex-shim test remains host-specific: it reads this host's persisted service-token path instead of the test's temporary OPENCODEX_HOME; none of this PR's files overlap that subsystem

Documentation

The transport SOT records why the exact-model registry default was chosen over a provider-wide switch or an unproven streaming workaround. The public provider configuration reference now names the OpenCode Go Luna default and the explicit override boundary.

Addresses #1482.

Summary by CodeRabbit

• New Features

  • OpenCode Go’s GPT 5.6 Luna model now automatically uses the Responses interface.
  • Other OpenCode Go models continue using the existing Chat interface.
  • Explicit model configuration overrides remain supported.
  • Streaming behavior is unchanged.

• Documentation

  • Added guidance on model-specific interface defaults and override behavior.

• Tests

  • Added coverage for Luna’s default interface, overrides, other models, and request routing.

[coderabbitai]

📝 Walkthrough

Walkthrough

OpenCode Go now routes gpt-5.6-luna through openai-responses by default. Explicit adapters and other model defaults remain unchanged. Tests and documentation cover routing precedence, endpoint selection, and streaming.

Changes

OpenCode Go Luna routing

Layer / File(s)	Summary
Registry wire default src/providers/registry.ts	The registry routes gpt-5.6-luna through openai-responses while preserving the provider-wide openai-chat default and explicit modelAdapters overrides.
Routing validation and documentation tests/opencode-go-luna-wire.test.ts, docs-site/src/content/docs/reference/configuration/providers.md, structure/04-transports-and-sidecars.md	Tests cover Luna, non-Luna models, explicit Chat overrides, the /v1/responses endpoint, and unchanged streaming. Documentation describes the mixed-wire defaults and precedence rules.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Client
  participant OpenCodeGo
  participant ProviderRegistry
  participant ResponsesEndpoint
  Client->>OpenCodeGo: Request gpt-5.6-luna
  OpenCodeGo->>ProviderRegistry: Resolve model wire
  ProviderRegistry-->>OpenCodeGo: openai-responses
  OpenCodeGo->>ResponsesEndpoint: POST /v1/responses
  ResponsesEndpoint-->>Client: Streaming response

Loading

Possibly related issues

• lidge-jun/opencodex#1482 — The change adds the model-specific gpt-5.6-luna routing described by the issue.

Possibly related PRs

• lidge-jun/opencodex#808 — Both changes add model-specific openai-responses routing while preserving explicit adapter overrides.
• lidge-jun/opencodex#889 — Both changes implement provider model wire defaults with provider-wide fallback behavior.
• lidge-jun/opencodex#746 — Both changes add per-model wire defaults in src/providers/registry.ts.

Suggested labels: review-ready

Suggested reviewers: lidge-jun

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes routing the OpenCode Go Luna model through the Responses adapter, which is the main change.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch agent/fix-1482-opencode-luna-responses

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

✅ Deterministic PR hygiene checks passed.

[Wibias]

Reviewed the scoped OpenCode Go Luna wire correction. I did not find an additional blocker in this head: the exact-model registry default uses the existing mixed-wire precedence, explicit modelAdapters still wins, and sibling models remain on their existing wire.

The separate terminal-delivery problem described in #1482 is intentionally not solved here, so #1482 should remain open for that work. I am not approving this head because it is currently not mergeable against the latest dev; rebase/resolve conflicts and request re-review.

[Wibias]

Thanks @Ingwannu for the focused fix. This is useful because GPT-5.6 Luna on OpenCode Go now reaches its correct Responses endpoint without changing the wire for sibling models or overriding explicit user configuration. Keeping the endpoint correction separate from the still-unproven streaming workaround also avoids baking in unnecessary compatibility behavior. Merged, thank you!