New-API v1.0.0 Released — finally “official”!

From 0.4.6.11.4 to 1.0.0 — New-API Finally Straightened Out Its Version Number

Recently, the open-source multi-model relay management tool New-API (QuantumNous/new-api) officially released version v1.0.0. For a project with over 28,000 stars, 232 contributors, and 481 releases on GitHub, this “1.0” didn’t arrive early—but it certainly arrived necessarily.

If you’ve ever built your own AI API gateway, you’ve likely heard of or even used New-API. What it does is simple: it unifies APIs from major model providers such as OpenAI, Anthropic, Google, DeepSeek, etc., wrapping them in a single OpenAI-compatible interface. On top of that, it adds operational features like channel management, token billing, load balancing, and user permissions. In plain terms, it’s a self-hosted model relay gateway.

But before version 1.0, the project’s versioning was nothing short of “performance art.”

The Chaos of Versioning — The Cost of Growth

If you scroll through New-API’s release page, you’ll find a rather fascinating version history:

• Early versions like v0.0.4, v0.0.5 followed the usual small-increment format
• Then it jumped to v0.9.x, v0.10.x, all the way to v0.12.x, v0.13.x
• At the same time, there were four-part versions like 0.4.6.11.1, 0.4.6.11.2, 0.4.6.11.3, 0.4.6.11.4
• Plus daily builds like nightly-20260409
• Finally, the formal release line: 0.1.0-alpha.1 → v1.0.0-rc.1 → v1.0.0-rc.2 → v1.0.0

Multiple version lines in parallel, mixing four-part and three-part numbering—common in open-source projects, but definitely confusing for users. Which branch should they follow? Which version is stable? Will upgrading break everything?

The release of v1.0.0 answers these questions: We now have a clear mainline—semantic versioning, officially maintained.

What v1.0.0 Brings

From rc.1 to rc.2 and then to the formal release, the core changes in v1.0.0 focus on several key aspects:

Seamless Switching Between Old and New Frontends

Starting with v1.0.0-rc.2, users can now freely switch between the new frontend and the classic one. This isn’t just a shiny feature—it solves a real pain point. New-API redesigned its frontend UI, but many veteran users have workflows deeply tied to the old interface. Removing the old frontend outright would’ve been too aggressive, but maintaining two separately was unsustainable.

The current solution lets users decide: try the new UI, and if it doesn’t feel right, switch back anytime. This “gradual migration” approach is far more user-friendly than a forced upgrade. For relay operators running their own gateways, frontend UX directly impacts users—smooth transitions are a must.

Stability Commitment at the Architectural Level

In the open-source world, version 1.0 carries a clear message: stable API, no arbitrary breaking changes. That’s particularly important for New-API’s user base.

Imagine a typical New-API setup: you run a relay hub with dozens of users, applications, and automation scripts downstream. If every upgrade could change endpoints, config formats, or database schemas, you’d never dare to update—and not upgrading means losing access to new models and security patches.

Version 1.0 says: From now on, upgrades won’t blow up your system. At least throughout the 1.x lifecycle, backward compatibility is guaranteed.

Formalized Version Management

Looking at the release history, the project team clearly tidied up its versioning before hitting 1.0:

• 0.1.0-alpha.1: first preview of the new architecture
• v1.0.0-rc.1: release candidate, feature freeze
• v1.0.0-rc.2: fixes for rc.1 and frontend switching enabled
• v1.0.0: official release

That’s a standard software release process. For a project that previously versioned somewhat casually, this alone signals maturity.

What Problem New-API Solves

If you haven’t used New-API yet, here’s how it’s positioned.

The large-model API ecosystem is fragmented. OpenAI has its own format, Anthropic’s Messages API uses another, Google Gemini follows the Google Cloud convention, and domestic models like DeepSeek, Zhipu, and Tongyi have their own schemas. If your app needs multiple models—say GPT-4o as the main one, Claude as backup, DeepSeek for cost-efficient tasks—you must integrate multiple SDKs and handle differing auth systems, request formats, and error codes.

New-API smooths out these differences. It adds a proxy layer that exposes an OpenAI-compatible interface externally while adapting various native APIs internally. Your app only needs to connect to one endpoint; switching models is just changing a parameter.

On top of that, New-API provides a full suite of operational features:

• Channel management: configure multiple upstream API providers with priorities and weights
• Load balancing and failover: automatically switch to backup channels when one fails
• Token billing: track usage by model and user, with quota control
• User and permission management: multi-user support and API key distribution for teams/commercial settings
• Payment integration: supports connecting to payment systems for paid relay stations

In short: New-API is a self-hosted AI API gateway + admin dashboard.

Who Uses It and How

