One Key, Four More Agents: Wiring Gemini CLI, Aider, Cline, and Continue to a Compatible Endpoint

Wiring one more agent to an OpenAI-compatible endpoint sounds like the same task each time, and it never quite is. The openai-compatible endpoint setup differs by tool because each tool exposes a different configuration surface: Gemini CLI changes its endpoint through an environment variable, Aider needs a model-name prefix on top of environment variables, Cline routes everything through a GUI provider panel, and Continue uses configuration keys that override per-model defaults. This guide wires all four, in the same shape as the original three-tool walkthrough: one key, several agents, no guessing. It is the extension of the earlier pillar piece, which covered the first tools on the bench.

Before the tools: verify the OpenAI-compatible endpoint

One step belongs before any tool configuration: prove the endpoint itself works. Send a minimal request with your key and read back the model list, so that "the tool will not connect" and "the endpoint cannot be reached" are separated before you start editing configs. The platform's own documentation covers the endpoint details, including the base URL for API calls and the model listing endpoint. On corporate networks, add one more prerequisite first: custom certificate bundles for TLS interception, which the corporate network guide covers for the CLI case generally. With those two checks done, every failure from here on is a tool configuration question, which is the rest of this article.

Gemini CLI: a custom base URL via environment variable

Gemini CLI is the most environment-variable-driven of the four. The official configuration reference documents three variables you will actually touch:

• GEMINI_API_KEY provides your key. The docs suggest setting it in your shell profile, such as ~/.bashrc or ~/.zshrc, or in an .env file.
• GOOGLE_GEMINI_BASE_URL overrides the default base URL for Gemini API requests when using API-key authentication. The docs require a valid URL and HTTPS unless it points to localhost. The official example: export GOOGLE_GEMINI_BASE_URL="https://my-proxy.com", or in Windows PowerShell, $env:GOOGLE_GEMINI_BASE_URL="https://my-proxy.com".
• GEMINI_MODEL sets the default model, overriding the built-in default, for example export GEMINI_MODEL="<model-name>".

Gemini CLI also supports a settings-file route: strings in settings.json can reference environment variables with $VAR_NAME, ${VAR_NAME}, or ${VAR_NAME:-DEFAULT_VALUE} syntax, resolved when settings load, so a value like "apiKey": "$MY_API_TOKEN" can keep secrets out of the file itself. The user-level file lives at ~/.gemini/settings.json, and a project-level .gemini/settings.json overrides it inside that project. Put together, this is the cleanest split of the four: key and model by environment variable, endpoint by base-URL override, and optional indirection through the settings file.

Aider: the OpenAI-compatible endpoint and the openai/ prefix

Aider connects through two standard environment variables plus one step people skip. Its OpenAI-compatible documentation shows the setup:

# Mac/Linux
export OPENAI_API_BASE=<endpoint>
export OPENAI_API_KEY=<key>

# Windows
setx OPENAI_API_BASE <endpoint>
setx OPENAI_API_KEY <key>

On Windows, the docs add the reminder that you need to restart your shell after setx commands. Then, when starting Aider, the model name carries an openai/ prefix:

cd /to/your/project
aider --model openai/<model-name>

That prefix is the documented way to tell Aider it is talking to an OpenAI-compatible endpoint rather than treating the model name as something else. It is also the step that quietly gets omitted: the environment variables look complete, the endpoint responds to a manual request, and Aider still behaves as if nothing was configured, because the model was invoked without the prefix. The docs also mention that Aider emits warnings when working with models it does not recognize, which is expected for custom endpoints and worth not misreading as a failure.

Cline: the OpenAI Compatible provider in the GUI

Cline does not use environment variables for this at all. In its settings panel, the OpenAI Compatible provider page describes three settings that matter:

1. Base URL. The docs are explicit that this will not be https://api.openai.com/v1, which is the official OpenAI API URL; it needs to be the endpoint your provider gives you. The page calls this out as a crucial step.
2. API Key. The secret from your provider.
3. Model ID. The name or identifier of the model you want to use.

