← Open Source
mozilla-ai

otari

Open-source, OpenAI-compatible LLM gateway you run yourself. One endpoint for 40+ providers, with virtual keys, budgets, and usage tracking.

InfrastructureObservabilityGatewayPython
Open on GitHub
Momentum
+2stars in 24 hours+0.4%
524
Stars
65
Forks
40
Contributors
Created 2026-04-02 · Updated 2026-10-16 · #4299 today
Top developers

mozilla-ai/otari is ranked 4,299 with 524 stars.

Same-category comparison

mozilla-ai/otari is ranked 4,299 among these 8 peers; agentregistry-dev/agentregistry is ranked 4,301.

Same-category comparison
NameRankMetrics
askalf/dario4,253
Language:
JavaScript
Stars:
574
Forks:
72
Description:
Use your Claude and ChatGPT subscriptions in Cursor, Cline, Aider, Claude Code and the Agent SDK: one local endpoint, failover, pooling.
HEXUXIU/M365-Copilot2API4,257
Language:
Go
Stars:
570
Forks:
193
openai/tunnel-client4,262
Language:
Go
Stars:
569
Forks:
121
Description:
Customer-run client for Secure MCP Tunnel: connect private or localhost MCP servers to ChatGPT, Codex, the Responses API, and AgentKit without exposing them to the public internet.
ROCm/rocm-systems4,288
Language:
C++
Stars:
536
Forks:
451
Description:
super repo for rocm systems projects.
agentregistry-dev/agentregistry4,301
Language:
Go
Stars:
523
Forks:
97
Description:
Fast-track AI innovation with a centralized, trusted, curated registry.
ldomaradzki/xcsift4,319
Language:
Swift
Stars:
506
Forks:
23
Description:
A Swift command-line tool that parses xcodebuild output into token-efficient JSON for coding agents.
chroma-core/chroma4,335
Language:
Rust
Stars:
29,511
Forks:
2,567
Description:
Search infrastructure for AI.
karpathy/llama2.c4,354
Language:
C
Stars:
20,184
Forks:
2,649
Description:
Inference Llama 2 in one file of pure C.
Key parameters and specifications
Key parameters and specifications
ParameterValue
LanguagePython
CategoryInfrastructure
SubcategoryObservability, Gateway
KeywordsAgent-ready APIs, Client integration, DevOps, SaaS-lite
Stars524
Forks65
Contributors40
Created date2026-04-02
Updated date2026-10-16
Stars in 1 day2
Rank4,299
Previous rank3,394
Rank change-905
7-day stars rank19,295
Previous 7-day stars rank19,273
7-day stars rank change-22
Total stars rank18,655
Previous total stars rank18,680
Total stars rank change25
CountryUSA
README summary

**An OpenAI-compatible LLM gateway you own and run. ** Route one endpoint to 40+ providers, issue virtual keys, enforce budgets, and track usage. ai · Launch blog · Discord Otari sits between your applications and model providers. It authenticates requests, resolves provider credentials, enforces budgets before dispatch, and records usage afterwards. Run Otari standalone with your own database and provider keys, or connect a data plane to otari. Why Otari One OpenAI and Anthropic-compatible endpoint for many providers Provider credentials stay

behind the gateway Revocable API keys with user, workspace, and model scope Budget checks before spend and usage records after settlement Local routing policies for failover, weighting, and learned selection Optional code execution, web search, MCP, inference guardrails, and file understanding Quickstart Run an ephemeral standalone gateway with Docker: On the first empty database, Otari creates an API key and prints it once: Send a request with that key: OpenAI clients work by setting to . This container uses SQLite inside

the container and is deleted when it stops. Use the Compose setup below for persistent data. The command a developer runs next to a coding agent ( , ) installs on its own, without the server: See Agent Guardrails and Use with Claude Code. Run the full stack Compose runs Otari with PostgreSQL. Optional profiles add the code sandbox, web search, and guardrail services: The dashboard is served at . To store provider keys through the dashboard, set to a Fernet key generated by

. A one-click deployment template is available for Railway. | | Hosted | A multi-tenant control plane; inference runs on connected gateways. | | Hybrid | A data-plane gateway resolves credentials and reports usage to otari. | When is unset, selects hybrid mode; otherwise Otari defaults to standalone. A mode says what a process serves, not who runs it, so "hosted" is not the opposite of "self-hosted". API and dashboard The core completion routes are: Standalone also serves the broader OpenAI-compatible and management

APIs. The running server publishes Swagger UI at and OpenAPI at . The dashboard manages providers, models, routing, tools, keys, members, budgets, settings, activity, and usage. Its navigation adapts to the deployment mode and the signed-in person's authority. Development For local development without PostgreSQL, change to . Documentation Quickstart Deployment Configuration Models Routing Access control Built-in tools Agent Guardrails SDK and agent integrations Architecture License Apache 2.

