CCX: a single-binary Go gateway that proxies and translates between Claude, OpenAI, Codex and Gemini APIs
Claude / Codex / Gemini API Proxy - CCX
At a glance
- What is it?
- CCX is an MIT-licensed, high-performance API proxy and protocol-translation gateway written in Go. From one port it exposes Claude Messages, OpenAI Chat, Images and Embeddings, Codex Responses and Gemini endpoints, with a built-in web admin console, channel orchestration, failover and multi-key management.
- Who is it for?
- Use CCX if you route AI traffic across several providers and want one endpoint with failover, key rotation and a web console rather than wiring each client to each upstream. Deploy the single binary or the Docker image, set a strong PROXY_ACCESS_KEY and a separate ADMIN_ACCESS_KEY, and open the console to add channels and watch health.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What CCX is
CCX describes itself as a high-performance AI API proxy and protocol-translation gateway. The important word is translation: it does not just forward requests, it converts between API formats, so a client speaking one provider's protocol can be served by an upstream that speaks another. It provides a unified entrypoint, built-in web administration, channel orchestration, failover, multi-key management and model routing.
The formats it covers are Claude Messages, OpenAI Chat Completions, OpenAI Images, OpenAI Embeddings, Codex Responses and Gemini. That breadth is the point. A team that uses several of these APIs, or wants to move traffic between providers without rewriting clients, gets one gateway to configure and monitor. CCX is written in Go, which is why the README can claim low memory use, and it ships as an integrated backend and frontend in a single binary.
One port, many endpoints
CCX exposes everything from one backend entrypoint. The README's map shows the routes on a single port:
Client -> backend :3000 ->
|- / -> Web UI
|- /api/* -> Admin API
|- /v1/messages -> Claude Messages proxy
|- /v1/chat/completions -> OpenAI Chat proxy
|- /v1/responses -> Codex Responses proxy
|- /v1/images/{...} -> OpenAI Images proxy
|- /v1/embeddings -> OpenAI Embeddings proxy
|- /v1/models -> Models API
`- /v1beta/models/* -> Gemini proxyThe images surface currently includes generations, edits and variations. Serving the web UI, the admin API and every proxy route from one port is what makes deployment simple: there is a single process to run, a single address for clients, and the frontend assets are embedded in the binary rather than served separately.
Channels, scheduling and failover
The reason to put a gateway in front of providers is usually reliability, and CCX's scheduling is where that lives. It supports smart scheduling with priorities, promotion windows, health checks, failover and circuit recovery, so when one channel degrades, traffic moves to another and the failed one is retried once it recovers. Context routing goes further: it filters candidate channels by the actual model context window and maximum output capability, so a long request is not sent to a channel that cannot handle it.
Each channel carries its own configuration: per-channel API key rotation, proxy support, custom headers, model allowlists and route prefixes. Responses session tracking supports multi-turn Codex workflows. The web admin console ties this together with visual, drag-and-drop channel management, real-time health monitoring, testing, logs, and traffic stats showing per-channel request volume, success rate and latency. For an operator, that console is the practical difference between a proxy you configure once and forget and one you can actually watch and tune.
Deploying CCX
There are several routes. CCX Desktop is a native GUI for Windows via the Microsoft Store, macOS via a Homebrew cask (brew tap BenedictKing/ccx && brew install --cask ccx-desktop) and Linux via an AppImage. For a server, the binary route is straightforward: download the release, create a .env next to it and run it. A minimal .env looks like this:
PROXY_ACCESS_KEY=your-proxy-access-key
PORT=3688
ENABLE_WEB_UI=true
APP_UI_LANGUAGE=enThe README also ships a docker-compose.yml. Its Go image is lightweight enough that the compose file caps the container at 256 MB of memory and half a CPU, persists a .config directory and exposes port 3000. Authentication uses two keys: PROXY_ACCESS_KEY guards the proxy endpoints, and an optional ADMIN_ACCESS_KEY isolates the web console and /api/* routes; if you do not set the admin key, it falls back to the proxy key, so setting both is the safer production choice.
The web console and model benchmarking
Beyond routing, CCX bundles some operator tooling that the Makefile reveals. It can generate a preset manifest of upstream configurations, and it has a benchmark-update workflow that refreshes model capability data from multiple sources and draws capability-versus-cost charts, optionally pulling from Artificial Analysis if you supply an API key and falling back gracefully when you do not. That is a useful extra for anyone deciding which channel to prioritise: the gateway can help you see the cost and capability trade-offs, not just route around failures.
The build itself is a cross-compiled Go binary with an embedded frontend built by Bun, which keeps the runtime image to an Alpine base with just the binary and certificates. For most users this is invisible, but it explains why a tool covering six API families still deploys as one small container.
Licence, releases and cautions
CCX is MIT licensed. Recent releases include v2.9.37 on 2026-07-07, v2.9.36 and v2.9.34 in early July, and the last push was on 2026-09-12, so the 2.9.x line is actively maintained. The repository keeps a VERSION file, a bilingual README, a Chinese-specific Dockerfile and a Watchtower compose file for auto-updating the container.
Two cautions. First, CCX holds and rotates your upstream API keys and exposes an admin console, so it must not be run open to the internet without the access keys set, and the admin key should be distinct from the proxy key. Second, the project carries several commercial sponsors offering discounted model access; those are advertisements in the README, not endorsements you need to act on, and the gateway works with any compatible upstream you configure. Treat the sponsor links as optional and evaluate any third-party API service on its own terms.
Editorial conclusion
Use CCX if you route AI traffic across several providers and want one endpoint with failover, key rotation and a web console rather than wiring each client to each upstream. Deploy the single binary or the Docker image, set a strong PROXY_ACCESS_KEY and a separate ADMIN_ACCESS_KEY, and open the console to add channels and watch health. It is a self-hosted gateway you run, not a hosted service.
Frequently asked questions
What does CCX actually do?
CCX is a self-hosted Go gateway that proxies and translates between Claude Messages, OpenAI Chat, Images and Embeddings, Codex Responses and Gemini APIs from a single port, adding a web admin console, channel failover, key rotation and model routing.
How do I deploy CCX?
Run the single binary with a .env that sets PROXY_ACCESS_KEY, PORT and ENABLE_WEB_UI, or use the provided docker-compose.yml. There is also CCX Desktop for Windows, macOS and Linux. Then open the web UI to add channels.
What are the two access keys for?
PROXY_ACCESS_KEY authenticates clients to the proxy endpoints, while the optional ADMIN_ACCESS_KEY isolates the web console and /api/* routes. If ADMIN_ACCESS_KEY is unset it falls back to the proxy key, so setting both separates the two roles.
Community notes