The gateway handles accounts, users, and money
Sub2API sits between AI clients and upstream providers. An administrator adds OAuth or API-key accounts, then issues separate keys to users. The gateway records token use, calculates charges, applies rate and concurrency limits, and chooses an upstream account. It speaks familiar OpenAI, Anthropic, Gemini, and xAI shapes, which lets coding clients point at a new base URL instead of learning a private protocol.
This is more than a reverse proxy. The dashboard manages users, balances, account pools, model groups, payments, and usage. Sticky sessions can keep a conversation on one upstream account, while composite groups map a requested model to several possible providers. That scope explains the operational weight: our checkout contained 3,631 files and about 1,246,556 lines of source, with the Go project under backend/.
The default README is English and links full Chinese and Japanese versions. It is unusually candid about the legal boundary. Using subscription accounts this way may violate Anthropic or another provider's terms, and the maintainers say they have not authorized commercial operation based on the project. Those warnings belong in the deployment decision, not in a footer nobody reads.
What happened when we ran it
Our install at commit d45135d completed in 96 seconds and pulled 405 packages. The build then succeeded in 142 seconds. Running the Go tests took 196 seconds, with 48 passing and none failing, inside an unprivileged Debian container limited to 3 CPUs and 8 GB of RAM.
That is a clean engineering result. Four CI workflow files and a Dockerfile support the impression that the repository is worked on as deployable software. There is no dedicated tests directory, but the Go test command found and passed 48 tests. We did not test live upstream accounts, billing providers, OAuth refresh, or traffic under load because the sandbox had no secrets.
The clean run should be read narrowly. It shows that the measured commit installed, compiled, and passed its available Go suite in our environment. It does not show that a provider permits subscription relay, that balances reconcile under failures, or that an internet-facing deployment is secure. Those require contract review and application-specific testing.
Docker Compose still leaves production decisions to you
The shortest full-stack path uses Docker Compose with PostgreSQL and Redis containers. A script installer is also available for Linux servers, but it needs root privileges plus PostgreSQL 15 or newer and Redis 7 or newer already running. Source builds add Go, Node, pnpm, migrations, frontend assets, and a configuration file.
Credential work starts after the containers boot. You need secure database and admin passwords, provider API keys or OAuth accounts, and possibly Stripe, Alipay, WeChat Pay, or EasyPay settings. The setup wizard creates the first administrator. The README warns that copying a template configuration too early skips that wizard and can leave an empty users table, producing an invalid-login loop.
Reverse proxies have a less obvious requirement. Codex sticky sessions use a header containing the _ character, and Nginx drops those headers by default. The documented fix enables them in the Nginx http block. If an operator misses that line, ordinary requests can still work while session routing fails, which makes the mistake harder to spot.
Default URL handling needs tightening before exposure
The Compose setup permits HTTP URLs when the URL allowlist is disabled. The README calls this developer-friendly and gives production settings for HTTPS-only behavior, blocked private networks, and an explicit allowlist. That is important because a gateway which fetches operator-supplied or provider URLs can become an attractive route toward internal services.
Sub2API also concentrates secrets and financial state. Upstream tokens, local API keys, balances, payment callbacks, request logs, and Redis coordination all sit within one trust boundary. A competent operator should isolate the service, terminate TLS, restrict admin access, rotate credentials, back up PostgreSQL, and test restoration. None of those chores disappear because docker compose up succeeds.
Simple mode removes user management and billing for a personal deployment. Even there, production startup requires an explicit confirmation setting. That is a sensible guard because removing the dashboard workflow does not remove upstream-account risk or the need to protect the gateway key.
The provider warning decides the use case
Sub2API is technically shaped for shared access, but permission comes from each upstream provider. An official API account used within its contract is a different proposition from pooling consumer subscriptions and selling access. The repository's warning explicitly mentions account bans, interruptions, and data loss. An operator cannot transfer those risks back to the maintainers.
The sponsor section makes this tension more visible. Many listed services advertise discounted relay access, account products, or proxy infrastructure, while the project says commercial operation is unauthorized. That does not prove any sponsor violates a rule. It does mean buyers should ignore marketing adjacency and read the exact terms for every account placed behind the gateway.
A huge active queue calls for pinned upgrades
GitHub reported 2,872 open issues and PRs on August 27, 2026. The repository was pushed that day, while release v0.1.183 was published on August 25, so the project is plainly active. The count is not a defect total because GitHub combines issues and pull requests, but it is too large to treat as a tidy support queue.
Recent activity covers Codex Responses compatibility, usage aggregation, account import, and provider-specific behavior. This is the normal churn of a gateway tracking several upstream protocols, yet it creates upgrade risk. Pin a release, read changes between versions, back up state, and test the clients and providers you use before replacing a running instance.
Choose Sub2API when you have authorization, need its user and billing plane, and can operate a sensitive stateful service. For one application calling one provider, an official SDK is easier to reason about. For multi-provider applications using standard API credentials, a narrower gateway avoids the subscription-policy question entirely.