[CarmeloCampos]

What

Fix the responses protocol. src/index.ts registered
@opencode/ai/providers/openai-compatible/responses; the compiled OpenCode
bundle does not contain that subpath, so model init failed with:

Cannot initialize cliproxyapi/gpt-5.6-luna: Cannot find package '@opencode/ai' imported from /$bunfs/root/chunk-6mdchvy2.js

The provider and model were listed in /models and selectable, so the failure
only appeared on the first prompt, and only with protocol: "responses".
protocol: "chat" was unaffected.

Fixes #1.

Change

-const RESPONSES_PACKAGE = "@opencode/ai/providers/openai-compatible/responses"
+const RESPONSES_PACKAGE = "@opencode/ai/providers/openai/responses"

Plus a comment explaining that OpenCode resolves these names from inside its own
bundle, so only bundled subpaths are importable, and the corresponding
assertion in src/index.test.ts.

Why this target

• @opencode/ai/providers/openai/responses is in the bundle (opencode --version 2.0.15, Linux x64).
• It is the same protocol OpenAI uses for GPT-5 reasoning models, so it matches
  a Responses-compatible endpoint.
• The nested path does exist in the published @opencode/ai tarball and
  resolves from a plugin's own node_modules, which is why the original code
  looks correct in isolation. It only breaks at model init inside the compiled
  CLI.

Verification

bun run check on this branch: 22 tests pass, build and tsc --emitDeclarationOnly clean.

End-to-end against a live CLIProxyAPI, using a capture proxy in front of
/v1 to record requests:

package registered	result
@opencode/ai/providers/openai-compatible/responses (before)	Cannot find package '@opencode/ai'; only GET /v1/models recorded
@opencode/ai/providers/openai-compatible-responses	same failure
@opencode/ai/providers/openai/responses (this PR)	prompt answered; POST /v1/responses recorded

Confirmed on two models (gpt-6-luna, gemini-3.7-flash-high) through the
patched plugin, with /v1/responses receiving the traffic.

Notes

The Responses facade here is generic (openai-compatible-responses route
semantics) rather than OpenAI-specific: it still uses the provider's own
baseURL and bearer token from plugin options, so nothing about the endpoint
becomes OpenAI-only. The OpenAI gpt-5* default options that come with that
facade (store: false, reasoning.encrypted_content) match CLIProxyAPI's
stateless Responses usage.

[moutansos]

Thanks for the fix!