Turn your own logins into a local OpenAI-compatible API
Supports Qoder Global, Qoder CN, WorkBuddy Global, WorkBuddy CN, Trae CN Solo, and experimental Devin (provider=devin, browser OAuth / session token import; not claimed production-ready).
Long-lived account runtimes, multi-account scheduling. Deploy with Docker; that is the supported install and update path.
- OpenAI / Anthropic-compatible proxy:
/v1/chat/completions,/v1/responses,/v1/messages,/v1/models— streaming/non-streaming text and function tools; image support depends on the provider (currently supported by Qoder, not WorkBuddy / Trae); file inputs are rejected explicitly.messages/responsesare stateless adapters today and do not support server-side conversations or upstream-specific tools. - Multi-channel account pool: Qoder Global / Qoder CN, WorkBuddy Global / WorkBuddy CN, Trae CN Solo, plus experimental Devin — region isolation, account pinning, concurrency limits, cooldowns, and same-family failover
- Outbound proxies: set one global HTTP(S) proxy or override it per account; use
direct/nonefor explicit direct access. SOCKS5 is available for WorkBuddy / Trae / Devin account-level proxies only; Qoder account-level proxies are HTTP(S) only - Account-level runtimes: Qoder accounts use an isolated Node process, HOME, and WASM context; WorkBuddy / Trae / Devin use in-process HTTP/SSE (or Connect) adapters. Each provider owns its login and upstream runtime boundary
- Provider-specific login methods: browser Device Flow OAuth, PAT, and credential import/export where supported
- Web console: accounts, models, access, request history, and runtime logs, with light and dark themes
- Deployment and ops: single Docker Compose container, safe managed updates (pre-update snapshot, automatic rollback on failure, jump to the latest stable release, roll back to one of the three previous stables), binds
127.0.0.1by default - Cross-platform:
linux/amd64/linux/arm64images; macOS and Windows run them through Docker Desktop
Deploy with Docker. Published images and console managed updates (pre-update snapshot, automatic rollback, jump to the latest stable release) are built around the single Compose container. Running the Go / Node sources directly is not on that update path.
Requirements: Docker (Docker Desktop on macOS/Windows, Docker Engine + Compose on Linux) and a Qoder, WorkBuddy, Trae, or experimental Devin account you control. On Windows, Docker Desktop must use Linux containers.
git clone https://github.com/caigee-cmd/cli2api.git
cd cli2api
./scripts/start.sh # Windows: scripts\start.ps1The first startup generates a random API key and prints it once in the logs — save it. Then open http://127.0.0.1:3010, sign in, and add accounts from Accounts. Full steps in the deployment guide.
Any OpenAI-compatible client (OpenAI SDKs, Codex, CherryStudio, …) works out of the box:
Base URL: http://127.0.0.1:3010/v1
API Key: <the key printed on first startup>
Without an account header the scheduler picks a ready account; pin a request with the X-Qoder-Account: acc_... header (a historical name that applies to every provider). Anthropic POST /v1/messages and OpenAI POST /v1/responses are also available; both require the complete conversation in each request and do not support server-side continuation through previous_response_id / conversation. Multi-turn requests stick to the same account from the first user message (including image-only turns) by default; X-CLI2API-Session remains an optional override. curl / PowerShell examples in the deployment guide.
Each enabled account gets an isolated runtime: Qoder uses its own Node process, HOME, and WASM context, while WorkBuddy / Trae / Devin use in-process adapters. Go owns persistence, scheduling, concurrency limits, cooldowns, failover, and the lifecycle of providers that need child processes.
Accounts, models, access, and logs all live in one web console. Each account signs in through the methods supported by its provider (browser OAuth, PAT, or credential import), readiness and quota are visible at a glance, and the Access page lets you copy the Base URL and run a quick check.
- Connect Qoder / WorkBuddy / Trae (and experimental Devin) to local or private-server tooling
- Reuse OpenAI-compatible clients and scripts
- Route requests across multiple accounts with failover
- Keep login state available without starting a full CLI Agent per request
CLI2API is a local gateway: it does not provide accounts, quotas, or an official API service, and it is not a shared multi-user resale service.
In progress
- Live-account acceptance for Qoder CN and WorkBuddy (login, failover, mixed account pools)
Supported
- Stateless text and function-tool adapters for Anthropic
/v1/messagesand OpenAI/v1/responses; image input where the provider supports it - WorkBuddy daily check-in and token keepalive (per-account opt-in, off by default; console can check in now / refresh credits)
- Session-sticky routing from conversation content (first user message, including image-only turns), or via
X-CLI2API-Session, with rule-based failover when the bound account cannot serve the request - Request history filtering by account, plus request status, latency, token, and usage statistics
Longer term
- More upstream channels (Cursor, etc.)
- Optional prompt/completion capture behind an explicit switch (off by default)
The service binds 127.0.0.1:3010 by default; all APIs and console data endpoints require the API key except /health, static frontend assets, and CORS preflight OPTIONS for the OpenAI-compatible /v1/* endpoints. Never commit .qoder, tokens, cookies, auth blobs, or raw captures; credential export is an explicit sensitive operation — protect exported files. Upstream API or CLI changes may affect compatibility; qodercli is pinned and checked. Please report security issues privately according to SECURITY.md.
Chinese-language discussion is on LINUX DO. Bugs and feature requests still go to GitHub Issues.
Issues, documentation improvements, and pull requests are welcome — see CONTRIBUTING.md.
MIT — for personal learning use; please follow the terms of each upstream platform.