AI Coding Assistants: 8 Ways to Bring Your Own Model

Contents

Figure 1: AI Coding Assistants: 8 Ways to Bring Your Own Model — every tool accepts an endpoint; they disagree on everything after that

Your company has a gateway, or you run a model on your own GPU, or you just do not want one vendor holding your coding workflow hostage. So which assistants let you bring your own provider? Most claim to, and the docs show a wider range than the marketing does.

I ran none of these tools. For seven of the eight I read the tool's own docs, and for Cursor I could only read a third party's page about it. My script lints the config snippets below against documented field names, so they are well-formed but not proven to work.

How I Judged "Supports Custom Providers"

Three questions, answered only from each tool's own pages:

1. Can you point it at your own endpoint, and what format must it speak?
2. Does the page say what breaks, or what the tool will not do?
3. Where do your keys live?

Support is a spectrum, not a yes or no. A tool that accepts a base URL but never documents its capability flags is less useful than one that tells you which features survive.

The Short Answer

Tool	Custom provider route	Notable catch
Aider	OPENAI_API_BASE plus an openai/ model prefix [1]	Warnings for models Aider does not recognise [1]
Cline	"OpenAI Compatible" provider form [2]	No per-provider feature matrix [2]
Continue	provider: openai with apiBase in YAML [3]	Fields documented, capabilities not [3]
Zed	openai_compatible in settings [3]	Keys belong in the keychain, not the file [3]
OpenCode	@ai-sdk/openai-compatible in opencode.json [4]	auth.json protection is not described [4]
Claude Code	Gateway via ANTHROPIC_BASE_URL [4]	Non-Claude models unsupported, per Anthropic [4]
GitHub Copilot	Local BYOK or enterprise custom models [5]	BYOK does not cover code completions [5]
Cursor	Base URL override, third-party guidance [5]	Not officially supported for gateways [5]

Aider: Two Variables and a Prefix

Aider's OpenAI-compatible page needs two environment variables and one flag.

export OPENAI_API_BASE=https://gateway.example.com/v1
export OPENAI_API_KEY=sk-...
aider --model openai/my-model

The prefix is not optional: the model name must start with openai/ [1]. Aider says it "uses the litellm package to connect to hundreds of other models," so any LiteLLM-supported model works with aider --model <model-name> [1].

The page also warns that Aider will emit warnings for models it is not familiar with [1]. That is the whole cost of admission here: no capability flags, no context-window setting, no image toggle. You get what the model does by default.

Cline: A Form With the Right Knobs

Cline's OpenAI Compatible provider asks for three things: a base URL, an API key and a model ID [2]. The base URL is explicitly not https://api.openai.com/v1 [2].

It also exposes a model configuration block [2]:

• Max output tokens
• Context window size
• Image support
• Computer use, for models with tool calling
• Input and output price, per token or per million tokens

The page names Ollama and LM Studio as local options and says model IDs differ by provider, so check the provider's own docs [2]. It offers no matrix of which Cline features work with which provider, so test the ones you rely on. That last sentence is my reading of the page, not a quote from it.

Continue: Config as Code

Continue defines models in config.yaml. Three fields are required: name, provider and model [3]. For a custom endpoint you set provider: openai and add apiBase [3].

models:
  - name: My Gateway Model
    provider: openai
    model: my-model
    apiBase: https://gateway.example.com/v1
    roles: [chat, edit, apply, summarize]
    defaultCompletionOptions:
      contextLength: 128000
      maxTokens: 4096

The reference documents more than the snippet shows [3]:

• roles accepts chat, autocomplete, embed, rerank, edit, apply and summarize, and defaults to [chat, edit, apply, summarize]. The docs note that summarize is not currently used.
• defaultCompletionOptions carries contextLength, maxTokens and temperature.
• requestOptions carries timeout, verifySsl, caBundlePath, proxy and custom headers.

What the reference does not give you is a provider-by-provider capability table. It documents the fields, not what your endpoint will honour.

Zed: The Most Explicit Capability Settings

Zed has the most detailed knobs of the eight. Providers live under language_models.openai_compatible, each with an api_url and an available_models array [3]:

{
  "language_models": {
    "openai_compatible": {
      "my-gateway": {
        "api_url": "https://gateway.example.com/v1",
        "available_models": [
          {
            "name": "my-model",
            "display_name": "My Model",
            "max_tokens": 128000,
            "capabilities": {
              "tools": true,
              "images": false,
              "parallel_tool_calls": false,
              "chat_completions": true,
              "max_tokens_parameter": false
            }
          }
        ]
      }
    }
  }
}

