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

The problem: client-only AI APIs have no server interface

Several providers ship capable models only through their own desktop or CLI client. Antigravity, Codex, Grok and Kiro are named in the project description as the targets. Those clients authenticate the way a browser does, not the way a server does, so a backend job cannot simply call them with a key. AIClient2API sits in the middle: it simulates the client request, holds the session, and republishes the result on a local OpenAI-compatible interface. The audience is developers who already have access to one of those clients and want to point existing OpenAI SDK code at it, plus anyone assembling a pool of several providers behind one base URL. It is not a way to obtain API access you do not otherwise have. The proxy forwards requests using credentials you supply; it does not create an entitlement.

How the proxy converts protocols and routes across a provider pool

The repository layout shows a Node.js service with a master process and a standalone server. package.json defines two entry points: node src/core/master.js as the default start script and node src/services/api-server.js as start:standalone. The master process is the multi-protocol front end; the standalone server is the narrower single-service mode. The Dockerfile builds a Go TLS sidecar in a first stage and copies the resulting binary into the Node image at /app/tls-sidecar/tls-sidecar, which suggests part of the outbound client simulation is handled outside Node, likely where TLS fingerprinting or connection behaviour matters. Requests arriving on the OpenAI-compatible surface are translated to the target provider's client protocol, and the description lists Gemini protocol conversion and a Claude API surface alongside the OpenAI one. Provider pools, smart routing and automatic failover are listed as features, so more than one upstream can back a single model name and a failing upstream can be skipped. The documentation does not publish the routing algorithm or the failover timeout, so treat those as configurable behaviour you will have to observe rather than a documented contract.

Installing AIClient2API with Docker and sending a first request

The image is published as justlikemaki/aiclient-2-api. The Dockerfile exposes ports 3000, 8085, 8086 and 19876-19880 and runs node src/core/master.js with any arguments passed through the ARGS environment variable. The Dockerfile comment gives the run pattern verbatim, including the example value for ARGS:

docker run -e ARGS="--api-key mykey --port 8080" ...

The container also ships healthcheck.js, wired into the image as a HEALTHCHECK that runs every 30 seconds with a 3 second timeout and 3 retries, so docker ps will show a health state without extra setup. If you prefer to run from source, the install scripts at the repository root are install-and-run.sh, install-and-run.bat and install-and-run.ps1, and the runtime floor is Node.js 20.0.0 or newer per the badge in the README and the node:20-alpine base image. The README does not include a client-side request example, so the call you make is whatever your OpenAI-compatible client already sends; point its base URL at the port you passed in ARGS and use the key from --api-key. What you should see is a completion object shaped like the one your client expects, because the proxy performs the protocol translation. If the call fails, check first whether the provider credential for the target model is configured; a proxy with no upstream session surfaces an upstream authentication error rather than a local one. The model name you pass is resolved against your configured providers, so an unknown name is a routing miss, not a syntax error.

Where AIClient2API is the wrong tool

The proxy depends on the providers' client behaviour staying put. When Antigravity, Codex, Grok or Kiro change their client protocol, the simulation in this repository has to be updated to match; the release history shows a steady cadence of small versions, v3.4.7.2, v3.4.8 and v3.4.9.1 within roughly two weeks, which is consistent with that pressure. That makes the upgrade cost real rather than optional. A second limitation is scope: if all your traffic already goes to OpenAI and Claude through official API keys, the conversion layer has nothing to convert and you have added a process, a port and a failure point for no benefit. Third, the README does not document rollback behaviour for a failed upstream, so automatic failover should be treated as a feature you verify against your own pool rather than one you assume. Finally, GPL-3.0 matters if you plan to redistribute a modified version.

How it differs from LiteLLM and one-api

LiteLLM and one-api solve a neighbouring problem: they normalise many official API keys behind one OpenAI-compatible endpoint. AIClient2API's distinguishing move is that its upstreams are client-only services with no server API of their own, which is why the repository carries a Go TLS sidecar and why the release notes track client protocol changes. With LiteLLM or one-api you register keys and get routing; with AIClient2API you reproduce a client session and then get routing. That difference sets the maintenance profile. A key-based router breaks when a provider changes its API version, which is announced. A client-simulation proxy breaks when a provider changes its client, which may not be announced at all. Choose based on which upstreams you actually hold.

Licence, maintenance and the cost of staying current

The project is GPL-3.0. Running it as a local service for your own use is the ordinary case the licence anticipates; distributing a modified binary or embedding it in a product triggers the copyleft obligations, and the LICENSE file at the repository root is the authoritative text. This is a description of the licence, not legal advice. On maintenance, the last push to main was on 2026-09-11 and the newest release, v3.4.9.1, was tagged the same day. The upgrade path is a container rebuild or a pull of the new image, but the meaningful cost is not the pull. It is the time spent diagnosing a broken upstream after a provider silently changes its client, which the healthcheck at /app/healthcheck.js will not detect because it only proves the local server answers.

Editorial conclusion

Adopt AIClient2API if you already hold client-only credentials for Antigravity, Codex, Grok or Kiro and want one OpenAI-compatible endpoint in front of them, and you accept GPL-3.0 plus the maintenance that comes with tracking upstream client changes. Do not adopt it if you need a vendor SLA, a hosted service with a support contract, or if your only providers are already OpenAI and Claude, where the proxy adds a hop for no conversion benefit. Verify first that your Node.js runtime is at least 20.0.0 (the image uses node:20-alpine), that ports 3000, 8085, 8086 and 19876-19880 are free on the host, and that you are willing to rebuild the container when a provider changes its client protocol.

Frequently asked questions

Official sources

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