AIClient2API: a self-hosted proxy that turns client-only model APIs into an OpenAI-compatible endpoint

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 name suggests TLS handling is delegated to that Go binary rather than done in Node. 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, so treat that as the 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. Read those scripts before executing them. The manual equivalent is a Node install followed by the start script declared in package.json.

npm install
npm start

npm 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:standalone

The 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-api

A 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 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. 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 reach client-only APIs 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-10-26, and the most recent release, v3.6.4, is dated 2026-11-03. Before that, v3.6.3.1 landed on 2026-10-26 and v3.6.2 on 2026-10-21. Three releases in thirteen 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.6.4, 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.18.1, 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

Official sources

1. justlovemaki/AIClient2API on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases