Metapi Open Source: The hub of hubs has arrived

Too Many Relay Stations — So Someone Built a Relay Station for Relay Stations

An open-source project called Metapi has recently become popular in the Linux.do community — the discussion thread has reached 58 pages. The problem it solves is quite straightforward: you’re holding five or six New API / One API / OneHub site Keys, your balances are scattered, model lists inconsistent, and you have to manually check in on each site — can’t there be one gateway to unify all of that?

Metapi does exactly that. Its name comes from “Meta” — as in metadata — a relay station for relay stations.

What It Is

Simply put, Metapi is a self-hosted unified gateway. You feed it the tokens of the relay stations you’ve registered elsewhere, and it will:

• Aggregate model lists from all upstream sites, exposing only one Key downstream
• Automatically route requests to the corresponding upstream sites
• Automatically check in at regular intervals — no more manual claiming of daily free quotas on public sites
• Monitor site balances and alert you when funds are running low

It is not another New API. Projects like New API / One API are designed to “set up relay stations for others to use,” featuring full user management, billing, and distribution systems. Metapi takes the opposite approach — it removes user management, keeping only an admin token, and explicitly positions itself as a personal utility.

This distinction matters. If you’re a relay site operator, you don’t need Metapi. But if you’re a developer registered on various relay stations and constantly switching between different dashboards, then this tool is for you.

Why the Need Exists

Here’s roughly how the AI API ecosystem has evolved over the past two years:

Phase 1: OpenAI dominated, and everyone used official Keys directly.
Phase 2: More models appeared (Claude, Gemini, DeepSeek, Qwen…), and relay stations emerged — one site aggregating multiple model providers.
Phase 3: Relay stations themselves multiplied — commercial, public, and privately hosted sites. Each supported different models and had different pricing.

By the third phase, management costs ballooned. A heavy user might have:

• 2–3 commercial relay stations (each with different pricing; model A cheaper on one site, model B cheaper on another)
• 1–2 public/free stations (free quota but require daily check-in)
• 1 self-hosted site (running open-source models)

That’s five or six dashboards, keys, and balance systems. Client apps (ChatBox, NextChat, Cursor, etc.) accept only one API endpoint — so what do you do? The old approach was manual switching or using tools like Sub2API to convert subscriptions. Metapi offers a more systematic solution.

Technical Implementation

Metapi’s GitHub repository (cita-777/metapi) shows that the project is Python-based and built around a reverse proxy gateway compatible with the OpenAI API format.

Workflow:

1. Add upstream sites in the Metapi dashboard (input each relay station’s base_url and API Key)
2. Metapi automatically fetches the model list supported by each upstream
3. It routes requests according to your routing rules, deciding which upstream handles each model
4. Downstream clients need only configure Metapi’s endpoint and unified Key

Routing strategies support prioritization and load balancing. For example, you can specify: GPT-4o requests go to Site A first (because it’s cheaper), and automatically fall back to Site B when A’s balance runs low.

The automatic check-in feature is another highlight. Many public relay sites require daily check-ins to claim free quotas. Metapi includes a scheduled task system supporting the major check-in protocols. For users relying on these public sites for quotas, this saves a lot of effort.

Pitfalls in Real Use

According to community feedback, Metapi is still rapidly evolving and has a few known issues.

One typical example: users report “I’ve added the upstream site’s token, but the router keeps showing it as an unregistered site; rebuilding the route doesn’t help.” This suggests a state synchronization bug between site registration and route construction — token validation succeeding doesn’t guarantee the route works automatically.

Additionally, since relay station implementations vary (some based on New API, others on One API, and some on OneHub), Metapi inevitably encounters compatibility issues when adapting to different upstreams. Model list formats, balance query interfaces, and check-in methods all differ slightly.

That’s why the project’s documentation center (docs.metapi) dedicates substantial space to operational support and troubleshooting — for an “aggregation of aggregations” tool, the number of possible error combinations is indeed much higher than for a single relay station.

Comparison with Similar Tools

Before Metapi, the similar tool popular in the community was Sub2API. Their core ideas are similar but with different focuses:

| Dimension | Sub2API | Metapi | |------------|----------|--------| | Core Feature | Subscription → API conversion | Multi-site aggregation gateway | | Check-in | Not supported | Built-in auto check-in | | Routing Strategy | Basic | Supports prioritization & load balancing | | Balance Monitoring | Limited | Unified dashboard | | User Management | None | None (deliberately removed) | | Deployment Complexity | Low | Moderate |

From community discussions, many users migrated from Sub2API to Metapi. Metapi offers more complete functionality, but deployment and configuration are relatively more complex. If you only manage a couple of sites and don’t need auto check-in, Sub2API may suffice. If you handle many sites and want fine-grained routing control, Metapi fits better.

Who Should Use It

Let’s clarify:

Suitable for:

• Individual developers registered on multiple relay stations and seeking unified management
• Users leveraging public sites’ free quotas, requiring auto check-in
• Users preferring certain upstreams for different models (based on price, speed, or stability) who want smart routing
• Those using clients like Cursor or ChatBox and only want to configure one API endpoint

Not suitable for:

• Operators setting up relay stations for others (Metapi has no user management; use New API instead)
• Users with only one relay station (no need for aggregation)
• Environments demanding high stability for production (the project is early-stage; bugs are inevitable)

Some Assessment

Metapi addresses a real pain point, though the audience is not large. It precisely targets the group of individuals deeply involved in the AI API ecosystem and managing multiple relay stations — active in communities like Linux.do but a minority among all developers.

However, that’s the charm of open-source tools — they don’t need millions of users, only to help a few thousand people with the same problem. Judging from the 58-page thread, Metapi clearly hit that niche demand.

The project’s risk lies in its dependence on the continued prosperity of the relay station ecosystem. If official API prices from model providers keep dropping and domestic access barriers ease, relay stations themselves may lose relevance — and Metapi, as a “relay station for relay stations,” would naturally lose its footing. But for now, the ecosystem is still expanding, and Metapi arrived just in time.

For developers already using all-in-one aggregation platforms such as OpenAI Hub, Metapi’s value may not seem urgent — since one platform already aggregates mainstream models. But if you also hold Keys from smaller or public sites and want unified management, using both together is perfectly fine.

Deployment Tips

If you decide to give it a try, here are a few suggestions:

• Start with two or three sites; don’t dump all Keys at once — routing takes tuning
• Watch GitHub Issues — the current “unregistered site” synchronization issue is common
• For auto check-in, manually verify each site’s check-in works before enabling the scheduled task
• Back up your upstream Keys — Metapi doesn’t store model data, it only forwards requests

---

References

• Metapi Discussion Thread (Linux.do) — Project release and user feedback, now over 58 pages of discussion
• Metapi GitHub Repository — Source code, documentation, and issue tracking