In the panel itself, you select "OpenAI Compatible" as the API provider, fill in the Base URL, paste the key, and choose or enter the Model ID. One documented caution applies to any compatible provider: available model IDs differ between services, so the correct source for the exact identifier is your provider's own documentation. There is no config file to edit and no shell to restart; the entire configuration lives in the extension's UI, which is why it never breaks the same way the environment-variable tools do. If you have wired editor-side tools before, the pattern is the same shape as the Cursor walkthrough, just a different panel.

Continue: apiBase and apiKey in the config

Continue is configuration-file driven, and its official configuration reference documents the two keys that matter for a compatible endpoint:

• apiBase can override the default API base that is specified per model. The wording matters: the override is per the model's defaults, so leaving it unset means some models keep their own base.
• apiKey is the key sent with requests, and the reference notes it travels as a Bearer header.

In practice the configuration looks like a provider entry with those fields filled in, for example:

models:
  - name: my-custom-model
    provider: openai
    apiBase: https://your-endpoint.example/v1
    apiKey: YOUR_API_KEY
    model: <model-name>

The trap here is subtler than the others: because apiBase overrides defaults rather than globally replacing them, teams that configure some models and not others end up with a mix, with some traffic going where they expect and some not. Setting the field deliberately for every model you intend to route is the clean approach.

The configuration surfaces, side by side

| Tool | Endpoint configuration | Credential | Model selection | Classic trap |
| --- | --- | --- | --- | --- |
| Gemini CLI | GOOGLE_GEMINI_BASE_URL environment variable | GEMINI_API_KEY (shell profile or .env) | GEMINI_MODEL variable | Setting the variable in a shell the CLI session does not inherit |
| Aider | OPENAI_API_BASE environment variable | OPENAI_API_KEY variable | aider --model openai/<model-name> | Forgetting the openai/ prefix |
| Cline | Settings panel: OpenAI Compatible provider, Base URL field | API Key field | Model ID field | Entering the official OpenAI URL instead of the provider's |
| Continue | apiBase config key (overrides per-model defaults) | apiKey config key (Bearer header) | model field | Leaving apiBase unset for some models, so they keep their default base |

Four tools, four surfaces: one environment variable, one prefix ritual, one GUI panel, one config pair. None of them is harder than the others; they just fail differently.

The pitfalls they share

Across all four, the same five problems produce most of the support tickets:

1. The trailing /v1. Compatible endpoints and tools differ in whether the base URL includes the version segment. When a configuration fails immediately, try the other form before doubting anything else, and record which form the working setup used.
2. Model-name format versus the model list. The names your tool accepts should match what the endpoint reports in its model list. When a tool offers free-text model entry, a typo presents as a connection problem.
3. Environment variables that live only in one shell. Variables exported in a terminal apply to that session. Persist them in the profile the tool actually runs under, or inside the tool's own configuration, as Gemini CLI's settings file allows.
4. Secrets drifting into repositories. Keys belong in placeholders and environment variables, never in committed files or screenshots; the CI hygiene patterns in the coding agents in CI guide apply unchanged to local tools.
5. Corporate networks. Interception proxies and private certificate authorities sit between the tools and the endpoint; handle certificates as a prerequisite rather than a debugging surprise, following the same order the corporate network guide lays out.

The verification checklist

1. Confirm the endpoint with a minimal request and a model listing before touching any tool.
2. Configure each tool by its own surface: environment variable, prefix plus variables, GUI panel, or config keys.
3. Run one minimal command in each tool and confirm it completes a real request.
4. Check that the model and endpoint the tool reports match what you configured.
5. Restart the tool and the shell, then confirm the configuration persists.
6. Record the working form for each tool, in the same spirit as the key rotation checklist, so the next person does not rediscover the prefix, the trailing slash, or the settings file.
7. Keep the endpoint verified first in the record: when something stops working, the fastest path is still to prove the endpoint works before editing any tool.