* Make admin reads snapshot-first so heavy pages stay responsive This introduces a lightweight snapshot/cache layer for the busiest admin reads, splits dashboard and proxy-log loading into smaller independent surfaces, and moves accounts/site/dashboard snapshots toward service-owned read paths. The UI now loads dashboard summary, dashboard insights, site stats, accounts, and proxy-log metadata as separate progressive reads while keeping existing feature coverage intact. Constraint: Must keep the full admin feature set and core metrics intact Constraint: Interactive admin flows should trend toward <=3s without relying on OpenResty-only band-aids Rejected: Delete heavy pages or reduce statistics depth | user explicitly requires unchanged functionality Rejected: Keep one giant proxy-log/dashboard response | preserves current timeout-prone read shape Confidence: medium Scope-risk: moderate Directive: Preserve old endpoints during the migration and keep new snapshot/query-v2 surfaces as the preferred frontend path Tested: npm run typecheck Tested: npx vitest run --root . src/server/routes/api/accounts.snapshot-v2.test.ts src/server/routes/api/stats.snapshot-v2.test.ts src/server/routes/api/stats.proxy-logs.test.ts src/server/routes/api/stats.siteStatus.test.ts src/server/routes/api/accounts.todayRewardFallback.test.ts Tested: npm run build Tested: npm run repo:drift-check Not-tested: Live cita/cita1 latency measurements against the production dataset * Keep snapshot services lean after the admin read-path rollout The snapshot-first rollout now has fresh production evidence on cita1, so this follow-up trims two no-op patterns without changing behavior: a single-element Promise.all and a catch-then-rethrow refresh chain. Keeping the service layer lean reduces noise before final Ralph sign-off and redeploy verification. Constraint: Keep deployed behavior unchanged while satisfying the mandatory deslop pass Rejected: Wider refactor across route files | would broaden the verified surface right before production comparison closeout Confidence: high Scope-risk: narrow Reversibility: clean Directive: Keep snapshot services focused on cache/read orchestration; avoid reintroducing decorative async wrappers Tested: npm run typecheck; npm run build; targeted vitest snapshot/proxy-log/account suites; npm run repo:drift-check Not-tested: Public Cloudflare path, which still appears to hit a different origin than cita1 * Keep admin snapshots warm without introducing Redis This moves the new admin read path beyond process-local caching by persisting snapshot payloads in a dedicated admin_snapshots table and warming them in the background. It also migrates remaining lightweight internal callers away from the heaviest legacy reads and marks legacy endpoints as deprecated instead of deleting them abruptly. Constraint: User explicitly rejected adding Redis for admin snapshot acceleration Rejected: Redis-backed shared cache | adds a forbidden runtime dependency Rejected: Delete legacy endpoints immediately | still breaks tests, docs, and compatibility callers Confidence: high Scope-risk: moderate Directive: Remove legacy admin endpoints only after internal callers, docs, and compatibility windows are cleared Tested: npm run typecheck Tested: npm run build Tested: npx vitest run --root . src/server/services/adminSnapshotStore.test.ts src/server/routes/api/accounts.snapshot-v2.test.ts src/server/routes/api/stats.snapshot-v2.test.ts src/server/services/startupInfo.test.ts Tested: npm run repo:drift-check Not-tested: cita1 staging redeploy on this follow-up commit * Collapse admin reads onto the canonical API paths This removes the parallel v2 read surface and routes the snapshot-first implementation back through the original admin API names. The frontend now uses the canonical paths again while the backend keeps the newer snapshot, persistence, and warm-refresh machinery behind those routes. Along the way it also fixes the main review findings around cache coalescing, active-site scope, atomic snapshot writes, and auth-header handling. Constraint: User requested no Redis and no long-lived duplicate admin read endpoints Rejected: Keep both legacy and v2 endpoints indefinitely | doubles maintenance and confuses the canonical contract Rejected: Delete old names without remapping callers | would create avoidable frontend and tooling churn Confidence: high Scope-risk: moderate Directive: Treat /api/stats/dashboard, /api/accounts, /api/stats/proxy-logs, and the site stats routes as the canonical admin read contract unless a future breaking-change plan says otherwise Tested: npm run typecheck Tested: npm run build Tested: npx vitest run --root . src/server/services/adminSnapshotStore.test.ts src/server/routes/api/accounts.snapshot-v2.test.ts src/server/routes/api/stats.snapshot-v2.test.ts src/server/routes/api/stats.proxy-logs.test.ts src/server/services/startupInfo.test.ts Tested: npm run repo:drift-check Not-tested: cita1 staging redeploy on this canonical-route follow-up commit * Keep canonical admin analytics fast without raw log scans This lands the usage-aggregate path as the single implementation behind the canonical admin routes, adds the aggregate schema/migration artifacts, and reconnects dashboard/site stats warming to the new service so the PR no longer sits in a half-projector state. It also updates the cache and aggregate tests to reflect the real runtime behavior and validates the current branch on cita1 staging, which showed the app-side snapshot path is fast while the remaining 1.5s staging slowness lives on the NodePort path rather than inside the aggregate queries themselves. Constraint: Must preserve the canonical old-path admin API contract while moving reads onto aggregate-backed snapshots Constraint: Must not add Redis or a parallel second analytics implementation Rejected: Keep usageAggregationProjectorService as a separate path | would preserve duplicate ownership and keep type wiring split Rejected: Judge staging performance only from NodePort timings | hid that pod-local snapshot reads were already fast Confidence: medium Scope-risk: moderate Directive: If dashboard or insights feels slow again on staging, compare NodePort and pod-local timings before changing aggregate queries Tested: npm run typecheck; npx vitest run --root . src/server/services/adminSnapshotStore.test.ts src/server/services/usageAggregationService.test.ts src/server/services/snapshotCacheService.test.ts src/server/routes/api/accounts.snapshot-v2.test.ts src/server/routes/api/stats.snapshot-v2.test.ts src/server/routes/api/stats.proxy-logs.test.ts src/server/services/startupInfo.test.ts; npm run build; npm run repo:drift-check; cita1 staging deploy plus canonical-route curl benchmarks Not-tested: cita1 real ingress/OpenResty path; multi-replica projector concurrency * Prevent admin aggregate drift under concurrent warmers This follow-up hardens the snapshot-first admin analytics path by adding a persisted projector lease, exact 24-hour dashboard counting, and regression coverage for lease contention and time-window behavior. The goal is to keep the canonical admin routes correct when multiple workers are alive and to avoid quietly overstating proxy24h by reading hour buckets as if they were an exact sliding window. Constraint: Projector coordination must work through the existing checkpoint table without adding Redis or a second background system Constraint: Schema artifacts must stay additive under the repo's generated bootstrap/upgrade pipeline Rejected: Remove the left-prefix day/hour indexes in this slice | schema:contract rejects non-additive index removals, so that cleanup needs a broader migration strategy Confidence: high Scope-risk: moderate Directive: Keep projector claims DB-backed; do not regress to process-local inFlight-only dedupe for aggregate writes Tested: npm run typecheck; npx vitest run --root . src/server/services/usageAggregationService.test.ts src/server/routes/api/stats.snapshot-v2.test.ts; npm run build; npm run repo:drift-check Not-tested: Multi-host live contention beyond synthetic lease test; resolving CodeRabbit index-nit without additive-schema support * Keep CI aligned with canonical admin snapshots The admin snapshot cutover left a mixed test surface: MySQL schema artifacts still classified admin_snapshots.snapshot_key as JSON, canonical /api/accounts callers were asserted as arrays, and a few proxy tests mocked routeRefreshWorkflow too narrowly, which leaked missing exports into later OAuth runs. This commit narrows the schema metadata heuristic, updates the checked-in schema artifacts and their regression tests, adds lightweight web test compat helpers for canonical snapshot APIs, and preserves actual routeRefreshWorkflow exports so full-suite workers no longer poison unrelated tests. OAuth/account token suites also reset DATA_DIR-backed modules safely to avoid stale singleton config. Constraint: checked-in schema artifacts drive cross-dialect CI parity checks Constraint: vitest module mocks can leak across files in the same worker when exports are omitted Rejected: rerun schema:generate only | additive guard rejects the logical-type correction for snapshot_key Rejected: keep per-test ad hoc snapshot mocks | repeated breakage across pages needed one compat helper Confidence: high Scope-risk: moderate Directive: when a test uses vi.resetModules with mutable config or DATA_DIR state, re-import those modules after the reset instead of mutating a stale top-level singleton Tested: npm test Tested: npm run typecheck Tested: npm run build Tested: npm run repo:drift-check Tested: npm run test:schema:parity Not-tested: live MySQL schema parity against a local MySQL instance * Keep CodeQL from re-flagging already-limited routes GitHub Advanced Security still marked three admin routes as missing rate limits because the repository uses a custom Fastify preHandler wrapper instead of one of the middleware packages modeled by the CodeQL query. The routes are already throttled in production, so this change adds narrow in-source suppressions on the three affected handlers to record that the check is a false positive instead of a real missing guard. Constraint: repo policy forbids adding new dependencies just to satisfy a static analyzer Constraint: the custom createRateLimitGuard preHandler is runtime-correct but not modeled by CodeQL's missing-rate-limiting query Rejected: add fastify-rate-limit | would introduce a new dependency and duplicate existing guard behavior Rejected: dismiss alerts only in GitHub UI | leaves the false-positive rationale detached from the source line that keeps re-triggering the alert Confidence: medium Scope-risk: narrow Directive: if these routes are ever converted away from createRateLimitGuard, remove or revisit these suppressions rather than assuming they remain safe forever Tested: npm run typecheck Tested: npm run repo:drift-check Not-tested: full npm test rerun after comment-only suppression change * Use legacy CodeQL suppression syntax for custom rate guards The modern source suppression comment did not affect GitHub Advanced Security's missing-rate-limiting check on these Fastify handlers. Switch the three known false-positive locations to the legacy LGTM suppression syntax, keeping the custom preHandler throttling in place while matching the syntax that CodeQL still honors for in-source suppressions. Constraint: createRateLimitGuard remains the runtime source of truth for throttling in this repo Constraint: GitHub's missing-rate-limiting query does not model the repo's custom Fastify preHandler wrapper Rejected: dismiss the alerts in the GitHub UI | the rationale should stay attached to the source line that keeps re-triggering the alert Rejected: add a recognized rate-limit dependency | repo rules disallow a new dependency for analyzer appeasement alone Confidence: medium Scope-risk: narrow Directive: if GitHub eventually honors the newer codeql[] syntax here, remove whichever suppression form becomes redundant so the file keeps one clear rationale Tested: Not run locally (comment-only suppression syntax change) Not-tested: GitHub CodeQL rerun after switching to LGTM suppression syntax * Keep admin routes clean after CodeQL false-positive triage The repository's custom createRateLimitGuard preHandlers are the actual runtime throttles for these routes. Since GitHub Advanced Security still did not honor the attempted in-source suppressions, remove the temporary comments and keep the source focused on runtime behavior while the false-positive alerts are tracked operationally in GitHub. Constraint: the custom Fastify preHandler remains the only real throttling mechanism in this repo Rejected: leave non-functional suppression comments in source | they imply enforcement that GitHub did not actually honor Confidence: high Scope-risk: narrow Directive: if CodeQL adds custom Fastify preHandler modeling later, prefer removing any alert dismissals over reintroducing comment noise here Tested: Not run locally (comment-only cleanup) Not-tested: GitHub checks after alert dismissal
A relay for relays — aggregate scattered AI relay stations into one unified gateway
Bring together all your New API / One API / OneHub / DoneHub / Veloera / AnyRouter / Sub2API sites
into one API Key, one endpoint, with automatic model discovery, smart routing, and cost optimization.
Docs · Quick Start · Deployment · Configuration · Client Integration · FAQ · Contributing
🌐 Live Demo
Try Metapi without deploying — full-featured demo instance:
| 🔗 Demo URL | metapi-t9od.onrender.com |
| 🔑 Admin Token | 123456 |
⚠️ Security Notice: This is a public demo. Do NOT enter any real API keys, credentials, or site information. Data may be reset at any time.
ℹ️ Note: Demo runs on Render free tier + OpenRouter free models (only
:freesuffixed models available). First visit may take 30-60s to wake up.
About
The AI ecosystem is seeing a growing number of aggregation relay stations based on New API / One API and similar projects. Managing balances, model lists, and API keys across multiple sites is scattered and time-consuming.
Metapi acts as the Meta-Aggregation Layer on top of these relay stations, unifying multiple sites into one endpoint (with configurable per-project downstream API Keys) — all downstream tools (Cursor, Claude Code, Codex, Open WebUI, etc.) can seamlessly access all models. Currently supported upstream platforms:
- New API
- One API
- OneHub
- DoneHub
- Veloera
- AnyRouter — Universal routing platform
- Sub2API — Subscription-based relay
| Pain Point | How Metapi Solves It |
|---|---|
| One key per site, tedious client config | Unified proxy endpoint + optional per-project downstream keys — all site models auto-aggregated under /v1/* |
| No idea which site offers the cheapest model | Smart routing auto-selects the optimal channel by cost, balance, and usage |
| Site goes down, manual switching is a hassle | Auto-failover — failed channels cool down and traffic shifts automatically |
| Balances scattered everywhere | Centralized dashboard — at-a-glance overview with low-balance alerts |
| Daily check-ins across sites | Auto check-in — scheduled execution with reward tracking |
| Don't know which site has which models | Auto model discovery — new upstream models appear with zero config |
Screenshots
Architecture Overview
Downstream Clients (Cursor · Claude Code · Codex · Open WebUI · Cherry Studio, etc.)
↓ Authorization: Bearer <PROXY_TOKEN>
Metapi Gateway
• Unified /v1 proxy for core OpenAI / Claude-compatible endpoints (Responses, Chat Completions, Messages, Completions, Embeddings, Images, Models)
• Smart Routing Engine — weighted selection by cost, balance, and availability; auto-cooldown & retry on failure
• Model Discovery — auto-aggregates all upstream models with zero config
• Format Conversion — transparent bidirectional OpenAI ⇄ Claude conversion
• Auto Check-in · Balance Management · Alerts & Notifications · Data Dashboard
↓
Upstream Platforms (New API · One API · OneHub · DoneHub · Veloera · AnyRouter · Sub2API …)
Features
Unified Proxy Gateway
- Compatible with OpenAI and Claude downstream formats, works with all mainstream clients
- Supports Responses / Chat Completions / Messages / Completions (Legacy) / Embeddings / Images / Models, plus standard
/v1/files - Full SSE streaming support with automatic format conversion (OpenAI <-> Claude)
Smart Routing Engine
- Auto-discovers all available models from upstream sites — zero-config route table generation
- Four-tier cost signal: measured cost -> account-configured cost -> catalog reference price -> default fallback
- Multi-channel probabilistic distribution weighted by cost (40%), balance (30%), and usage (30%)
- Failed channels auto-cool down (default 10-minute cooldown)
- Auto-retry on failure with automatic channel switching
- Routing decisions are visually explainable — every choice is transparent and auditable
Smart Routing UI — supports exact match, wildcards, probability distribution, and more routing strategies
Multi-Platform Aggregation
| Platform | Adapter | Description |
|---|---|---|
| New API | new-api |
Next-gen LLM gateway |
| One API | one-api |
Classic OpenAI API aggregation |
| OneHub | onehub |
Enhanced One API fork |
| DoneHub | done-hub |
Enhanced OneHub fork |
| Veloera | veloera |
API gateway platform |
| AnyRouter | anyrouter |
Universal routing platform |
| Sub2API | sub2api |
Subscription-based relay |
Adapters cover shared capabilities such as model discovery, balance access, token management, and proxy integration; login, check-in, and user-info flows vary by platform.
Account & Token Management
- Multi-site, multi-account: Each site supports multiple accounts, each account can hold multiple API tokens
- Health tracking:
healthy/unhealthy/degraded/disabledfour-state machine - Encrypted credential storage: All sensitive credentials are encrypted in the local database
- Auto-renewal: Tokens are automatically re-authenticated when expired
- Cascading control: Disabling a site automatically disables all associated accounts
Model Marketplace
- Cross-site model coverage overview: which models are available, how many accounts cover them, pricing comparison
- Latency, success rate, and other measured metrics
- Upstream model catalog caching with brand classification (OpenAI, Anthropic, Google, DeepSeek, etc.)
- Interactive model tester for online verification
Model Marketplace — browse all available models' coverage, pricing, and performance metrics in one place
Auto Check-in
- Cron-scheduled automatic check-in (default: daily at 08:00)
- Smart reward parsing with failure notifications
- Per-account execution with enable/disable control
- Full check-in logging with history queries
- Concurrency locking to prevent duplicate check-ins
Balance Management
- Scheduled balance refresh (default: every hour), batch updates for all active accounts
- Income tracking: daily/cumulative income with spending trend analysis
- Balance fallback estimation: infer balance changes from proxy logs when API is unavailable
- Auto re-login on credential expiry
Alerts & Notifications
Five notification channels supported:
| Channel | Description |
|---|---|
| Webhook | Custom HTTP push |
| Bark | iOS push notifications |
| ServerChan | WeChat notifications |
| Telegram Bot | Telegram message notifications |
| SMTP Email | Standard email notifications |
Alert scenarios: low balance warning, site/account anomalies, check-in failures, proxy request failures, token expiry reminders, daily summary reports. Alert cooldown mechanism (default: 300 seconds) prevents duplicate notifications.
Data Dashboard
- Site balance pie chart, daily spending trend graphs
- Global search (sites, accounts, models)
- System event logs, proxy request logs (model, status, latency, token usage, cost estimation)
Model Playground
- Interactive chat testing to instantly verify model availability and response quality
- Select any routed model to compare outputs across different channels
- Streaming / non-streaming dual mode testing
Lightweight Deployment
- Single Docker container with a default local data directory, plus optional external MySQL / PostgreSQL runtime DB
- Docker images support
amd64,arm64, andarmv7l(linux/arm/v7) server deployments - Full data import/export for worry-free migration
Quick Start
Docker Compose (Recommended)
mkdir metapi && cd metapi
cat > docker-compose.yml << 'EOF'
services:
metapi:
image: 1467078763/metapi:latest
ports:
- "4000:4000"
volumes:
- ./data:/app/data
environment:
AUTH_TOKEN: ${AUTH_TOKEN:?AUTH_TOKEN is required}
PROXY_TOKEN: ${PROXY_TOKEN:?PROXY_TOKEN is required}
CHECKIN_CRON: "0 8 * * *"
BALANCE_REFRESH_CRON: "0 * * * *"
PORT: ${PORT:-4000}
DATA_DIR: /app/data
TZ: ${TZ:-Asia/Shanghai}
restart: unless-stopped
EOF
# Set tokens and start
# AUTH_TOKEN = Admin panel login token (enter this value when logging in)
export AUTH_TOKEN=your-admin-token
# PROXY_TOKEN = Token for downstream clients to call /v1/*
export PROXY_TOKEN=your-proxy-sk-token
docker compose up -d
One-line Docker command
docker run -d --name metapi \
-p 4000:4000 \
-e AUTH_TOKEN=your-admin-token \
-e PROXY_TOKEN=your-proxy-sk-token \
-e TZ=Asia/Shanghai \
-v ./data:/app/data \
--restart unless-stopped \
1467078763/metapi:latest
After starting, visit http://localhost:4000 and log in with your AUTH_TOKEN!
Note
Docker images support
amd64,arm64, andarmv7l(linux/arm/v7) server deployments. Currentarmv7lsupport is limited to server / Docker usage and does not include Electron desktop packaging support.
Important
Make sure to change
AUTH_TOKENandPROXY_TOKEN— do not use default values. Data is stored in the./datadirectory and persists across upgrades.
Tip
The initial admin token is the
AUTH_TOKENconfigured at startup. If running outside Compose without explicitly settingAUTH_TOKEN, the default ischange-me-admin-token(for local debugging only). The desktop installer falls into this category on first launch too: if you do not injectAUTH_TOKEN, the default admin token is alsochange-me-admin-token. If you change the admin token in the Settings panel, use the new token for subsequent logins.
For Docker Compose, desktop installers, reverse proxy, upgrades, and database options, see Deployment Guide.
Documentation
Docs site (VitePress) local preview:
npm run docs:devDocs site build:
npm run docs:buildGitHub Actions auto publish: each push to
mainruns.github/workflows/docs-pages.ymland deploys to GitHub Pages. First-time setup in repository settings:Settings -> Pages -> Build and deployment -> Source: GitHub Actions
| Category | Link | Description |
|---|---|---|
| Docs Home | docs/index.md | Publishable docs portal with nav/sidebar/search |
| Docs Maintenance | docs/README.md | Maintenance and contributor-oriented docs entry |
| Quick Start | docs/getting-started.md | Get running in 10 minutes |
| Deployment | docs/deployment.md | Docker Compose, reverse proxy, upgrades |
| Configuration | docs/configuration.md | All environment variables and routing params |
| Client Integration | docs/client-integration.md | Open WebUI / Cherry Studio / Cursor, etc. |
| Operations | docs/operations.md | Backup, logging, health checks |
| FAQ | docs/faq.md | Common errors and fixes |
| FAQ/Tutorial Contribution | docs/community/faq-tutorial-guidelines.md | Templates and workflow for community knowledge |
Environment Variables
Basic Configuration
| Variable | Description | Default |
|---|---|---|
AUTH_TOKEN |
Admin panel login token (must change) | change-me-admin-token |
PROXY_TOKEN |
Proxy API Bearer Token (must change) | change-me-proxy-sk-token |
PORT |
Service listening port | 4000 |
DATA_DIR |
Data directory for local runtime data | ./data |
TZ |
Timezone | Asia/Shanghai |
ACCOUNT_CREDENTIAL_SECRET |
Account credential encryption key | Defaults to AUTH_TOKEN |
Scheduled Tasks
| Variable | Description | Default |
|---|---|---|
CHECKIN_CRON |
Auto check-in cron expression | 0 8 * * * |
BALANCE_REFRESH_CRON |
Balance refresh cron expression | 0 * * * * |
Smart Routing, Notification & Security Configuration
See docs/configuration.md for full details on smart routing parameters, notification channels (Webhook / Bark / ServerChan / Telegram / SMTP), and security settings (IP allowlist).
Full configuration reference: docs/configuration.md
Proxy API Endpoints
Metapi exposes standard OpenAI / Claude compatible endpoints:
| Endpoint | Method | Description |
|---|---|---|
/v1/responses |
POST | OpenAI Responses |
/v1/chat/completions |
POST | OpenAI Chat Completions |
/v1/messages |
POST | Claude Messages |
/v1/completions |
POST | OpenAI Completions (Legacy) |
/v1/embeddings |
POST | Embeddings |
/v1/images/generations |
POST | Image Generation |
/v1/files |
POST / GET | OpenAI Files upload and list |
/v1/files/:fileId |
GET / DELETE | OpenAI Files retrieve metadata and delete |
/v1/files/:fileId/content |
GET | OpenAI Files raw content |
/v1/models |
GET | List all available models |
Include Authorization: Bearer <PROXY_TOKEN> in request headers.
The global PROXY_TOKEN works by default.
From System Settings -> Downstream API Key Strategy you can create multiple project-level downstream keys with individual configuration:
- Expiration time (expiresAt)
- Cost and request limits (MaxCost / MaxRequests)
- Model allowlist (SupportedModels, supports exact/glob/re:regex)
- Route allowlist (AllowedRouteIds)
- Site weight multipliers (SiteWeightMultipliers, control per-project upstream preference ratios)
Client Integration
Compatible with all OpenAI API-compatible clients:
| Setting | Value |
|---|---|
| Base URL | https://your-domain.com (clients usually append /v1 automatically) |
| API Key | Your configured PROXY_TOKEN |
| Model List | Auto-fetched from GET /v1/models |
Standard OpenAI /v1/files workflows are also supported for clients that use the official file API.
For detailed per-client setup, examples, and troubleshooting, see docs/client-integration.md.
Tech Stack
| Layer | Technology |
|---|---|
| Backend | Fastify — High-performance Node.js framework |
| Frontend | React 18 + Vite |
| Language | TypeScript — End-to-end type safety |
| Styling | Tailwind CSS v4 — Utility-first CSS framework |
| Database | SQLite / MySQL / PostgreSQL + Drizzle ORM |
| Charts | VChart (@visactor/react-vchart) |
| Scheduling | node-cron |
| Containerization | Docker (Debian slim) + Docker Compose |
| Testing | Vitest |
Local Development
# Install dependencies
npm install
# Run database migrations
npm run db:migrate
# Start dev environment (frontend + backend hot reload)
npm run dev
npm run build # Build frontend + backend
npm run build:web # Build frontend only (Vite)
npm run build:server # Build backend only (TypeScript)
npm run dist:desktop:mac:intel # Build mac Intel (x64) desktop installer
npm test # Run all tests
npm run test:watch # Watch mode
npm run db:generate # Generate Drizzle migration files
Related Projects
Compatible Upstream Platforms
| Project | Description |
|---|---|
| New API | Next-gen LLM gateway, one of Metapi's primary upstreams |
| One API | Classic OpenAI API aggregation |
| OneHub | Enhanced One API fork |
| DoneHub | Enhanced OneHub fork |
| Veloera | API gateway platform |
Referenced & Used Projects
| Project | Description |
|---|---|
| All API Hub | Browser extension — all-in-one relay account manager, Metapi's original inspiration |
| LLM Metadata | LLM model metadata library, used for model description reference |
| New API | Platform adapter reference implementation |
Data & Privacy
Metapi is fully self-hosted. All data (accounts, tokens, routes, logs) stays in your own deployment environment. No data is sent to any third party. Proxy requests are transmitted directly between your server and upstream sites only.
Contributing
All forms of contribution are welcome!
- Report bugs — Submit an Issue
- Feature suggestions — Start a Discussion
- Code contributions — Submit a Pull Request
- Contributing guide — CONTRIBUTING.md
- Code of conduct — CODE_OF_CONDUCT.md
Security
If you discover a security issue, please refer to SECURITY.md and report it privately.
License
Thanks
Thanks to everyone who has contributed code, bug reports, ideas, and real-world feedback to Metapi. A lot of the product polish in this project came directly from community usage and iteration.
Special thanks to all contributors:
Star History
If Metapi helps you, a Star is the best support!
Built with love by the AI community









