"I Stopped Letting Every AI CLI Own Its Provider Config"

AI coding tools keep getting better.

The setup around them keeps getting worse.

Claude Code wants one style of config. Codex CLI wants another. Gemini CLI has its own path. OpenClaw has a different provider file again. Each tool makes sense in isolation. Together, they turn provider management into a small pile of duplicated state.

That was the part I wanted to stop.

The real problem is ownership

The annoying part is not that every tool needs a base URL or an API key.

The annoying part is that every tool starts acting like it owns your provider strategy.

If I change from OpenAI to Azure OpenAI, I should not have to remember which CLI has which config file. If I want Claude Code on one account and Codex on another provider, that should not become a weekend of shell variables, TOML edits, and half-forgotten JSON.

The tool should own the developer experience.

The local control plane should own routing.

What I changed

I built that rule into CliGate.

CliGate runs locally on localhost:8081. Claude Code, Codex CLI, Gemini CLI, and OpenClaw point at the same local gateway. After that, provider decisions move out of the individual tools and into one dashboard.

The setup becomes boring:

npx cligate@latest start

Then each tool only needs to know one thing:

use localhost:8081

The gateway handles the rest: account pools, API keys, model mapping, app-level bindings, fallback order, usage logs, and cost visibility.

Why this feels different

Before, switching providers meant touching the tools.

After, switching providers means changing a route.

For example, I can bind:

• Claude Code to a Claude account pool
• Codex CLI to Azure OpenAI
• Gemini CLI to Gemini API keys
• quick fallback requests to cheaper or free models

The CLIs do not need to know that decision changed. They keep speaking the protocol they already speak. CliGate translates and routes behind them.

That is the point: I do not want four AI tools to become four configuration databases.

The useful boundary

This is the boundary that made the project simpler:

Tools should be replaceable.

Providers should be replaceable.

Routing should be inspectable.

Once those three things are separated, a lot of annoying workflow problems get smaller. A key expires in one pool? Replace it in one place. A provider gets expensive? Move that app to another route. A model name does not match the upstream deployment name? Map it once.

No drama. No config archaeology.

Who needs this

If you use one AI CLI with one API key, you probably do not need a gateway.

If you use Claude Code, Codex CLI, Gemini CLI, local models, work credentials, personal accounts, and a few free provider keys, you probably already feel the problem.

The sharp version is this:

Your AI CLI should not own your provider strategy.

It should send the request. A local layer should decide where that request belongs.

That is the part CliGate is trying to make normal.

How are you handling provider config across AI coding tools right now: one config per tool, one wrapper script, or a local gateway?