OpenCode AI Gateway: Connect Multiple LLMs Through One API

An OpenCode AI gateway gives you one stable API layer between your terminal workflow and the models you actually want to use. If you are juggling separate provider keys, separate billing pages, and separate availability risks, that extra layer can make OpenCode much easier to run day to day.

ShareAI fits that role well because it gives you one API for 150+ models, plus smart routing, failover, and marketplace visibility. OpenCode already supports custom OpenAI-compatible providers, so the setup is mostly about pointing OpenCode at the right base URL and adding the model you want to use.

This guide is part of our Developers articles on AI routing, model access, and production-ready integrations.

Why use an OpenCode AI gateway in the first place?

OpenCode is designed to work with many providers, and its public docs show support for custom provider configuration, custom baseURL values, and OpenAI-compatible endpoints. That flexibility is powerful, but it also means you can end up managing every provider separately when all you really want is a clean coding workflow.

• One API key instead of one key per model vendor.
• One billing surface instead of several dashboards.
• Cleaner switching between models for fast edits, long-context tasks, or heavier refactors.
• A routing layer that can help when a provider is slow, unavailable, or no longer the best fit for the job.

For developers who want flexibility without maintaining separate provider plumbing, that is usually the point where an AI gateway starts to pay for itself.

How OpenCode supports this setup

According to the official OpenCode provider documentation, you can customize provider settings through opencode.json, set a custom baseURL, and use @ai-sdk/openai-compatible for OpenAI-compatible providers. The public OpenCode GitHub repository also documents its configuration paths and confirms that the tool is built for provider-level flexibility.

That means you do not need a special ShareAI integration package to get started. You can add ShareAI as a custom provider, keep your API key in an environment variable, and then choose the exact model you want OpenCode to call.

Step 1: Create your ShareAI API key and choose a model

Start by generating credentials in Create an API Key. Then browse the ShareAI model marketplace to decide which model should back your OpenCode workflow.

A practical pattern is to pick one default model for everyday coding tasks and keep one or two alternatives in mind for cases where you want lower latency, lower cost, or a stronger reasoning model.

Step 2: Add ShareAI as a custom provider in opencode.json

OpenCode lets you define a custom provider with an OpenAI-compatible endpoint. A simple starting template looks like this:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "shareai": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "ShareAI",
      "options": {
        "baseURL": "https://api.shareai.now/v1",
        "apiKey": "{env:SHAREAI_API_KEY}"
      },
      "models": {
        "your-shareai-model": {
          "name": "Choose a ShareAI model"
        }
      }
    }
  }
}

Replace your-shareai-model with the exact model identifier you want to use from the ShareAI model catalog. Keep the API key out of the file itself and load it through an environment variable instead.

export SHAREAI_API_KEY="your_api_key_here"
opencode

If you want the broader request format and authentication details, the API Reference covers the core ShareAI API flow.

Step 3: Switch models without rebuilding your setup

Once ShareAI is the provider layer, model changes become much lighter. You are no longer reworking vendor auth every time you want to test a different model. Instead, you keep the same API surface and change the model you point OpenCode at.

That is especially useful when your coding workflow changes by task. You might want one model for quick edits, another for larger repo reasoning, and a third as a fallback when cost or latency matters more than peak capability. You can compare options in the model marketplace and sanity-check behavior in the Playground before you lock in a default.

When direct provider keys still make sense

There are still cases where going direct is reasonable. If you depend on a provider-specific beta feature, a private enterprise agreement, or a strict in-provider governance setup, you may want to keep that path separate.

But for teams that mainly want OpenCode to stay flexible, portable, and easier to operate, using an OpenCode AI gateway is often the cleaner default. It reduces account sprawl and lets you evaluate models on performance and fit instead of on which vendor login you configured last.

Final takeaway

An OpenCode AI gateway is not about adding more tooling for the sake of it. It is about keeping one coding workflow while giving yourself room to change models, compare providers, and keep moving when the underlying model landscape shifts. If that is what you want from OpenCode, ShareAI gives you a practical way to do it through one API.