Most AI dev setups break down in exactly the same place: the layer between your tools and your providers.
You may have:
- Claude Code on one account
- Codex using a different auth path
- Gemini CLI speaking another protocol
- a few API keys across multiple vendors
- mobile messages coming from Telegram, Feishu, or DingTalk
At that point, the problem is no longer "which model should I use?"
The problem is that your workflow has no control plane.
So I built CliGate: a local multi-protocol AI gateway that runs on localhost and gives all of those clients one entry point.
The idea
I did not want:
- separate configs for every CLI
- separate auth handling for every provider
- separate debugging surfaces for web chat and mobile channels
- separate session logic for "real work" versus "messages from my phone"
I wanted one local layer that could do all of this:
- accept requests from different AI coding tools
- route them to different upstream providers or account pools
- keep visibility into usage, logs, pricing, and failures
- let mobile channels continue the same runtime flow instead of becoming a dead-end notification pipe
That is what CliGate does.
What CliGate supports
On the client side, CliGate already exposes compatible paths for:
- Claude Code through Anthropic Messages API
- Codex CLI through OpenAI Responses API, Chat Completions, and Codex internal endpoints
- Gemini CLI through Gemini-compatible routes
- OpenClaw
On the channel side, it now supports:
- Telegram
- Feishu
- DingTalk
On the upstream side, it can route through combinations of:
- ChatGPT account pools
- Claude account pools
- Antigravity accounts
- provider API keys
- free-model routes
- local runtimes
That means the same local service can sit between your tools, your chat channels, and multiple upstream model providers.
The part I care about most: channels are not bolted on
This is the distinction that made the project worth building.
I did not want Telegram, Feishu, or DingTalk to behave like dumb message forwarders.
In CliGate, channel conversations plug into the same runtime orchestration layer used by the dashboard. That gives you:
- sticky runtime sessions
- conversation records
- pairing and approval flows
- provider-specific follow-up handling
- one place to inspect what happened
So when a conversation starts from a mobile channel, it can stay attached to the same runtime session until you explicitly reset it.
That is a very different model from the usual "webhook in, text out" bot architecture.
Why the local-first approach matters
CliGate runs locally.
That means:
- no hosted relay layer
- no forced external control plane
- direct connections to official upstream APIs
- your routing, credentials, sessions, and logs stay under your control
For developer tooling, this matters a lot more than people admit.
If the gateway layer itself becomes another cloud dependency, you have just moved the fragility somewhere else.
Routing is where the mess gets cleaned up
CliGate separates the client protocol from the upstream provider.
Your tool sends the shape it already expects. CliGate decides where it should actually go.
That includes:
- routing priority between account pools and API keys
- per-app assignments
- model mapping
- free-model fallback
- local model routing
So Claude Code, Codex CLI, Gemini CLI, and OpenClaw do not need to share the same credentials, and they do not need to know anything about each other's protocol requirements.
You can also bind apps to specific targets instead of manually swapping environment variables every time your usage pattern changes.
The dashboard is part of the product, not an afterthought
Most proxy tools feel fine until something breaks.
Then you realize there is no real visibility into:
- which credential was selected
- why routing chose that path
- whether a token expired
- which conversation owns a runtime session
- where a mobile follow-up got attached
CliGate ships with a web dashboard to manage:
- accounts
- API keys
- app routing
- channel settings
- runtime providers
- conversation records
- request logs
- usage and cost stats
- pricing overrides
That matters because a gateway without observability eventually becomes guesswork.
A concrete example
This is the workflow I wanted to make normal:
- Run CliGate once on my machine.
- Point Claude Code, Codex CLI, and Gemini CLI at the same local gateway.
- Configure Telegram, Feishu, or DingTalk as channel entry points.
- Start a task from the dashboard or from a mobile message.
- Keep that conversation attached to the same runtime context while I continue from another surface.
In other words: not just "multiple clients can call one proxy", but "multiple surfaces can participate in the same local orchestration model."
That is the real product.
Quick start
npx cligate@latest start
Or:
npm install -g cligate
cligate start
Then open:
http://localhost:8081
From there you can:
- add accounts or API keys
- configure app routing
- enable Telegram / Feishu / DingTalk channels
- inspect runtime sessions and conversation records
Who this is for
CliGate is useful if you are already feeling pain from any of these:
- you use more than one AI coding CLI
- you switch across OpenAI, Anthropic, Gemini, and other providers
- you want one local place to manage auth and routing
- you want mobile channel access without giving up runtime continuity
- you want debugging and observability instead of shell-script chaos
Repo
GitHub: https://github.com/codeking-ai/cligate
If your current AI setup looks like a pile of disconnected clients, credentials, and chat surfaces, CliGate is meant to turn that into one local piece of infrastructure.
Top comments (0)