AISIX AI Gateway
OfficialRuns the AISIX AI Gateway: a Rust-native, OpenAI-compatible gateway in front of many LLM providers, and also exposes an echo tool that returns your input text.
Proxies LLM traffic through one OpenAI-compatible API: chat/completions, completions, responses, embeddings, rerank, images, audio, videos, files, batches, fine-tuning, realtime, and model listing, plus Anthropic /v1/messages and /passthrough.
Routes and fails over across providers with strategies like round-robin, consistent hash, least-cost/latency/busy, priority tiers, retries, and cooldowns.
Supports ensemble models and semantic routing.
Enforces rate limits, concurrency caps, and token limits, locally or via Redis.
Applies guardrails for content policy, PII, and provider-based moderation.
Caches responses and supports automatic prompt caching.
Acts as an MCP gateway and an A2A agent gateway.
Authenticates callers via API keys or OIDC/JWT.
Exports observability data via Prometheus, OTLP, Datadog, and logs.
Uses declarative resources.yaml or etcd config, with SIGHUP reload and offline validation.
Exposes a single MCP tool: echo__echo(text) — echoes the provided text back.
Integrates Alibaba Cloud content-safety services as guardrails for input and output content policy enforcement.
Allows routing to Google Gemini models, including Vertex, through the same OpenAI-compatible API.
Provides access to OpenAI models through an OpenAI-compatible API, including chat completions, embeddings, and other model endpoints, with streaming and OpenAI Moderation guardrails.
AISIX AI Gateway
The open-source, Rust-native AI gateway for LLMs and AI agents
One OpenAI-compatible API in front of every model. Route, govern, secure, cache, and observe all your LLM and AI-agent traffic from a single control point — shipped as one static binary with low per-request overhead. Run it in your infrastructure for free, forever.
Built by the original creators of Apache APISIX.
Start free · Documentation · Quickstart · AISIX Cloud · Roadmap
AISIX AI Gateway is a Rust-native gateway that puts a single, OpenAI-compatible API in front of every LLM provider — OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure OpenAI, DeepSeek, and any OpenAI-compatible endpoint. It gives platform teams one place to route, govern, secure, and observe LLM traffic, with first-class SSE streaming and low gateway overhead.
It runs as a single static binary — low cold-start, lock-free config reads, and hot
configuration reloads with no restarts: declare resources in one resources.yaml and
reload on SIGHUP, or point the gateway at etcd for a multi-replica cluster. Run the
open-source gateway in your infrastructure, or connect it to
AISIX Cloud
for centralized management with team governance, budgets, audit, and a dashboard.
AISIX AI Gateway (this repo) is the open-source product. It runs without a control plane using declarative configuration or etcd. When connected to AISIX Cloud, the same gateway serves as the data plane. AISIX Cloud adds a commercial control plane, either hosted by API7 (Hybrid Cloud) or hosted by you in your infrastructure (On-Premises). In both options, the gateway runs in your environment and calls providers directly; live AI traffic does not pass through the control plane or API7. The proxy API is identical throughout. Talk to us about AISIX Cloud →
⚡ Quickstart
One container. No control plane, no database, no configuration store — the gateway reads
every dynamic resource from one declarative resources.yaml.
# config.yaml
resources_file: /etc/aisix/resources.yaml
proxy:
addr: "0.0.0.0:3000"
admin:
enabled: false # a declarative gateway needs no admin listener
observability:
metrics:
prometheus:
enabled: true
addr: "0.0.0.0:9090"# resources.yaml
_format_version: "1"
provider_keys:
- display_name: openai-main
provider: openai
api_key: ${OPENAI_API_KEY} # interpolated from the environment
models:
- display_name: my-model
provider: openai
model_name: gpt-4o-mini
provider_key: openai-main
api_keys:
- display_name: local-dev
key_env: CALLER_API_KEY # hashed at load; the plaintext is never stored
allowed_models: ["my-model"]export OPENAI_API_KEY="YOUR_PROVIDER_KEY"
export CALLER_API_KEY="YOUR_CALLER_KEY"
docker run -d --name aisix \
--platform linux/amd64 \
-v "$(pwd)/config.yaml:/etc/aisix/config.yaml:ro" \
-v "$(pwd)/resources.yaml:/etc/aisix/resources.yaml:ro" \
-e OPENAI_API_KEY -e CALLER_API_KEY \
-p 3000:3000 -p 127.0.0.1:9090:9090 \
ghcr.io/api7/aisix:latest # proxy → :3000, metrics + status → :9090
# ^ the metrics/status listener is unauthenticated;
# keep it on loopback or a private networkThen call the gateway exactly like OpenAI:
curl http://localhost:3000/v1/chat/completions \
-H "Authorization: Bearer $CALLER_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"my-model","messages":[{"role":"user","content":"hello"}]}'Edit resources.yaml and send SIGHUP (docker kill -s HUP aisix) to apply changes with
no restart — an invalid file is rejected whole and the last good configuration keeps
serving. Check a file before booting with aisix validate --resources resources.yaml.
Full walkthrough: the
Gateway Quickstart ·
every field: the resources file reference.
For a multi-replica cluster, point the gateway at etcd instead — resources_file and
etcd are mutually exclusive.
Related MCP server: Peta Core
✨ Why AISIX
One API, every model. Speak the OpenAI or Anthropic wire format in; the gateway translates to whichever provider each model points at. Point an OpenAI or Claude SDK at one
base_urland switch models without changing code.A real gateway, in Rust. Single static binary, low cold-start, lock-free config reads on the hot path, native streaming.
Open source, free forever. Apache-2.0 licensed and built to run in your infrastructure. Choose AISIX Cloud when you want centralized management through a control plane and dashboard.
Production controls built in. Routing & failover, rate limits, guardrails, caching, and observability ship in the box. (Budgets and spend caps are an AISIX Cloud feature — the gateway enforces the control plane's decisions.)
🧩 Features — available today
Covered by 183 end-to-end scenario files (496 cases) that run against real gateway processes.
OpenAI-compatible proxy (
:3000) —chat/completions,completions,responses,embeddings,rerank,images/{generations,edits},audio/{speech,transcriptions,translations},videos(submit → poll → fetch),files,batches,fine_tuning/jobs,realtime,GET /v1/models, plus a root-level/passthrough/:provider/*escape hatch. Native SSE streaming, tool/function calling, JSON mode, vision/multimodal input, and reasoning-content support.Anthropic Messages API —
POST /v1/messagesas a first-class route, working against any configured upstream: requests and responses (including streaming) are translated both ways when a model points at a non-Anthropic provider.Routing & failover — virtual/routing models with six strategies:
round_robin(smooth weighted round-robin),consistent_hash(session affinity keyed by header / cookie / API key / client IP),failover, plus metric-basedleast_cost,least_latency, andleast_busy. Per-targetprioritytiers (active/backup pools), retry budgets, cooldowns, tag-conditional targets, and per-attempt timeouts.Ensemble models — fan one request out to a panel of models concurrently, then have a judge model synthesize a single answer, with a minimum-successful-responses threshold.
Semantic routing — one virtual model that dispatches by the meaning of each request: it embeds the prompt, scores it against per-route example utterances, and routes to the best match (or a default). See the semantic routing docs.
Rate limiting & concurrency — RPS/RPM/RPH/RPD + TPM/TPD + concurrency caps, AND-combined across caller keys, models, and policy scopes (
api_key/model/team/member/team_member). Counters are per-process by default, or shared across replicas with the Redis backend.Guardrails — content-policy enforcement on input and output, in-process or through a provider: keyword/regex, built-in PII detection and redaction, Presidio, Lakera, OpenAI Moderation, AWS Bedrock Guardrails, Azure AI Content Safety (Prompt Shield + text moderation), and two Alibaba Cloud services. A block returns
422 content_filter; monitor mode records what would have happened without blocking.Caching — exact-match response cache with per-policy TTL and model/key scope matchers; memory and Redis backends; cost-saved telemetry on every hit. Separately, automatic prompt caching can be enabled per direct Anthropic model to inject cache breakpoints, so callers get provider-side prompt discounts without changing their requests.
MCP gateway — front registered upstream MCP servers at
/mcpwith gateway-held credentials, per-server tool namespaces, and per-caller access. It serves every Streamable HTTP revision from2025-03-26through stateless2026-07-28without downstream sessions. Upstreams useinitializeby default orserver/discoverwithprotocol_version: "2026-07-28". CI runs the official MCP suite's applicable tools-only protocol scenarios. Also exposes a REST API as MCP tools from its OpenAPI description.A2A agent gateway — front A2A (Agent-to-Agent) agents at
/a2a/:agent, serving each agent's card with URLs rewritten to the gateway, over JSON-RPC 2.0.Inbound authentication — caller API keys (SHA-256 hashed, model allowlists, expiry, rotation), or OIDC/JWT bearer tokens validated against registered providers (Entra ID, Okta, Google Workspace, or any OIDC issuer) with JWKS caching.
Observability — Prometheus
/metrics, structured per-request access logs, usage events, OTLP/GenAI span export (Langfuse, Honeycomb, Grafana Cloud, or any OTLP receiver), plus dedicated Datadog and Aliyun SLS log exporters and object-storage (S3/GCS/Azure Blob) telemetry.Declarative configuration — one
resources.yamlcarries all ten resource collections (provider keys, models, caller keys, guardrails, MCP servers, A2A agents, cache policies, observability exporters, rate-limit policies, OIDC providers), validated against the same JSON Schemas the gateway uses at runtime.aisix validatechecks a file offline;SIGHUPreloads it atomically.Operational endpoints —
/livezand/readyzon the proxy listener;/status/config,/status/ready,/status/models, and Prometheus/metricson a dedicated metrics listener (:9090). The admin listener (:3001) additionally serves a read-only resource surface, OpenAPI 3 with a Scalar UI, and a playground. Resources are managed declaratively — through theresources_file(reloaded on SIGHUP) or direct etcd writes — not through the admin listener; its former write endpoints were removed.
🔌 Supported providers
AISIX dispatches through five native adapter families — distinct wire-protocol bridges, not one generic relabel. Whatever the upstream protocol, the client-facing API stays OpenAI-shaped.
Adapter family | Reaches | Wire shape · auth |
| OpenAI + any OpenAI-compatible vendor — DeepSeek, Groq, Mistral, Together, Fireworks, Perplexity, vLLM, Ollama, or self-hosted OpenAI-compatible endpoints | OpenAI chat completions · Bearer |
| Anthropic Claude | Anthropic Messages · |
| AWS Bedrock — Anthropic, Meta Llama, Mistral, Cohere, Amazon Titan/Nova, AI21 | Bedrock Converse + |
| Google Vertex AI (Gemini) | Vertex |
| Azure OpenAI | Azure deployments · api-key / Entra ID |
Plus specialized handling for vendor quirks (e.g. DeepSeek reasoning content) and dedicated rerank / embeddings vendors (Cohere, Jina). Details in adapter protocol families.
☁️ Open source vs AISIX Cloud
Same gateway binary, same proxy API — in every form the gateway runs in your environment. AISIX Cloud adds a commercial control plane, either hosted by API7 (Hybrid Cloud) or hosted in your infrastructure (On-Premises).
Open-source gateway (this repo) | AISIX Cloud (Hybrid Cloud or On-Premises) | |
Price | Free · Apache-2.0 · forever | Commercial — talk to us |
Configuration | Declarative | Dashboard + Cloud Admin API, multi-environment |
Tenancy | Single instance / namespace | Org → Team → Member → Environment |
Provider keys | In the resources file as | Envelope-encrypted at rest, write-only, in-place rotation |
Inbound auth | Caller keys (SHA-256 hashed, model allowlists, expiry), or OIDC/JWT bearers | Same, plus masked reveal, key ownership, and PATs |
Budgets | — (rate and token limits only) | Per key / provider / env / org / team, hard-stop & alerts |
RBAC | Admin key = read-only resource surface | Org roles (owner / admin / member), invites |
Audit log | — | Full org-scoped audit with diff viewer |
Usage & cost | Export logs, metrics, and usage events yourself | Managed usage views, model pricing catalog, spend reporting |
Surface | Status endpoints, OpenAPI read surface, playground | Full dashboard + per-environment playground |
→ Want the AISIX Cloud control plane, governance, budgets, and dashboard? Talk to API7 about Hybrid Cloud or On-Premises, or book a demo.
🏗️ Architecture
A single Cargo workspace; the aisix-server crate builds one binary named aisix that
wires the crates together.
crates/
├── aisix-core Config, snapshot, resource model, resources.yaml source, errors
├── aisix-etcd Config provider + watch supervisor
├── aisix-gateway Hub & bridge, SSE parser, provider trait
├── aisix-proxy /v1/*, /mcp, /a2a handlers, routing, middleware
├── aisix-admin Read-only resource surface + playground + OpenAPI
├── aisix-provider-* openai · anthropic · azure-openai · bedrock · vertex
├── aisix-mcp MCP gateway — server registry, tool ACL, transports
├── aisix-a2a A2A agent gateway — agent cards, JSON-RPC bridge
├── aisix-ratelimit fixed-window + token accounting + concurrency (local | redis)
├── aisix-cache memory + redis backends
├── aisix-redis shared Redis connection for cache + rate limits
├── aisix-guardrails pre/post content-policy hooks
├── aisix-obs tracing, metrics, access log, exporters
└── aisix-server the `aisix` binary — bootstrap + CLI🗺️ Roadmap
Highlights on the roadmap; tracked live in issues:
Semantic (embedding-similarity) response caching
More observability sinks — Langsmith, Helicone, Slack alerts
Prompt templates managed as gateway resources
Llama-Guard as a guardrail provider
Shipped since this list was last written: the MCP gateway, the A2A agent gateway, OIDC/JWT inbound auth, Redis-backed distributed rate limiting, and the Lakera, Presidio, PII, and OpenAI Moderation guardrails — see Features above.
🛠️ Development
Prerequisites: the Rust toolchain pinned in rust-toolchain.toml. Docker is only needed
for the tests that exercise etcd, Redis, or provider emulators.
cargo check --workspace
cargo fmt --check
cargo clippy --workspace -- -D warnings
cargo test --workspace
# Coverage (matches the CI gate)
cargo llvm-cov --workspace --lcov --output-path lcov.info
# Run locally against a resources.yaml (no etcd needed). Copy the Quickstart's two files
# and change resources_file to the local path, e.g. resources_file: ./resources.yaml
cargo run -p aisix-server --bin aisix -- --config config.local.yaml
# Check a resources file without starting a listener
cargo run -p aisix-server --bin aisix -- validate --resources resources.yaml💬 Community
Discord — discord.gg/dUmRZ7Rvf
Issues & discussions — github.com/api7/aisix/issues
Contributing — CONTRIBUTING.md
Website — api7.ai/ai-gateway
If AISIX is useful to you, a ⭐ helps other engineers find it.
📄 License
Available Tools
1 toolecho__echoA
Echo the input text back.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It accurately describes the operation (echoing input) without any side effects or hidden behaviors. For a trivial tool, this minimal disclosure is sufficient, though it does not explicitly state return behavior or safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core purpose. Every word is necessary and there is no extraneous information, making it ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool of this low complexity—with one simple string parameter, no output schema, and no annotations—the description is fully complete. It states exactly what the tool does, and no additional details are needed for correct invocation or interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'text' with no description, and the schema coverage is 0%. The description references 'input text', which maps directly to the parameter, adding meaning by clarifying the intended input. Though it does not explicitly name the parameter, the connection is obvious, making the semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Echo the input text back' clearly states a specific verb (echo) and resource (input text), making the tool's function unambiguous. Since there are no sibling tools, differentiation is not required, but the purpose is fully conveyed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what the tool does—when you need to repeat input text—but provides no explicit guidance on when to use it versus alternatives (none exist) or any exclusions. This is an implied usage scenario rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
v0.1.0- First observed
echo__echo
TDQS
Only one tool exists, so there is no possibility of confusion between tools. The tool's purpose is clearly distinct by default.
The name 'echo__echo' follows a namespace-style pattern, but with only one tool there is no broader pattern to evaluate. The double underscore is unusual but not inconsistent within the set.
A single echo tool is extremely thin for a server named 'AI Gateway'. The tool count is far below what the domain implies, making the server feel more like a stub than a functional gateway.
The tool surface is severely incomplete for any plausible interpretation of an AI Gateway. It lacks any gateway-related operations such as routing, request handling, model access, or configuration.
Maintenance
Related MCP Connectors
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
471Self-hosted MCP gateway: turn any API, database or MCP server into AI connectors — no code.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCPGate aggregates multiple MCP servers into a single unified endpoint, enabling centralized tool management with granular filtering, automatic namespacing, and observability. Features a real-time web dashboard and optional PostgreSQL-backed audit trails for monitoring and controlling AI tool access across local and remote deployments.23Apache 2.0
- FlicenseNot gradedqualityAmaintenanceA production-ready MCP gateway and control plane that provides credential vault, policy engine, audit logging, and managed runtime for routing tool calls between AI agents and downstream MCP servers.58-
- AlicenseAqualityAmaintenanceA zero-dependency MCP gateway: host your own tools, forward and curate tools from other MCP servers, expose them leanly to cut agent token cost, and gate every call through your own policy hooks before it runs.42535MIT
- AlicenseNot gradedqualityAmaintenanceSelf-hosted MCP gateway that exposes a single MCP URL to AI agents and routes tools/resources to many upstream MCP servers behind it.3,958MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/api7/aisix'
If you have feedback or need assistance with the MCP directory API, please join our Discord server