Frequently asked questions

How many stars and forks are recorded?

mozilla-ai/otari has 524 stars and 65 forks.

What is the repository rank?

mozilla-ai/otari is ranked 4,299.

What language and category are recorded?

mozilla-ai/otari has 524 stars, uses Python and belongs to Infrastructure.

Which repository is closest in rank?

mozilla-ai/otari is compared with agentregistry-dev/agentregistry, ranked 4,301 with 523 stars.

README

An OpenAI-compatible LLM gateway you own and run.

Route one endpoint to 40+ providers, issue virtual keys, enforce budgets, and track usage.

Docs · otari.ai · Launch blog · Discord

Otari sits between your applications and model providers. It authenticates requests, resolves provider credentials, enforces budgets before dispatch, and records usage afterwards. Provider calls go through any-llm.

Run Otari standalone with your own database and provider keys, or connect a data plane to otari.ai.

Why Otari

  • One OpenAI and Anthropic-compatible endpoint for many providers
  • Provider credentials stay behind the gateway
  • Revocable API keys with user, workspace, and model scope
  • Budget checks before spend and usage records after settlement
  • Local routing policies for failover, weighting, and learned selection
  • Optional code execution, web search, MCP, inference guardrails, and file understanding

Quickstart

Run an ephemeral standalone gateway with Docker:

docker run --rm -p 8000:8000 \
  -e OTARI_MASTER_KEY=SET_A_MASTER_KEY \
  -e OPENAI_API_KEY=YOUR_OPENAI_KEY \
  -e OTARI_CONFIG_YAML='
default_pricing: true
providers:
  openai:
    api_key: ${OPENAI_API_KEY}
' \
  mzdotai/otari:latest \
  otari serve

On the first empty database, Otari creates an API key and prints it once:

No API keys found. Created bootstrap key for first run. Save this key now:
tk-...

Send a request with that key:

curl http://localhost:8000/api/v1/chat/completions \
  -H "Authorization: Bearer tk-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai:gpt-4o-mini",
    "messages": [{"role": "user", "content": "Say hello."}]
  }'

OpenAI clients work by setting base_url to http://localhost:8000/api/v1.

This container uses SQLite inside the container and is deleted when it stops. Use the Compose setup below for persistent data.

The command a developer runs next to a coding agent (otari hook, otari import claude-code) installs on its own, without the server:

brew install mozilla-ai/tap/otari

See Agent Guardrails and Use with Claude Code.

Run the full stack

git clone https://github.com/mozilla-ai/otari
cd otari
cp config.example.yml config.yml
# Set a master key, provider credentials, and pricing in config.yml.
# Provider copies of attached files need a pepper of their own. Compose reads .env.
grep -qs OTARI_PROVIDER_ACCOUNT_PEPPER .env || echo "OTARI_PROVIDER_ACCOUNT_PEPPER=$(openssl rand -base64 32)" >> .env
docker compose pull
docker compose up -d

Compose runs Otari with PostgreSQL. Optional profiles add the code sandbox, web search, and guardrail services:

docker compose --profile code-exec --profile web-search --profile guardrails up -d

The dashboard is served at http://localhost:8000/. To store provider keys through the dashboard, set OTARI_SECRET_KEY to a Fernet key generated by otari gen-secret-key.

A one-click deployment template is available for Railway.

Runtime modes

Mode Purpose
Standalone One process serves management and inference using local storage.
Hosted A multi-tenant control plane; inference runs on connected gateways.
Hybrid A data-plane gateway resolves credentials and reports usage to otari.ai.

When OTARI_MODE is unset, OTARI_AI_TOKEN selects hybrid mode; otherwise Otari defaults to standalone. A mode says what a process serves, not who runs it, so "hosted" is not the opposite of "self-hosted". See Runtime modes.

API and dashboard

The core completion routes are:

  • POST /api/v1/chat/completions
  • POST /api/v1/messages
  • POST /api/v1/responses

Standalone also serves the broader OpenAI-compatible and management APIs. The running server publishes Swagger UI at /api/v1/docs and OpenAPI at /api/v1/openapi.json. See API reference.

The dashboard manages providers, models, routing, tools, keys, members, budgets, settings, activity, and usage. Its navigation adapts to the deployment mode and the signed-in person's authority. See Admin dashboard.

Development

git clone https://github.com/mozilla-ai/otari
cd otari
uv sync --dev
cp config.example.yml config.yml
uv run otari serve --config config.yml

For local development without PostgreSQL, change database_url to sqlite+aiosqlite:///./otari.db.

Common checks:

make test
make lint
make typecheck

See CONTRIBUTING.md before opening a pull request.

Documentation

License

Apache 2.0. See LICENSE.

Nearby in the ranking
Similar items