2026-09-25

Connect OpenCode to a Multi-Provider AI Gateway

Connect OpenCode to a Multi-Provider AI Gateway: a production guide with an explicit decision, reusable artifact, failure tests, operating signals, and source-qualified limits.

Choose the wire contract before the tool

Connect OpenCode to a Multi-Provider AI Gateway should be implemented as a coding-agent integration contract, not as a one-off configuration. Freeze the protocol, ownership, evidence, and rollback condition before traffic moves. The concrete control points in this guide are provider_id, provider_package, baseURL, explicit_model_map.

Treat the OpenCode provider ID, provider package, base URL, credential entry, and explicit model map as one versioned contract. Choose the package that matches the endpoint actually used, test every declared capability on the selected model, and avoid advertising context, tools, or output limits copied from another provider.

Separate client setup from gateway policy

Separate the reader-facing task from the control-plane work behind it. Client setup owns the local file or environment variable; the gateway owns authentication, routing, limits, accounting, and attempt records; the provider owns its native protocol and volatile capability contract. A passing text prompt proves only that one path worked once.

A useful integration page owns protocol selection, configuration precedence, proof cases, and team rollout. The live setup document remains the owner of copy-paste installation steps. This division follows a capability-tree model: the article explains why and how to verify; the documentation supplies the current commands.

The owner record for this page is opencode-multi-provider-api-gateway; its frozen controls are provider_id, provider_package, baseURL, explicit_model_map. Every value is reviewed at the wire or durable-state boundary and never inferred from a marketing label.

Compatibility contract: Connect OpenCode to a Multi-Provider AI Gateway

Use the following review record as the deployable artifact. Technical values are intentionally explicit so a reviewer can compare configuration, wire evidence, and durable state without relying on a screenshot or a successful-looking outer response.

Control point	Fixed decision	Evidence to retain
`provider_id`	`credential_and_config_ids_match`	`auth_listing + effective_config_provider_key`
`provider_package`	`package_matches_endpoint_contract`	`package_name + captured_endpoint`
`base_url`	`exact_versioned_api_root`	`resolved_baseURL + first_request_path`
`model_map`	`only_verified_model_ids_declared`	`display_id + upstream_model_id + probe_digest`
`capabilities`	`tools_and_limits_are_evidence_based`	`tool_probe + context_boundary + output_boundary`
`fallback`	`only_same_contract_routes_are_eligible`	`eligibility_matrix + selected_route + rejection_reason`

Reference configuration or flow

The example uses placeholders and deterministic inputs. Replace identifiers with reviewed values, never with credentials or customer content. Preserve the exact configuration snapshot alongside the probe result.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "modelflare": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Modelflare",
      "options": { "baseURL": "https://modelflare.dev/v1" },
      "models": {
        "<verified-model-id>": { "name": "<reviewed-display-name>" }
      }
    }
  }
}

Prove the complete coding-agent path

Run the ladder in order. A later check cannot compensate for a missing earlier boundary, and every attempt must remain attributable to one logical request.

Freeze the current client, gateway policy, model alias, route set, and observable baseline. Evidence record for provider_id: enforce credential_and_config_ids_match and retain auth_listing + effective_config_provider_key.
Run one deterministic positive probe and capture the client-visible response, request ID, selected route, terminal state, and usage. Evidence record for provider_package: enforce package_matches_endpoint_contract and retain package_name + captured_endpoint.
Run the paired negative, limit, or disconnect case and verify that it fails in the intended layer. Evidence record for base_url: enforce exact_versioned_api_root and retain resolved_baseURL + first_request_path.
Repeat the probe through the actual protocol surface; do not infer native support from a neighboring compatibility endpoint. Evidence record for model_map: enforce only_verified_model_ids_declared and retain display_id + upstream_model_id + probe_digest.
Roll out to a bounded cohort with an explicit owner, expiry time, stop threshold, and prepared rollback. Evidence record for capabilities: enforce tools_and_limits_are_evidence_based and retain tool_probe + context_boundary + output_boundary.
Re-read durable configuration and accounting after the test, then remove temporary access or test data. Evidence record for fallback: enforce only_same_contract_routes_are_eligible and retain eligibility_matrix + selected_route + rejection_reason.

Integration failures that a text demo hides

Treat each item below as a release blocker. A 200 response, attractive dashboard, or single successful demo does not override these failure conditions.

provider_id_mismatch — A credential stored under one provider ID is invisible to a differently named configuration block.
wrong_provider_package — Using a Chat Completions package for a Responses-only path, or the reverse, changes the wire contract.
copied_capability_limits — Invented context, output, or tool flags create failures only after real workloads grow.
fallback_without_eligibility — A cheaper or available route is unsafe when it cannot preserve the same protocol and required capabilities.

Rollout evidence and stop conditions

Monitor success and harm together. The threshold is a policy input, not a universal benchmark; choose it from the workload SLO and record the denominator before the observation window begins.

Signal	Decision threshold	Action
`declared_model_probe_coverage`	`100%`	`remove_unverified_model`
`provider_resolution_errors`	`0`	`rollback_config_and_credential_id`
`capability_contract_failures`	`0`	`disable_capability_or_route`
`fallback_contract_mismatch`	`0`	`remove_route_from_eligible_set`

Modelflare boundary and limitations

Modelflare can centralize OpenAI-compatible and native-protocol routing, scoped keys, groups, usage records, and failure handling. A configured channel is not proof that every optional field, model alias, retention promise, region, or fallback is supported. Verify the selected route with its native protocol, preserve explicit zero values, and use the final durable settlement as billing truth.

OpenCode’s provider schema is actively evolving. The example records the currently checked configuration family, while the live /docs/opencode page and official provider documentation own the exact syntax at publication time. T-1 verification must block publication if the schema or package contract changes.

Continue through the topic cluster

Use the linked parent for the broader decision, the sibling for the next implementation step, and the documentation route for current client configuration. These body links are deliberate because managed CMS articles do not currently carry a separate related-slug field.

Frequently asked questions

Can any OpenAI-compatible provider package be used?

Only when its endpoint contract matches the route. Chat Completions and Responses are not interchangeable package choices.

Why declare models explicitly?

A custom provider may not have a trusted catalog entry; explicit reviewed IDs prevent accidental discovery claims.

Can fallback prioritize the cheapest model?

Only after protocol, capability, policy, and workload eligibility have passed. Cost is not the first gate.

Sources and verification date

Sources were checked on 2026-08-07. They establish external contracts and engineering principles; they do not prove an untested route or future provider state.