You can also add the provider from Agent Settings instead of editing the file [3]. The defaults matter, because they are conservative [3]:

Capability	Default for an OpenAI-compatible model
tools	true
images	false
parallel_tool_calls	false
prompt_cache_key	false
chat_completions	true
interleaved_reasoning	false
max_tokens_parameter	false

If a model only works with the Responses API, set capabilities.chat_completions to false and Zed uses the Responses endpoint instead [3]. For reasoning models it suggests setting reasoning_effort to a supported non-none level [3].

The key rule is blunt: keys saved through Zed go into the system keychain, not settings.json [3]. Zed also reads an environment variable named after the provider ID in upper snake case plus _API_KEY, so my-gateway reads MY_GATEWAY_API_KEY [3]. A non-empty environment variable takes precedence over the keychain value [3].

OpenCode: The Widest Provider List

OpenCode says it supports "75+ LLM providers" and local models through the AI SDK and Models.dev [4]. For a custom OpenAI-compatible provider, you add the key with /connect and then configure opencode.json [4].

{
  "provider": {
    "myprovider": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://gateway.example.com/v1",
        "apiKey": "{env:GATEWAY_API_KEY}"
      },
      "models": {
        "my-model": { "name": "My Model" }
      }
    }
  }
}

The page says /connect keys are stored in ~/.local/share/opencode/auth.json but does not say how that file is protected [4]. Its guidance on models is a map of model IDs to display names, so check the page for the exact entry shape [4].

One practical tip from the page: if Ollama tool calls fail, try increasing num_ctx to around 16k–32k [4]. That is the same context-size limit the OpenAI shape cannot express, which is why it lives in Ollama's own configuration.

Claude Code: Gateway-Based, With a Big Caveat

Claude Code connects through a gateway using ANTHROPIC_BASE_URL, plus the credential your gateway expects. Any gateway that exposes a supported API format works [4].

But Anthropic's own page is explicit: it "doesn't support routing Claude Code to non-Claude models through any gateway," and it "doesn't endorse, maintain, or audit third-party gateway products" [4].

That is a different stance from the LiteLLM tutorial I covered in an earlier article, which shows Claude Code with non-Anthropic models through LiteLLM. Both pages exist, and they disagree on support. Treat the LiteLLM route as unofficial.

One detail worth stealing even if you never use Claude Code: allowedProviders set to ["customEndpoint"] in managed settings makes the gateway the only destination a managed machine may use [4]. Claude Code then refuses a session pointed anywhere else, including at Anthropic directly or at a developer's own proxy [4].

A gateway is also infrastructure you maintain. Claude Code adds features with each release, and a gateway that does not forward them breaks those features.

GitHub Copilot: Bring Your Own Key, Two Ways

GitHub offers two mechanisms, and they are not the same feature [5].

Mechanism	Who configures it	What it does
User BYOK	Each developer, in a supported client	The client sends requests straight to the provider with your credentials, not through GitHub's Copilot API [5]
Enterprise custom models	Enterprise owners, or org owners with permission	Keys are added centrally and users reach the models through GitHub's Copilot API [5]

User BYOK is supported in VS Code, JetBrains IDEs, Xcode, Copilot CLI, the GitHub Copilot app and the Copilot SDK [5]. The Copilot app lists OpenAI, Azure OpenAI, Microsoft Foundry, Anthropic, Ollama, Foundry Local, LM Studio and any OpenAI-compatible HTTP endpoint [5]. The SDK's provider config takes a baseUrl, an optional apiKey and a wireApi of completions or responses, which is how vLLM and LiteLLM get in [5].

Enterprise custom models are in public preview [5]. The supported providers are Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, OpenAI-compatible providers and xAI [5]. That list is longer than most comparisons suggest, and it is the part worth checking before you promise a team that its gateway will work.

Two limits are easy to miss [5]:

• BYOK does not apply to code completions in VS Code. It covers chat, the plan agent and custom agents, not inline completion.
• Business and Enterprise admins can disable user BYOK by policy. The enterprise path is the one that survives that policy, and it requires a Copilot licence.

Usage is billed by your provider and does not count against Copilot premium request quotas [5]. That cuts both ways: you lose Copilot's rate limits and you lose its accounting.

