One-api grew up, got a billing department, and learned to cluster

What it does

one-api-pro is a Go-and-Vue-3 overhaul of the one-api gateway, unifying 30-plus LLM providers behind a single OpenAI-compatible endpoint. It layers on the corporate plumbing the original lacked: subscription plans with per-token or per-request billing, native WeChat Pay and Alipay integration, and a decentralized active-active cluster mode where nodes sync via application-layer events without sharing a single database.

The interesting bit

The real refactor is in the adaptor architecture. The original forced you to edit four framework files and a 56-line iota block to add a new provider; one-api-pro uses a self-registering registry, so a new vendor is just a new package plus a registration call. The cluster design is equally opinionated: every node carries its own MySQL and Redis, trading shared-state simplicity for geographic distribution without a database single point of failure.

Key highlights

• Self-registering provider registry: add a new LLM vendor by creating a package and registering it, without touching core framework code.
• Built-in subscription commerce: supports per-token and per-request plans, period limits, automatic prorated upgrades, and native WeChat Pay / Alipay checkout.
• Decentralized active-active clustering: nodes operate independent databases and sync state through application-layer events, aimed at multi-region deployments.
• Fine-grained access control: token-level model whitelists, IP subnet restrictions, and a four-tier permission system (Guest / User / Admin / Root).
• Precise cost accounting: independently priced prompt, completion, and cached tokens, with group discounts and channel-level RPM and concurrency limits.

Caveats

• Payment rails are China-first: WeChat Pay and Alipay are the only native options, so international teams face integration work.
• The README warns that enabling Redis is unnecessary—and can actually introduce data lag—if your database latency is already low.
• It is a heavy refactor of one-api, not a from-scratch gateway; you inherit its underlying design choices.

Verdict

Teams that need to monetize LLM access through subscriptions and precise per-token billing—especially if they operate in China or can tolerate China-centric payment rails—should look here. If you just need a lightweight internal API router without commercial bookkeeping, the original one-api or a simpler proxy is likely less baggage.