Should you use Sub2API?
Choose Sub2API for an authorized pool of upstream AI accounts when you need user keys, billing and account scheduling. Its README warns that use may violate upstream providers' terms. Confirm permission for the account types and sharing arrangement before importing credentials. Passing repository checks cannot resolve that permission question.
The README at the measured commit describes OAuth and API-key accounts, platform-issued user keys, token accounting, sticky sessions and per-user and per-account concurrency limits. Those features address the work of operating an account pool. They also introduce a database, cache and administrative service that a direct provider integration may not need.
What our September 28 run establishes
Our run on September 28, 2026 used commit 9a62841 in our sandbox. The full recorded commit is 9a62841fd124d026cf3694fcf9b79e98addcdbdc. The attached harness records the install step at 85 seconds, build at 237 seconds and tests at 268 seconds. Each step returned exit code 0 without timing out; the build tail ends with vet-exit:0.
The stored parser summaries report 104 passed, 0 failed and 104 total. The matching raw record calls these package outcomes: packagesOk is 104 and packagesFail is 0, with 57 packages recorded separately as having no tests. The retained output also includes a package marked [no tests to run]. These summaries do not establish exhaustive, unique individual-test coverage, and we have not reconciled complete logs or performed a new execution.
The sandbox had 3 CPUs, 8 GB of memory and the golang:1.24-bookworm image. Its install tail says go: downloading go1.27.0 (linux/amd64), so describing the run simply as a Go 1.24 test would be misleading.
Our harness records command status, exit code, elapsed time, timeout status and parsed outcomes separately. The testing methodology explains that distinction and the limits of sandbox testing. That page describes the publisher's methodology today; it does not establish which methodology revision governed this September run.
The supplied record does not demonstrate a deployed gateway, successful CLI integration, live OAuth refresh, payment processing, upstream account scheduling or sustained traffic. Audit data is absent, and dependency scan coverage is unknown. The command results support a repository evaluation, not a security or production-readiness finding.
Deployment adds work beyond the green commands
The measured commit's README requires PostgreSQL 15+ and Redis 7+. Its Compose deployment includes both services; its binary installer requires root and already running database and Redis services. Neither deployment path was exercised by our recorded command outcomes.
Source builders should read the first-admin warning before following the configuration-copy step. The README says an existing configuration skips the setup wizard, while the historical admin fields in that configuration do not create the initial administrator. Follow the documented wizard procedure rather than assuming those fields provision a login.
The same README documents legacy forwarded-header trust enabled for upgrade compatibility. It tells operators to restrict origin access to their proxies and have the edge overwrite trusted client-IP headers. It also warns that disabling URL allowlist validation permits HTTP upstream URLs by default. Review proxy trust, require HTTPS upstream traffic and restrict outbound destinations before exposing a deployment.
The measured commit changes the version to 0.2.9. The separately supplied 0.2.10 release is not the version tested here. Current README instructions should also be checked against the version you actually deploy.
When another gateway fits better
LiteLLM supports direct Python SDK integration as well as a centralized proxy server. Its README makes it a candidate when you need a common interface across provider APIs, either inside an application or behind a team gateway. That is an alternative integration approach; this review does not establish equivalent subscription-account behavior or comparative performance.
New API manages upstream model services through a consistent client API and a web console. Its README makes it a candidate when channel configuration, usage accounting and protocol conversion are the main requirements. It warns that conversion features depend on the upstream model and conversion path, and it also requires authorized upstream access. Switching gateways does not remove provider obligations.
These are replacement candidates for the gateway role, not required companions to Sub2API. We did not run either alternative for this correction.
How the ratings should be read
These are editorial assessments, not benchmark results. For each assessed dimension, 1 means substantial documented obstacles, 2 means several unresolved obstacles, 3 means workable with material operating work or validation gaps, 4 means strong documented support with remaining limits, and 5 requires broader corroboration than this record provides. An unassessed dimension means the necessary evidence is missing.
Setup ease is 3/5: repository commands succeeded, but deploying the service requires PostgreSQL, Redis, secrets and careful first boot. Documentation is 4/5: the README covers deployment and concrete network settings, although its configuration-copy procedure needs the later administrator warning to avoid a failed first login. Maturity is 3/5: the recorded 0.2.9 commands succeeded, but live operation and upgrade behavior remain untested here. Community is unassessed because the supplied independent extracts do not establish response times, contributor continuity or support outcomes.