GitHub stats: 28.2k stars, 5.9k forks—clearly a top-tier project in its category. 559 open issues and 117 pull requests also suggest a lively community.

Typical users include:

Individual developers — Have multiple API keys, want unified management and usage tracking. They deploy one New-API instance, configure all keys, and either use it themselves or share with friends.

Relay service operators — The core user group. Since accessing overseas APIs from China can be challenging, relay nodes deployed abroad solve connectivity issues. New-API is the most widely used backend for such services. The stability promise of v1.0.0 matters most here—these operators serve paying users and cannot risk downtime.

Internal enterprise platforms — Some companies build internal AI capability platforms with New-API as a unified gateway to manage cost, permissions, and audit usage.

AI app development teams — During development, they frequently switch models for benchmarking. New-API’s unified interface eliminates repetitive code changes.

Deployment is straightforward; the official recommendation is Docker Compose:

git clone https://github.com/QuantumNous/new-api.git
cd new-api
docker compose up -d

The backend is mainly written in Go (52.2%), the frontend in JavaScript (47.7%)—a mainstream stack with low barriers for customization.

Competitive Landscape

New-API isn’t the only player. In the multi-model relay space, both open-source and commercial options exist:

One-API — New-API’s upstream project, one of the earliest tools in this category. New-API extended it heavily, making features richer but also heavier. For basic relay capabilities, One-API might be more lightweight.

Commercial relay services — Platforms like OpenAI Hub offer hosted multi-model aggregation—call all mainstream models with one key, no self-deployment or maintenance needed. For developers who don’t want infrastructure hassle, these are convenient.

LiteLLM — A Python-based model proxy tool focusing on interface unification at the code level, different from New-API’s standalone gateway approach.

All API Hub — A community-built browser extension for managing multiple New-API instances—showing balances, comparing prices, auto check-ins. Its existence indicates that New-API’s ecosystem has grown large enough to need management tools.

New-API’s advantages: comprehensive functionality and a massive community. Its obvious drawback: self-hosting means managing servers, domains, SSL, database backups, and version upgrades—all operational overhead not trivial for individuals.

What to Watch After 1.0

Reaching version 1.0 marks a new stage. Several areas are worth attention:

New frontend maturity — Currently both UIs coexist, but the old one will inevitably be deprecated. Whether the new interface wins over longtime users will determine the success of this redesign.

Plugin and extension mechanisms — As model capabilities evolve rapidly—multimodal, function-calling, long-context, real-time voice—the relay layer must keep up. If every new feature requires modifying core code, maintenance cost will soar. A solid plugin system would let the community share the load.

Security — Relay stations are, by nature, proxy services: all API keys and request data pass through them. How many of those 559 open issues are security-related? How well is the project’s Security Policy enforced? These questions will draw more attention post-1.0.

Relationship with upstream One-API — New-API is a fork of One-API; both projects now evolve separately. As New-API’s 1.0 architecture solidifies, differences will grow and merging becomes increasingly unlikely. For users, that means clearer choices—but also a fragmented community.

A Few Thoughts

Frankly, v1.0.0 is more a project governance milestone than a feature explosion. It mainly fixes confusion in versioning and builds upgrade confidence, not introduces disruptive functionality.

But that’s precisely what New-API needs. For infrastructure relied on by thousands of relay stations, stability and predictability matter far more than shiny new features. No one wants their relay crashing at 3 a.m. after a “minor upgrade.”

From a broader view, New-API’s 1.0 reflects the maturation of the AI middleware ecosystem. Two years ago, developers struggled just to get the OpenAI API working. Now we have a full tooling chain around multi-model management, cost optimization, and traffic routing. Tools like New-API, One-API, LiteLLM, various commercial relays, plus ecosystem helpers like All API Hub—today’s landscape is richer than ever.

For developers, choices are now clear: want full control? Deploy New-API yourself. Want simplicity and peace of mind? Use a hosted aggregation service. Both paths work—the right one depends on your context and operational capacity.

Indeed, many open-source projects are shipping 1.0s recently—as one Linux.do user put it, “So many projects are releasing 1.0 versions lately.” Perhaps it signals that, after two years of rapid, chaotic growth, the AI tooling ecosystem is collectively entering a stabilization phase. For the broader community, that’s good news.

---

References

• Linux.do - Discussion on New-API v1.0.0 Release: Community discussion about New-API v1.0.0
• GitHub - QuantumNous/new-api Releases: Full release history of New-API
• GitHub - QuantumNous/new-api: Project homepage with docs and deployment guides
• Zhihu - Comparison of New-API Tools, Private Deployment, and Enterprise Gateway Architecture Analysis: Enterprise architecture analysis using New-API
• GitHub - All API Hub: Browser extension management tool for the New-API ecosystem