AIClient2API: a self-hosted proxy that turns client-only model APIs into an OpenAI-compatible endpoint
Self-hosted multi-protocol AI API proxy for Antigravity, Codex, Grok, Kiro, OpenAI, Claude, and custom providers. Supports OpenAI-compatible API, Claude API, Gemini protocol conversion, GPT, Grok Build, Claude Opus, Gemini Pro, Kimi, MiniMax, provider pools, smart routing, and automatic failover.
At a glance
- What is it?
- AIClient2API sits between your tools and providers such as Antigravity, Codex, Grok and Kiro, converting their client-only protocols into an OpenAI-compatible interface. It is worth adopting when you already hold accounts on those clients and want one local endpoint; it is the wrong tool if you need a stable, documented API contract.
- Who is it for?
- Adopt AIClient2API if you already hold accounts on Antigravity, Codex, Grok or Kiro and want one local OpenAI-compatible endpoint for your own tooling, and you accept that the upstream clients can change without notice. Do not adopt it if you need a documented stability guarantee, a published API contract or a hosted dependency, because the project simulates client requests rather than calling official APIs.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly JavaScript, 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
The client-only API problem AIClient2API addresses
Several capable models are reachable only through a vendor's own client application. The README describes AIClient2API as "a powerful proxy that can unify the requests of various client-only large model APIs (Antigravity, Codex, Grok, Kiro ...), simulate requests, and encapsulate them into a local OpenAI-compatible interface." That sentence is the whole product thesis. The targets are Antigravity, Codex, Grok and Kiro, plus OpenAI, Claude and custom providers named in the repository description.
The audience is narrow but real. You are a developer who already has access to one or more of those clients, and you want to point an existing tool at a single base URL instead of writing a separate adapter per vendor. The proxy also speaks the Claude API and performs Gemini protocol conversion, so a tool written against any of those three shapes can plausibly talk to the same backend. Provider pools, smart routing and automatic failover are listed as features, which implies more than one credential can back a single logical endpoint.
What it is not: an official SDK, a vendor-supported gateway, or a service with an uptime commitment. The mechanism is request simulation against clients, and that is the source of both its reach and its fragility.
How the proxy converts client protocols into OpenAI-shaped responses
The repository layout shows the split. src/core/master.js is the entry point used by npm start, while src/services/api-server.js is a standalone server started by npm run start:standalone. So the normal mode runs a master process that supervises the API service rather than a single flat server. Configuration lives in configs/, and the Dockerfile creates /app/logs for output.
A separate Go program under tls-sidecar/ is compiled in the first Docker stage with Go 1.22 and copied into the Node image as /app/tls-sidecar/tls-sidecar. Its presence tells you the proxy needs a TLS layer it does not implement in Node, which fits the request-simulation model: some upstream clients expect a specific transport fingerprint. That sidecar is the least documented part of the system, and it is the piece most likely to break when an upstream client changes.
The Node side depends on axios, undici, ws, the openai and @ai-sdk/openai packages, and google-auth-library. The Google auth library is consistent with the Gemini conversion path; ws suggests streaming. The Dockerfile comment notes the Node 20 Alpine base was chosen because undici requires Node.js >= 20.18.1, which is stricter than the badge in the README that states Node.js >= 20.0.0. Treat the Dockerfile as the accurate floor.
Installing AIClient2API and making a first request
The repository ships install-and-run.sh, install-and-run.ps1 and install-and-run.bat, so the intended path is a script rather than a manual sequence. The README does not reproduce the steps those scripts take, so read them before executing. The manual equivalent is a Node install followed by the start script declared in package.json.
npm install
npm startnpm start runs node src/core/master.js. If you would rather run only the API server without the master process, package.json exposes a second entry point.
npm run start:standaloneThe Docker route builds the Go sidecar first, then the Node image. The Dockerfile exposes ports 3000, 8085, 8086 and the range 19876-19880, and it accepts runtime arguments through the ARGS environment variable, with the documented example being --api-key and --port.
docker run -e ARGS="--api-key mykey --port 8080" justlikemaki/aiclient-2-apiA healthcheck runs node healthcheck.js every 30 seconds with a 3 second timeout and 3 retries. If the container reports unhealthy, that script is the first thing to inspect, not the proxy logs.
Where AIClient2API breaks, and when it is the wrong tool
The design depends on simulating requests that client applications make. Anything that changes in an upstream client, an auth flow, a header set, a TLS expectation, can invalidate that simulation. The README does not document rollback, does not describe how upstream changes are detected, and does not state a compatibility policy. The tls-sidecar binary is compiled at image build time, so a fix may require rebuilding the image rather than restarting the process.
There is also a licensing and provenance question the README does not address. Using client-only APIs through a proxy may conflict with the terms those clients set. Nothing in the repository resolves that, and the project cannot resolve it for you.
Where it is clearly the wrong tool: production systems that need a documented API contract with versioned deprecation windows. If your application depends on a specific response schema, a simulated client API gives you no notice before it changes. The same applies if you need vendor support, an SLA, or a security review of the code path handling your credentials. Finally, if your only provider is OpenAI or Anthropic with official API keys, the proxy adds a hop and a failure mode for no benefit.
AIClient2API compared with a plain OpenAI-compatible gateway
A conventional gateway such as LiteLLM or one-api assumes every backend already exposes an HTTP API with a key. Its job is routing, key management, budgets and logging across those APIs. AIClient2API starts one level lower: it makes client-only providers look like APIs in the first place. That is a different problem, and it explains why the project carries a Go TLS sidecar and a Node process instead of a routing table.
The practical difference shows up in failure modes. A gateway fails when a provider is down or a key is exhausted, and the fix is usually a config change. AIClient2API can fail because a client changed its request shape, and the fix is a code change plus a rebuild. The trade is reach against stability: the gateway cannot touch Antigravity, Codex, Grok or Kiro at all, while AIClient2API can, at the cost of depending on undocumented behaviour. If you have official keys for every model you need, the gateway is the lower-risk choice. If you do not, the gateway is not an option.
Maintenance cadence, upgrade cost and the GPL-3.0 boundary
The last push to main was on 2026-09-11, three days before this writing, and the most recent release v3.4.9.1 is dated the same day. Before that, v3.4.8 landed on 2026-09-05 and v3.4.7.2 on 2026-09-01. Three releases in eleven days indicates a fast-moving codebase. The repository is not archived. Note that package.json still declares version 3.0.0 while the releases are at 3.4.9.1, so the file is not a reliable version indicator; check the VERSION file or the release tag instead.
Upgrade cost is the real consideration. The Dockerfile installs tar, git and procps and the comment mentions tar is used for the update feature, so in-container updates exist. Upgrading across a fast release cadence means re-reading release notes each time, because a simulated client protocol can shift between patch versions. Pinning a digest is the safer default.
The licence is GPL-3.0. If you run the proxy internally for your own tooling, that is a normal use. If you distribute a product that links to or embeds this code, GPL-3.0 obligations attach to that distribution. This is a description of the licence, not legal advice; get your own review before shipping anything built on it.
Editorial conclusion
Adopt AIClient2API if you already hold accounts on Antigravity, Codex, Grok or Kiro and want one local OpenAI-compatible endpoint for your own tooling, and you accept that the upstream clients can change without notice. Do not adopt it if you need a documented stability guarantee, a published API contract or a hosted dependency, because the project simulates client requests rather than calling official APIs. Before running it, verify that Node.js is at least 20.0.0, that the ports you intend to expose match the ones the Dockerfile declares, and that GPL-3.0 fits how you plan to distribute anything built on top.
Frequently asked questions
What is AIClient2API and which providers does it support?
It is a self-hosted proxy that simulates requests to client-only model APIs and exposes them as a local OpenAI-compatible interface. The repository names Antigravity, Codex, Grok, Kiro, OpenAI, Claude and custom providers, and it also supports the Claude API and Gemini protocol conversion.
How do I install and run AIClient2API?
The repository includes install-and-run.sh, install-and-run.ps1 and install-and-run.bat scripts, or you can run npm install followed by npm start, which executes node src/core/master.js. A Docker image is also published, and the Dockerfile documents passing arguments through the ARGS environment variable.
What Node.js version does AIClient2API require?
The README badge states Node.js >= 20.0.0, but the Dockerfile comment says the Node 20 Alpine base was chosen because the undici package requires Node.js >= 20.18.1. Treat 20.18.1 as the effective floor when installing manually.
Which ports does AIClient2API expose?
The Dockerfile declares EXPOSE 3000, 8085, 8086 and the range 19876-19880. The Dockerfile also shows the port can be overridden at runtime, with --port 8080 given as the example argument.
Is AIClient2API free to use and what licence applies?
The project is licensed under GPL-3.0, and the repository includes a LICENSE file. Running it for your own internal tooling is a normal use; distributing a product built on it triggers GPL-3.0 obligations, so review the licence before shipping.
Why does AIClient2API include a TLS sidecar written in Go?
The Dockerfile compiles a Go program from tls-sidecar/ in a golang:1.22-alpine stage and copies the binary into the Node image at /app/tls-sidecar/tls-sidecar. The README does not explain its role, but its presence is consistent with the proxy needing transport behaviour that Node does not provide on its own.
Community notes