One API: A Complete Guide to the Open-Source API Gateway for Unified Management of 30+ LLMs

What Is One API? Understanding This Open-Source Project in One Sentence

One API is an open-source LLM API management and distribution system created by developer songquanpeng. With over 32,800 GitHub Stars, it's one of the most popular large model API gateway solutions available today.

Its core concept is straightforward: convert the APIs of dozens of large models on the market into a unified OpenAI-compatible format, allowing developers to call different vendors' model services through a single interface.

To understand the value of One API, you first need to understand how widespread the problem it solves actually is. Since 2023, the LLM API market has entered a highly fragmented phase: OpenAI, Anthropic, and Google each operate independently in the international market, while domestically (in China), over a dozen vendors including Baidu, Alibaba, ByteDance, Tencent, iFlytek, Zhipu, and DeepSeek^Ad compete head-to-head. Each vendor's API differs—sometimes significantly—in authentication methods, request body structures, error code definitions, billing units, and even streaming output protocols. For a development team that needs to integrate three to five model services simultaneously, maintaining multiple sets of adapter code, managing multiple API Keys, and reconciling multiple bills is a real and ongoing drain on engineering resources. At its core, One API lays a unified abstraction layer over this fragmented market—this "adapter pattern" is nothing new in software engineering, but its emergence is perfectly timed for the explosive growth of the LLM ecosystem.

One API Core Features in Detail

Unified API Adaptation: One Interface to Call 30+ LLMs

One API's most critical capability is protocol translation—converting different vendors' proprietary API formats into the OpenAI API standard. Currently supported model providers include:

• International vendors: OpenAI, Azure OpenAI, Anthropic Claude, Google Gemini
• Chinese vendors: DeepSeek, ByteDance Doubao, Zhipu ChatGLM, Baidu ERNIE Bot, iFlytek Spark, Alibaba Qwen, 360 AI Brain, Tencent Hunyuan

This means you don't need to write separate adapter code for each vendor. If the backend wants to switch from GPT-4o to DeepSeek, you only need to change a channel configuration—business code remains completely untouched.

Why Choose OpenAI Format as the Unified Standard?

The OpenAI API format became the de facto standard due to its first-mover ecosystem advantage established during 2022-2023. The Chat Completions interface uses a clean RESTful design, passing conversation context through a messages array while supporting streaming output (Server-Sent Events), Function Calling, and Structured Outputs.

From a technical evolution perspective, OpenAI's API design went through several key stages: the early GPT-3 era used a simple Completions interface (give a prompt, get continuation text); the Chat Completions interface introduced with GPT-3.5-Turbo in March 2023 brought role-based messages structure (system/user/assistant), which greatly simplified multi-turn conversation state management; subsequently added Function Calling (allowing models to output structured function call requests) and Structured Outputs (constraining output format via JSON Schema) further expanded the interface's expressiveness. Streaming output is implemented via the Server-Sent Events (SSE) protocol, where the server pushes generated results token by token through a persistent HTTP connection, allowing the client to begin rendering without waiting for the complete response—this is crucial for user experience since full model responses can take several seconds or even tens of seconds to generate.

