providers: documented openai-compatible/responses package fails with "Cannot find package '@opencode/ai'"

Summary

The documented native provider package @opencode/ai/providers/openai-compatible/responses cannot be used: setting it as a provider package fails with Cannot find package '@opencode/ai'. The equivalent Responses route is present in the CLI binary, so this looks like a missing package-specifier registration rather than missing implementation.

Environment

• opencode version: 2.0.7
• OS: Linux 7.0.0-31-generic (Ubuntu, x86_64)
• Terminal: TERM=xterm-256color, COLORTERM=truecolor
• Shell: /bin/bash
• Install/channel: latest (npm @opencode/cli 2.0.7; 2.0.7 is the latest published)
• Active plugins: oh-my-opencode-slim@2.2.18

Reproduction

1. Define a custom provider whose package is the documented OpenAI-compatible Responses package, pointing at any OpenAI-compatible base URL:

   {
     "providers": {
       "myprovider": {
         "name": "My Provider",
         "package": "@opencode/ai/providers/openai-compatible/responses",
         "settings": { "baseURL": "https://<gateway>/v1" },
         "models": { "mymodel": { "name": "My Model" } }
       }
     }
   }
   

2. Run: opencode run --standalone --model "myprovider/mymodel" "hello"

3. Repeat step 1-2 with "package": "@opencode/ai/providers/openai-compatible" (chat variant).

Expected Behavior

The .../openai-compatible/responses package should load, since it is listed as a native package option in the V2 providers documentation:

@opencode/ai/providers/openai-compatible
@opencode/ai/providers/openai-compatible/responses

and @opencode/ai@2.0.7 ships dist/providers/openai-compatible-responses.js, resolvable through the package's "./*" export.

Actual Behavior

{"type":"error","error":{"type":"provider.no-route","message":"Cannot initialize myprovider/mymodel: Cannot find package '@opencode/ai' imported from /$bunfs/root/chunk-k2dm7gzx.js"}}

The chat variant (.../openai-compatible) loads and works. The flat spelling @opencode/ai/providers/openai-compatible-responses fails identically.

Additional Context

Control test — registration membership determines the outcome

Same model, same config, only package changed:

package value	present in binary's providers/* table	result
.../openai/responses	yes	works
.../google-vertex/responses	yes	module loads, then provider-specific error "Google Vertex Responses does not support API keys"
.../openai-compatible/responses	no	Cannot find package '@opencode/ai'
.../openai-compatible/chat	no	identical error
.../does-not-exist	no	identical error

Registered specifiers load and fail only inside their own configure() logic. Unregistered specifiers produce one identical generic error, consistent with falling through to a real import of the package root @opencode/ai, which is not resolvable at runtime.

The binary appears to register specifiers, but omits this one

opencode.exe (2.0.7) contains a contiguous table of @opencode/ai/providers/* specifiers starting near offset 89705612. Exact fixed-string counts over the full binary:

specifier	hits
providers/openai-compatible	7
providers/openai/responses	2
providers/google-vertex/responses	2
providers/openai-compatible/responses	0
providers/openai-compatible/chat	0

The Responses route implementation is bundled

Near offset 172936080 the binary contains the route source:

var x="openai-compatible-responses",j=nt.make({id:x,providerMetadataKey:"openresponses",protocol:oa,endpoint:Ot(n0),transport:A...})

and the chunk registry maps file:///$bunfs/root/chunk-9492jz16.js to openai-compatible-responses. So the implementation ships; only the config-facing package name seems unregistered.

No alternative selector

The V2 providers documentation mentions protocol 0 times; the only mechanism for choosing a runtime package is the package field. There is no documented way to select the Responses route through the openai-compatible entry.

Impact / workaround

Any user following the docs to wire an OpenAI-compatible provider to a /responses endpoint hits a hard provider-init failure. Workaround that works: use @opencode/ai/providers/openai/responses with the custom baseURL, which initializes and drives /v1/responses correctly (verified store, include: ["reasoning.encrypted_content"], and nested reasoning.effort all accepted by the gateway).

Frequency

Reproducible consistently.

Disclosure

This report was generated by an LLM agent and reviewed by a human before submission.

• Agent/model: orchestrator agent running deepseek-v4.1-flash (provider opencode-go) under the oh-my-opencode-slim@2.2.18 plugin, in opencode v2.0.7
• All commands and outputs above were executed locally on the reporter's machine; results should be verified independently.

Start with the V2 providers documentation, the custom provider package field, and the binary's providers/* registration table; reproduce the documented openai-compatible/responses configuration with the supplied opencode run command. Compare its registration with the working openai/responses and chat variants. Done means the documented Responses package loads and reaches its route instead of producing the generic missing-package error.