ENGINEERING

Run Aider against your own OpenAI-compatible gateway

August 2026 · 3 min read

Why point Aider at your own gateway

By default, Aider sends every request straight to the vendor's API. That's fine for one person kicking the tires. It gets uncomfortable once a team adopts it: every prompt and everything pulled into context leaves your network through a connection you don't operate and can't inspect. Put your own gateway in front of that traffic and you get the same four things any AI tool gains from this pattern:

• Data containment. Requests terminate at infrastructure you control before going upstream.
• Predictable cost. Per-team, per-key budgets instead of one shared vendor invoice nobody can attribute.
• Model swaps without touching the client. Change what's behind the gateway; every client config stays untouched.
• An audit trail. Every request logged by user, by key, by team.

Step 1: Install Aider and get your gateway key

Any Python 3.10+ works. We ran everything below on a stock Ubuntu box, with a key issued by our own gateway (the iSol API dashboard hands you one on signup, any OpenAI-compatible gateway works the same way).

python3 -m venv ~/venvs/aider
~/venvs/aider/bin/pip install aider-chat
~/venvs/aider/bin/aider --version   # aider 0.86.2 at the time of writing

Step 2: Point it at your gateway (three variables, not two)

Aider's docs say OPENAI_API_BASE. In current releases the underlying SDK reads OPENAI_BASE_URL, and if you set only the first one, the main request fails with a misleading "The model does not exist". We hit this on the exact session below. Set both and move on:

export OPENAI_API_BASE=https://tokens.4clouders.com/v1
export OPENAI_BASE_URL=https://tokens.4clouders.com/v1   # current aider reads this name
export OPENAI_API_KEY=<your gateway key>

Step 3: Run a real edit

The openai/ prefix tells Aider to use the OpenAI-compatible client against your base URL. Set the weak model too, or commit-message generation tries a model your key can't reach. This is a real session, Aider validated a Python function, applied the diff and committed, entirely through our sovereign gateway:

Step 4: Verify at the gateway, not at the client

Don't take the client's word for it. Ask the gateway who spent what, every request lands on the key's ledger with model and token counts. If nothing shows up there, the change didn't take:

curl -s https://tokens.4clouders.com/key/info \
  -H "Authorization: Bearer $OPENAI_API_KEY" | jq .info.spend
# 0.064732  ← the session above, accounted per key

What this covers, and what it doesn't

• Covered: all chat and code-editing requests, the traffic that carries your prompts and repository context, including streaming.
• Not covered: model metadata (context window, cost) for custom model names, add a .aider.model.metadata.json if you want exact token accounting; and Aider's optional voice mode, which uses a separate transcription API.

Gotchas we hit running this for real

• Set OPENAI_BASE_URL as well as OPENAI_API_BASE. With only the latter, aider 0.86 fails with "The model `isol-4.9` does not exist", the model is fine, the base URL never reached the SDK.
• Aider prints an "unknown model" warning for custom names, it still works; the warning is about missing cost metadata, not compatibility.
• Set --weak-model openai/<same-model> if your gateway restricts the model list, or the commit-message step may call a model your key can't reach.

Every command and screenshot on this page comes from a session run against the live iSol gateway on 2026-08-19.

Sources:

• https://aider.chat/docs/llms/openai-compat.html (checked 2026-08-19)

Try it on ours

Our gateway (iSol API) runs exactly this setup on sovereign infrastructure, US$ 99/month, 14-day trial. The endpoint in the examples above, https://tokens.4clouders.com/v1, is the real one.

See plans →