Mainstream frameworks and tools like LangChain, LlamaIndex, Dify, and ChatGPT-Next-Web all target the OpenAI SDK as their primary integration target. By choosing OpenAI format as the unified standard, downstream ecosystems can integrate with zero modifications—this is the key reason One API quickly gained community recognition. You might not have noticed, but this "de facto standard" didn't form because OpenAI's protocol is technically flawless (for example, Anthropic's Messages API offers more flexible design for multimodal content blocks), but because the most extensive toolchain and developer habits have accumulated around the OpenAI format, and network effects have led other vendors to also provide OpenAI-compatible modes.

It's worth noting that the diffusion speed of the OpenAI-compatible format has exceeded many expectations. Local deployment tools like Ollama (local model runtime framework), vLLM (high-performance inference engine), and LM Studio have all adopted OpenAI-compatible APIs as their standard external interface. This means One API's adaptation scope isn't limited to cloud-based commercial APIs—theoretically, locally self-hosted open-source models (such as Llama, Qwen, Mistral) can also be brought under unified management, further expanding its boundaries as an "all-model gateway."

API Key Management and Secondary Distribution

One API provides a complete Key management system covering the entire process from procurement to distribution:

• Multi-channel management: Configure multiple vendors' API Keys as upstream channels, maintained centrally
• Load balancing: Automatically distribute requests among channels of the same type, avoiding single-point pressure
• Token distribution: Generate sub-tokens for team members or downstream users without exposing original Keys
• Quota control: Set usage limits for each token to keep costs under control
• Usage statistics: Record call volume and spending by token and channel for clear, transparent billing

Multi-Tenant Design for Token Distribution

One API's token distribution mechanism essentially implements a lightweight multi-tenancy architecture. Administrators hold each vendor's original API Keys (equivalent to master accounts) and generate sub-tokens with independent quotas and permissions through One API, distributing them to different users or teams.

This design borrows from IAM (Identity and Access Management) concepts in cloud computing: permission isolation ensures that one tenant's abnormal usage doesn't affect other tenants, while quota limits enable fine-grained cost control. In cloud computing, multi-tenant architecture isolation levels are typically divided into three tiers: shared database with shared schema (weakest isolation but highest resource utilization), shared database with independent schemas, and completely independent databases (strongest isolation but highest cost). One API adopts the first approach—all tenant data is stored in the same SQLite or MySQL database, with logical isolation through token IDs. Common permission models in IAM systems include RBAC (Role-Based Access Control, such as admin/regular user) and ABAC (Attribute-Based Access Control, which determines permissions based on dynamic conditions like time and IP). One API currently uses a simplified RBAC model, distinguishing between administrator and regular user role levels, achieving fine-grained control through token-level quotas and model access scopes. For most small-to-medium-scale use cases, this lightweight permission design is sufficiently practical.

From a security engineering perspective, the token distribution mechanism also addresses an often-overlooked "key leak blast radius" problem. If team members directly hold vendor original API Keys, once a member's key is leaked, attackers can consume the entire account quota without limits, and it's difficult to trace which member's key was compromised. Through One API's sub-token mechanism, each member holds an independent token with a quota cap. Even if a token is leaked, losses are strictly limited to that token's remaining quota. Administrators can immediately revoke the token without affecting other members, while precisely locating the source of abnormal calls through usage logs. This practice of the "Principle of Least Privilege" is a fundamental requirement of enterprise-level security management.

LLM API Billing and Cost Normalization

LLM API billing is typically based on Token usage, but billing granularity and pricing vary significantly across vendors. For example, GPT-4o's input Token price is approximately $2.5/million Tokens, while DeepSeek-V3 is only ¥1/million Tokens (even lower with cache hits).

Here it's necessary to explain the concept of Tokens. A Token is the basic unit for LLM text processing and doesn't equate to a single character or word. Mainstream models generally use BPE (Byte Pair Encoding) tokenization algorithms to split text into subword segments. In English, one Token corresponds to approximately 4 characters or 0.75 words, while Chinese characters are typically encoded as 1-2 Tokens due to the specifics of Unicode encoding (depending on the model's vocabulary). This means Chinese text of equivalent semantic length often consumes more Tokens than English, resulting in correspondingly higher actual usage costs. Additionally, most vendors use differential pricing for input and output Tokens—output Tokens are typically 2-4 times the price of input Tokens, since the computational overhead of generation far exceeds that of understanding. The recently emerging Prompt Caching technology allows vendors to offer discounted pricing for repeated system prompts or context prefixes, with DeepSeek's cache hit pricing as low as one-tenth of regular pricing.

One API's usage statistics function normalizes different vendors' billing units through a "multiplier" mechanism—setting a price multiplier relative to a baseline model for each model, accurately reflecting actual cost consumption within a unified quota system. For enterprises that need strict AI budget control, this feature is quite practical. It's worth noting that as LLM capabilities rapidly iterate, vendors' pricing strategies are continuously adjusting (the overall trend is rapidly declining prices), and One API's multiplier configuration needs regular maintenance to keep cost accounting accurate—this is also one of the important directions for ongoing community contributions.

Minimalist Deployment: One Docker Command Gets It Done

One API achieves out-of-the-box deployment experience:

• Single executable: No external dependencies required, download and run directly
• Docker deployment: Official images provided, launch with a single docker run command
• Low resource usage: Lightweight architecture, runs smoothly even on a 1-core 1GB server

The reason Docker containerized deployment can compress complex environment configuration into a single command relies on the container image's layered storage mechanism (Union File System) and the widespread adoption of the OCI (Open Container Initiative) standard. Images package the application and all its dependencies into an immutable layered file system, ensuring that the environment where "it works on my machine" can be precisely reproduced on any host that supports Docker. For applications like One API written in Go, Docker images can be built on minimal scratch or alpine base images, resulting in final image sizes of just tens of MB, with extremely fast pull and startup speeds, further lowering the barrier to self-hosting.

One API Typical Use Cases

Scenario 1: Enterprise Internal AI Unified Gateway

Enterprises that have simultaneously procured OpenAI, DeepSeek, and Qwen