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. 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. 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. 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. 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. 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. 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. 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. 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 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 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.