New API combines a gateway with an operator console
New API routes many model providers through one service and exposes OpenAI, Claude, and Gemini-compatible interfaces. The admin side handles users, tokens, model restrictions, channel weights, retries, usage records, and cost accounting. That is more than a thin compatibility proxy. It is meant to be the control plane between an organization and its authorized upstream AI accounts. The repository's 359,391 lines of source reflect that scope, and the web console makes it usable by people who do not want to edit routing files for every change.
The appeal is strongest when one team owns access for many internal users. A token can be restricted by model, usage can be charged against assigned quota, and several provider channels can sit behind the same public model name. New API also supports OIDC plus Discord, Telegram, and LinuxDO login. Those features save work only when you need them. For a single application with 2 provider keys, they create an identity and billing system that you now have to patch, back up, and audit.
Protocol conversion covers 3 major API families, with gaps
The README lists native surfaces for OpenAI-compatible chat and Responses, Claude Messages, and Google Gemini. It can convert OpenAI-compatible requests to Claude and convert text requests between Gemini and OpenAI formats. This helps teams move clients without teaching every application each provider's payload. Other endpoints cover images, audio, embeddings, reranking, and realtime conversations, so the gateway is not limited to chat completions.
Conversion is not uniform. The README says Gemini-to-OpenAI function calling is not supported yet, while conversion between OpenAI-compatible calls and the Responses API is described as in development. Those limits matter because a 200 response on plain text says little about tool calls, streaming events, or provider-specific reasoning fields. Test the exact endpoint and model combination your application uses. With 1,339 open issues and PRs, edge cases are not a theoretical concern, even though that GitHub number includes proposed changes as well as bugs.
What happened when we ran it
Our sandbox cloned commit 2d8e50b into an unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installation succeeded in 181 seconds and fetched 828 Go packages. The checked-out tree contained 1,987 files, about 359,391 lines of source, and occupied 16.2 MB. The project also had 7 CI workflow files, a Dockerfile, and a Compose file, which is a reassuring amount of automation for a stateful gateway.
The build completed in 8 seconds. Tests were less clean: go test exited 1 after 149 seconds, with 33 packages passing and 1 failing out of 34. The supplied log tail shows a series of passing or no-test packages followed by FAIL; it does not name the failing assertion or establish why the package failed. We would reproduce that result with the full log before approving a production revision, rather than treating 33 passes as a green suite.
SQLite starts quickly, while production adds shared state
The shortest route is the published container on port 3000 with a mounted /data directory and SQLite. Docker Compose is the recommended route, and remote MySQL 5.7.8 or PostgreSQL 9.6 and newer are supported. A production instance needs upstream provider keys and a persistent SESSION_SECRET. Redis is optional, but the README recommends it for cache behavior and explains how it affects sessions and rate limits.
Multi-node deployment deserves close reading. Every node must share the primary database and SESSION_SECRET; nodes using the same Redis also need the same CRYPTO_SECRET. With independent Redis instances, session state converges from the database on a configurable interval, and rate limits apply separately on each node. That can multiply aggregate allowance by the number of nodes. The documentation is unusually direct about this topology, yet the operator still owns load-balancer trust, secure cookies, origin checks, backups, and secret rotation.
Billing features also create compliance work
New API can allocate quota, account for cache hits, and connect internal top-ups to payment systems such as Stripe or EPay. Those controls suit an organization distributing authorized access. They also make public resale a much higher-risk use than running an internal gateway. The README warns about licensing, content safety, identity checks, logs, tax, payments, and upstream authorization. None of those duties disappear because the deployment is open source.
The AGPL-3.0 license is another concrete decision point. A company modifying and offering the service over a network should have counsel or an experienced open-source lead review its obligations. The latest GitHub release, v1.0.0-rc.25, was published on 2026-08-18, and the last push was 2026-08-24. That is active development, not abandonment, but the release-candidate label and fast-moving provider adapters argue for pinned images and staged upgrades.
Choose it for managed access, not a two-key proxy
New API earns its operational weight when accounts, quotas, cost records, and protocol conversion belong in one place. The 8-second build in our run was easy; validating routing across providers and keeping a public gateway safe is the larger job. Teams with that job will find a substantial product here, especially if they are migrating a One API database.
For a small service that only needs retry and fallback, LiteLLM or Portkey Gateway is easier to reason about. New API asks you to own user sessions, billing logic, shared state, and fast-changing model adapters. Choose it when those are requirements rather than attractive checkboxes, and hold deployment until the single failed package in your own environment is explained.