[FEATURE]: Connect OpenCode to centrally managed gateway models and settings #55354

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Related discovery proposals are linked below. This request concerns the complete gateway-managed settings and session-budget integration implemented in #53713

Describe the enhancement you want to request

We would like OpenCode to connect to a model gateway using its URL and key, then pick up the models and settings offered by that gateway without requiring users to define each model again in OpenCode. We have built this with LiteLLM, but the OpenCode integration uses an OpenAI-compatible interface and a documented metadata extension that other gateways can implement as well

The problem is the gap between managing models at the gateway and using them in a coding client. A gateway administrator can already choose supplier connections and public model names, but the client still needs its own understanding of what those models support. That becomes another configuration to maintain, particularly when gateway aliases differ from the original model names or an account has a different set of available models. Adding a model centrally should make it usable in OpenCode with its reasoning choices, capabilities and limits, rather than create another round of client configuration

Our implementation connects those two sides. The gateway publishes the models available to the connected credential together with their known settings, and OpenCode uses that information for model selection and execution. This includes reasoning choices, tools and image support, the supported inference interface, and separate context, input and output limits. Gateway-selected output budgets also inform how much room OpenCode reserves before compaction. Main agents and subagents use the same model definitions, including when a subagent selects a different model

For example, an administrator could add a model, adjust its reasoning default or remove an offering at the gateway, and OpenCode would pick up the change without the user copying that definition locally. The gateway keeps control of supplier credentials, model offerings and routing, while OpenCode remains responsible for the coding session and can retain explicit local overrides. Discovery is opt-in, so other providers keep their existing behavior

The companion LiteLLM PR #45023 implements the gateway side. It gathers supplier inventories and metadata, applies central configuration, and publishes the resulting model definitions. It also supports an optional live offering configuration where an administrator can select models from supplier catalogs or supply manual definitions. That gives us a concrete end-to-end integration, while allowing another gateway to manage its models differently and expose the same client-facing information. OpenCode does not need access to LiteLLM's private management APIs or the underlying supplier credentials, and adoption of the client change does not depend on the LiteLLM PR merging first

The OpenCode implementation is in PR #53713, now updated against dev. We have tested both sides together during development, and the current OpenCode revision passes local lint/typechecks, the selected regression suites and a Linux CLI build. The PR records the exact revisions and distinguishes current local checks from earlier integration evidence. The contract documentation covers the protocol and lifecycle details for anyone who wants to look further. The richer metadata is an optional extension to the OpenAI-style model list, so gateways need to implement those fields to provide the full behavior

There is related work already, including V2 catalog reconciliation in #40524, the older LiteLLM sync request #29308, context-limit discovery in #53235 and #54398, and the LiteLLM provider proposed in #54558. We would like to coordinate with those efforts. This request brings together the gateway-managed offerings and settings, including reasoning choices and output budgets, with their use by main agents, subagents and compaction. We are opening it to discuss that complete integration and its existing implementation, while keeping the related discovery work visible

Request For Maintainer Input

@rekram1-node, your gateway compatibility work in #54945 is particularly relevant to how these gateway models behave in OpenCode. Would you be willing to look at how this integration fits the provider work you have been doing? We have kept the existing compatibility controls and local overrides, and would appreciate your view on the approach

@thdxr, this builds on your provider/model registry work in #48901, especially the connection-bound inventories. Would you be willing to look at how we connect the gateway catalog to those registries, or suggest who would be best placed to review it?

We do not contribute here regularly, so we would appreciate a pointer to the right review owner and process. We have put substantial work into the integration and its tests, and want to give the team enough context to decide whether it is useful to OpenCode. Your feedback on the direction would help us understand what to refine, how to coordinate with the related work, and whether you would prefer the implementation reviewed in smaller parts