Cursor: Best Effort at Best

I could not read Cursor's own docs here. LiteLLM's Cursor page describes an Override OpenAI Base URL setting, and then adds the caveats that matter [5]:

• "Cursor does not officially support AI Gateways," and LiteLLM calls its own work "best effort from reverse engineering their APIs."
• Newer Cursor builds no longer show the Override OpenAI Base URL setting on every plan, and LiteLLM now points those users at an Azure OpenAI fallback.
• The Cursor CLI cannot target LiteLLM at all.
• Agent mode through LiteLLM works from v1.97.0, because LiteLLM translates the Responses API shapes Cursor sends.

Treat all of that as a third-party view and check Cursor's docs before you commit.

What I Did Not Run

This is a documentation comparison, not a benchmark.

• I ran none of the eight tools against a real endpoint. Every claim above comes from the linked page.
• The config snippets were linted against documented field names by my script, not executed. Well-formed is not the same as working.
• For Cursor, the only source is LiteLLM's page, which is explicit that it reverse engineered the integration.
• Cline, Continue and OpenCode do not publish a capability matrix, so "this feature works with your provider" is untested for all three.
• Provider pages change quickly. I read these on 2026-10-29 [1][2][3][4][5].

Which Should You Pick?

Your situation	The tool to try first
Terminal, minimal setup	Aider — two env vars and a model prefix [1]
Config as code in an editor	Continue or Zed — YAML or JSON, both with explicit fields [3]
Widest provider reach	OpenCode — 75+ providers through the AI SDK [4]
A team already on Copilot	Copilot BYOK, after checking which models your client accepts [5]
A form-driven VS Code workflow	Cline [2]
Claude Code	Stay on Claude models unless you accept an unsupported setup [4]

The best test is not the feature list. Point the tool at your actual endpoint and run a tool-calling task.

Common Pitfalls

1. Assuming "supports custom providers" means every feature works. It usually means chat works and the rest is your problem.
2. Putting API keys in settings.json for Zed. They belong in the keychain or an environment variable [3].
3. Forgetting the openai/ prefix in Aider. Without it the model name is looked up as a native provider [1].
4. Expecting Copilot BYOK to cover code completions. It does not, in VS Code [5].
5. Assuming Cursor officially supports gateways. LiteLLM says the opposite, in its own words [5].
6. Treating a gateway as a one-off setup. Claude Code ships features your gateway must forward [4].
7. Skipping the context-window field. Zed and Cline expose it; Aider does not [2][3].
8. Believing the marketing over the compatibility page. The page is the contract.

Wrapping Up

Almost every assistant here will accept your endpoint, but they differ on key storage, capability settings and how honest the docs are about limits. Pick based on where your keys live and what your endpoint supports, then test one real task.

Start with one tool and one endpoint, and write down what broke. That list is worth more than any comparison table, including this one.

If the endpoint itself is the unknown, OpenAI-compatible APIs: the fields they ignore covers what each provider does with your request, and the LiteLLM proxy guide covers the gateway side.

Frequently Asked Questions

Which AI coding assistants support custom model providers?

Aider, Cline, Continue, Zed, OpenCode, Claude Code and GitHub Copilot all document a path to your own endpoint, and Cursor has a base URL override that LiteLLM describes as best effort. The differences are in what each tool lets you configure, where the key lives, and how honest the docs are about the features that stop working.

Does Claude Code work with non-Claude models?

Not according to Anthropic. Its gateway page says Anthropic does not support routing Claude Code to non-Claude models through any gateway, and does not endorse, maintain or audit third-party gateway products. A gateway that speaks a supported API format still works for Claude models, and the page documents allowedProviders with customEndpoint to lock a managed machine to one gateway.

Where does Zed store API keys for a custom provider?

Keys saved through Zed go into the system keychain, not settings.json, and the docs say not to put API keys in that file. Zed also reads an environment variable built from the provider ID in upper snake case plus _API_KEY, so a provider ID of my-gateway reads MY_GATEWAY_API_KEY. A non-empty environment variable takes precedence over the keychain value.

Does GitHub Copilot BYOK work with local models?

Yes, in the clients that support user-configured BYOK. The Copilot app lists Ollama, Foundry Local and LM Studio alongside OpenAI, Azure OpenAI, Microsoft Foundry, Anthropic and any OpenAI-compatible HTTP endpoint, and the Copilot SDK accepts an OpenAI-compatible base URL for vLLM or LiteLLM. Copilot also notes that BYOK does not apply to code completions in VS Code.

