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

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: [email protected]

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/[email protected] 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:

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:

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 [email protected] plugin, in opencode v2.0.7
• All commands and outputs above were executed locally on the reporter's machine; results should be verified independently.