[Feature]: OpenAI-compatible provider by base URL

[euguk]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Not sure

Problem or use case

I am running OpenCode app, not CLI. CLI is not compatible with my mid-2012 15" Retina MacBook Pro.
It would be great if one could connect to OpenCode Zen (and others) via OpenAI-compatible provider by base URL.
Thanks very much.

Proposed solution

Add a feature of provider connection via OpenAI-compatible provider by base URL.

Why this matters

I believe it matters to many existing and potential new users.

Smallest useful scope

Add a feature of provider connection via OpenAI-compatible provider by base URL.

Alternatives considered

No response

Risks or tradeoffs

No response

Examples or references

No response

Contribution

• I would be open to helping implement this.

[tianyiswufeng]

Two things that may unblock you today and one that won't.

Per-provider env vars already exist (Settings → the provider → Environment variables). The Claude driver documents a full base-URL override in docs/user/providers-claude.md ("I Want To Use OpenRouter"): ANTHROPIC_BASE_URL + ANTHROPIC_AUTH_TOKEN + an empty ANTHROPIC_API_KEY, token marked sensitive. That covers any Anthropic-compatible endpoint. docs/user/providers-codex.md has the same pane on the Codex side, but it doesn't name an OpenAI base-URL variable, so that path needs experimenting.

For OpenCode Zen the route would be the OpenCode provider with your own opencode.json — currently broken by #4239: T3 starts the subprocess with OPENCODE_CONFIG_CONTENT="{}", so custom providers/models never appear. Worth subscribing there.

One thing to flag on "OpenCode app, not CLI": T3 Code drives the CLI — it spawns opencode serve as a subprocess (apps/server/src/provider/opencodeRuntime.ts) — so that lane needs a working opencode binary on the machine either way.