Can I use Cursor with a self-hosted LLM gateway?

Only as a best-effort setup. LiteLLM's Cursor page says Cursor does not officially support AI gateways, that its work is reverse engineered, and that newer Cursor builds no longer show the Override OpenAI Base URL setting on every plan. The Cursor CLI cannot target LiteLLM at all, and agent mode through LiteLLM needs v1.97.0 or later.

Sources

• [1] Aider, OpenAI compatible APIs and Other LLMs — OPENAI_API_BASE and OPENAI_API_KEY, the mandatory openai/ model prefix, the note that Aider warns about models it does not recognise, and "Aider uses the litellm package to connect to hundreds of other models" with aider --model <model-name> and --list-models: aider.chat/docs/llms/openai-compat.html and aider.chat/docs/llms/other.html
• [2] Cline, OpenAI Compatible — the base URL, API key and model ID fields, the warning that the base URL is not the official OpenAI endpoint, the model configuration block with max output tokens, context window, image support, computer use and input/output pricing, Ollama and LM Studio as local options, and the note that model IDs differ by provider: docs.cline.bot/provider-config/openai-compatible
• [3] Continue, config.yaml reference, and Zed, Use API Access — Continue's required name, provider and model fields, apiBase, the seven roles and their default of [chat, edit, apply, summarize], the unused summarize note, defaultCompletionOptions with contextLength, maxTokens and temperature, and requestOptions with timeout, verifySsl, caBundlePath, proxy and headers; Zed's language_models.openai_compatible with api_url and available_models, the seven capability defaults, the Responses fallback via chat_completions: false, reasoning_effort, keys stored in the system keychain rather than settings.json, and the <PROVIDER_ID>_API_KEY environment variable rule with its precedence over the keychain: docs.continue.dev/reference and zed.dev/docs/ai/use-api-access.html
• [4] OpenCode, Providers, and Anthropic, Other LLM gateways — "75+ LLM providers" through the AI SDK and Models.dev, /connect credentials stored in ~/.local/share/opencode/auth.json, baseURL overrides, the @ai-sdk/openai-compatible provider example and its models map, the num_ctx 16k-32k tip for Ollama tool calls; and Claude Code's ANTHROPIC_BASE_URL, "Any gateway that exposes a supported API format works", the refusal to support non-Claude models through any gateway, the no-endorsement and no-audit statement, and allowedProviders: ["customEndpoint"] with the gateway URL in the managed settings env block: opencode.ai/docs/providers/ and docs.anthropic.com/en/docs/claude-code/llm-gateway
• [5] GitHub, Bring your own key for GitHub Copilot, Enabling custom models for GitHub Copilot in your enterprise and BYOK in the Copilot SDK, plus LiteLLM, Cursor — user BYOK sending requests directly to the provider rather than GitHub's Copilot API, the supported clients (VS Code, JetBrains, Xcode, Copilot CLI, Copilot app, Copilot SDK), BYOK without a Copilot subscription, the policy that can disable it for Business and Enterprise, enterprise custom models in public preview with Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, OpenAI-compatible providers and xAI, the Copilot app's provider list including Ollama, Foundry Local and LM Studio, the SDK's baseUrl, apiKey and wireApi fields, BYOK not applying to code completions and not counting against premium requests; and LiteLLM's Cursor page with "Cursor does not officially support AI Gateways", the reverse-engineering note, the missing Override OpenAI Base URL setting on newer builds, the Azure OpenAI fallback, the CLI limitation and agent mode from v1.97.0: docs.github.com/en/copilot/concepts/models/bring-your-own-key, docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/enable-custom-models, docs.github.com/en/copilot/how-tos/copilot-sdk/auth/byok, docs.github.com/en/enterprise-cloud@latest/copilot/how-tos/github-copilot-app/use-byok-models, github.blog/changelog/2026-04-22-bring-your-own-language-model-key-in-vs-code-now-available and docs.litellm.ai/docs/tutorials/cursor_integration

Related Articles

• OpenAI-Compatible APIs: The Fields They Ignore
• Aider, Claude Code, Cursor: One LiteLLM Proxy for All
• LLM Gateways Compared: 9 Options, No Vendor Rankings
• Hosting an LLM Gateway: The Cluster You Don't Need