Choosing between One API and New API: an operations view, not a feature list

Start with the parent-child relationship

New API is a fork of One API. That single fact settles most of the decision:

• The database schemas are largely compatible: moving from One API to New API usually means swapping the image and mounting the same data volume, though you must back up the database file first in production.
• Channel configuration and the token model carry over, so there is no new conceptual model to learn.
• New API is updated more often, so it keeps up with new models and new protocols faster.

So the real question is not which one has more features, but which one fits the maintenance capacity you actually have.

1. Licence: settle the boundary first

This is the most easily overlooked point and possibly the most decisive.

• One API is MIT licensed. Commercial use and modification are essentially unrestricted.
• New API is AGPLv3. The constraint is that if you offer it to users as a service and you have modified the code, your modified version must also be released under AGPL.

For internal use, such as a team gateway or personal use, this changes nothing. For running a service, if your business model depends on keeping modifications to the gateway private, AGPL is a hard boundary. There has been debate about this in the industry, and it is worth settling before you make a commercial decision.

2. Protocol conversion: New API's core differentiator

This is the most substantive capability difference between the two.

One API's approach is to normalise everything to the OpenAI format: every channel is reshaped into OpenAI-compatible requests and responses, so the conversion it performs is mainly other formats into OpenAI.

New API adds bidirectional and multi-directional conversion on top:

• OpenAI to and from Claude messages, so you can call Claude channels with an OpenAI SDK or reach them with Anthropic's official SDK
• OpenAI to Gemini
• Gemini to OpenAI

The practical benefit is real: you can point Anthropic's official SDK, or a client like Claude Code, at your self-hosted gateway by changing base_url, with no translation layer in between. One API's native Claude and Gemini support is weaker, and its conversion ability is limited.

New API also supports OpenAI's Responses interface, Realtime, Rerank, Midjourney and Suno, all of which appeared or matured around 2026, and One API has followed more slowly.

3. Deployment and upgrades

Both ship as a single Go binary or a one-command Docker deployment, with SQLite for light use or MySQL for production.

Things to watch:

• One API has a history of version upgrades breaking the database schema, so back up before upgrading.
• New API is heavier and uses somewhat more resources, but its upgrade process is better disciplined.
• Neither solves networking: overseas models still need a proxy where one is required, and the gateway itself provides no route acceleration.

4. Where the maintenance time actually goes

Whichever you choose, the time is not spent installing. It goes to:

1. Channel health monitoring: when an upstream dies you need to know quickly. One API's built-in monitoring is weak, while New API has Prometheus and OpenTelemetry support.
2. Maintaining quotas and rates: when an upstream changes its pricing you have to follow, and this is manual work.
3. Bill reconciliation: a self-hosted gateway has no third-party invoice behind it, so when a user or a colleague questions their usage you need logs to show.
4. Alerting: low balance and surging channel failure rates should come to you, rather than you finding out because the business stopped.

On points 1 and 4, New API is plainly better out of the box.

5. Conclusion: a decision rule

Starting from scratch: go straight to New API. Migration cost is near zero, so changing later stays easy, while protocol conversion, monitoring, the interface and release frequency are all things you will eventually want. The time saved far outweighs the extra resource use.

Already running One API stably: do not migrate for new features. Unless you have a clear gap, such as needing native Claude protocol support or Midjourney. Six months of stable operation is value in itself, and risking a migration for a few interface components is a bad trade. The pragmatic industry view is that what decides the choice is usually not which has more features but who on your team maintains it.

Running a service with private modifications: settle the AGPL question first. If AGPL is an obstacle, One API under MIT is the safer starting point, or move to LiteLLM, a code-driven proxy configured entirely in YAML, and keep your commercial logic in your own service.

Appendix: where LiteLLM fits

LiteLLM is the other common option and occupies a different niche: written in Python, configured in pure YAML, and with no admin interface. Its advantage is that it is programmable, which suits embedding in internal services, CI pipelines and microservice architectures. Its disadvantage is the learning curve, since non-developers will struggle to maintain it.

In one line: choose New API for an interface and multi-user management, choose LiteLLM for embedding in code and pipelines.