Introduction

OneGateway is an AI gateway and token management platform built for enterprises. It gives your employees, business applications, and AI agents a single endpoint for models from many providers, while your organization keeps central control over access, costs, and security.

When multiple teams start using different AI models, you need answers to several questions at once: Who can use which models? Where is the money going? How do you keep services running when a provider goes down? How is sensitive content handled? OneGateway brings the answers together in one gateway and one console, cutting the integration, development, and maintenance work that each application would otherwise repeat.

Core Capabilities

Capability	What it does for you
Unified Model Access	Reach models from many providers through one endpoint, without integrating each one separately
High-Availability Routing and Failover	Serve one model through several providers, with backup retries governed by the configured retry policy
API Keys and Access Control	Keep provider keys in one place and grant access per person and per application
Quotas and Billing	Set spending limits that reset each period, and bill by tokens or by request
Usage Analytics and Request Logs	Break down cost and usage by department, member, and model, and trace any individual request

Unified Model Access

Connect to OpenAI, Anthropic, DeepSeek, MiniMax, Moonshot, and other providers through a single endpoint, along with your own self-hosted models if they use a compatible API. Applications keep their existing request format, whether OpenAI, Anthropic, or another supported API format. You only need to set OneGateway's API URL, API key, and a model ID.

• Minimal migration effort: Existing applications only need a new API URL and key. The core request logic usually stays as it is.
• Provider differences handled for you: OneGateway normalizes the differences between providers' APIs, so request formats, error codes, and streaming responses stay consistent for your applications.
• Model access set by administrators: Administrators configure provider connections, available models, and pricing in one place. Members see the models they're approved to use in Available Models, where they can compare context windows, pricing, and recent status.

High-Availability Routing and Failover

A single model can be served by several providers. OneGateway chooses a provider by priority and, among providers with the same priority, splits requests by weight. If the primary provider fails, OneGateway can retry with a backup provider according to your retry policy, reducing your dependence on any one provider.

• Priority and weight: Priority sets the primary and backup order. Weight sets how traffic is split among providers with the same priority, so you can adjust each provider's share.
• Retry on failure: Choose which status codes trigger a retry and how many retries to allow. Providers that keep failing can be taken out of rotation automatically and brought back once they recover.
• Combined capacity: Serving a model through several providers reduces the impact of any one provider's rate limits and increases your total available capacity.
• Invisible to your applications: Applications keep using the same model ID and never manage individual providers' URLs or keys. Administrators can see which providers serve each model, their response times, and the primary and backup setup in the model routing view.

The above chooses among providers for the same model. To choose among different models — tiering by complexity, rolling out a replacement model, or switching models when one is unavailable — use the Intelligent Routing plugin.

API Keys and Access Control

Administrators store provider API keys centrally. Members and applications use API keys issued by OneGateway and never see the original provider keys.

• Purpose-specific keys: Give each API key its own quota, expiry date, allowed models, and IP restrictions, and enable, disable, or delete it at any time. This makes it easy to issue a separate key for each application or use case. If you suspect a key has leaked, disable it immediately and confirm that requests using it are rejected.
• Layered access control: Roles determine which menus a person can see and which actions they can perform. Restrictions on an individual API key further narrow the models, quota, validity, and source IPs it can use.
• Data isolation by organization: Business data is isolated per organization. Within an organization, departments record who belongs where and are used for cost analysis.
• Self-service or admin-managed: Members can manage their own keys and view their own usage. Administrators can create keys on members' behalf and adjust restrictions centrally. See Managing Users and Managing API Keys.

Quotas and Billing

• Recurring quotas: Give members spending limits that reset automatically each period, choosing from the reset periods available in your console. Select members by department to assign quotas in bulk.
• Usage alerts: When enabled, members are notified at 80% quota usage, helping them plan before their quota runs out.
• Layered limits: Set a separate quota on an API key to cap what a single application can spend. Where redemption codes are enabled, members can also add credit to their balance by redeeming a code.
• Two billing methods: Bill each model by token usage or per request. Set separate prices for input, output, cache reads, and cache creation; the pricing ratio from group pricing is applied when charges are calculated.

Together, these controls let you reconcile AI spending, plan quotas ahead, and avoid unplanned costs. See Quotas & Redemption for the detailed rules.

Usage Analytics and Request Logs

• Trends and breakdowns: The Dashboard and Cost & Usage pages show request volume, successes and errors, token usage, and spending over time, broken down by department, member, model, or provider.
• Trace individual requests: Request Logs record which model and provider actually handled each request, along with latency, time to first token, token usage, and billing details, so you can pinpoint problems quickly.
• Audit log for configuration changes: Configuration changes are recorded separately in an audit log that shows who changed what, and when.
• Role-based visibility: Members see their own data. Administrators see the whole organization in Dashboard & Analytics.

Plugins

Plugins add model selection, response reuse, and content checks at the gateway. Administrators turn them on and configure them to suit each business need.

• Intelligent Routing: Decides which model a request uses before it is sent upstream. Callers send one virtual model name (such as og-auto), and the gateway picks a simple, medium, or complex tier model by request complexity; it can also roll out a replacement model by percentage, or switch to backup models automatically when the primary model fails. Billing follows the model actually used, and callers do not need to change their APIs.
• Semantic Cache: Reuses a previous answer when a new request is identical or close enough in meaning to meet your matching criteria, so the model doesn't have to generate it again. For example, "I'm not happy with this product. How do I get a refund?" and "I bought something and want a refund. What do I need to do?" may be served the same answer. On a cache hit, the upstream model isn't called at all. Semantic Cache works best where answers rarely change, such as FAQs and product inquiries. Actual savings depend on your hit rate, how long answers stay cached, and the overhead of the similarity search itself.
• Guardrails: Checks text at two points—before a request reaches the model and before the response is returned—and blocks or redacts content according to your rules. Use Guardrails to detect sensitive information, catch prompt injection, and moderate content. Rule matches are logged, helping your organization enforce content-safety policies consistently.

All three plugins support streaming and non-streaming requests on supported APIs. See Intelligent Routing, Semantic Cache, and Guardrails for supported scope and setup.

Deployment Options

OneGateway supports two deployment modes: SaaS and hybrid. Choose based on your network setup, where your models are hosted, and your data-handling requirements.

Live requests are handled by Token Gate (the data plane). It converts between API formats, routes requests, calculates and deducts charges, and runs plugins such as Intelligent Routing, Semantic Cache, and Guardrails.

• SaaS mode: Use OneGateway's cloud service. There's nothing to deploy—sign up and start integrating.
• Hybrid mode: Deploy a dedicated Token Gate inside your corporate network. This suits teams that call self-hosted models on their internal network, or that need API traffic to stay within the corporate network. When you call an internal model, the request goes through Token Gate directly to that model. If the supporting services also run inside your network, request and response content can stay there, and only management data, such as configuration, quotas, and usage, syncs with the cloud console. If you enable external embedding services, complexity classification models, moderation models, or verdict services, the relevant text is still sent to them; see the FAQ.

Getting Started

• Members and developers: Follow the Quickstart to get an API key and make your first request.
• Administrators: To connect model providers, start with Providers & Models.

To try models right away, start a conversation in the Playground.

Questions about integration, permissions, quotas, caching, or guardrails? See the FAQ.