Otari

Otari is an OpenAI-compatible LLM gateway you run yourself. Put one endpoint in front of 40+ providers, then manage API keys, enforce budgets, and track usage in one place. It's the proxy server at the heart of otari.ai, open source and yours to deploy.

Your applications talk to Otari instead of directly to providers. Otari authenticates each request, enforces budgets before a call runs, resolves the right provider credential, and logs every request. Provider keys stay in one place, and usage is tracked across every model and app.

Two ways to run it

• Standalone: Otari manages everything locally: its own database, your provider credentials, keys, budgets, and usage. Nothing leaves your environment. This is the default and the place to start.
• Connected to otari.ai: Otari delegates provider routing, authentication, and usage tracking to the platform, adding multi-provider fallback. Enabled by setting one environment variable.

See Modes for the full comparison.

New here?

Start with the Quickstart. It gets Otari running locally and walks you through your first request in about five minutes.

Browse the docs

The docs are grouped by what you are trying to do.

Start here

• Quickstart: get running and make your first request.
• Modes: standalone vs hybrid, and what changes between them.

For operators

Running and managing a gateway.

• Deployment: Docker, Render, Railway, hybrid mode, and optional services.
• Configuration: the full config file and environment variable reference.
• Admin dashboard: the operator dashboard, covering the two-key model, a first-run walkthrough, and a page-by-page reference.
• Access control: users, API keys, and budgets, with the management endpoints that drive them.
• Supported models: providers, model format, aliases, and capabilities.
• Routing policies: failover, budget-based tier-down, a weighted split that load balances across providers, a learned router that sends easy prompts to cheaper models, and enforced guardrails, all behind one model name.
• OpenAI provider guide: configure OpenAI and route your first request through Otari.

For integrators

Calling the gateway from your own code.

• API reference: every endpoint, with auth and availability per mode.
• Built-in tools: sandboxed code execution and web search Otari runs itself.
• MCP: connect MCP servers to chat, messages, and responses requests.
• Files: file uploads and document understanding for local models.
• Guardrails: request-level checks like prompt-injection detection.
• Use with Claude Code: point the Claude Code CLI at Otari.
• Use with Codex: route the Codex CLI through Otari over the Responses API, or import its usage without routing.
• Use with opencode: point the opencode CLI at Otari.
• Use with a ChatGPT subscription: route Otari at ChatGPT Plus/Pro models through a local Codex-OAuth proxy.
• Importing external usage: bring subscription-backed usage (Claude Code, Codex, any OTLP app) into your analytics.
• SDK compatibility: how the language SDKs are released and which SDK version works with which Otari version.

For platform builders

• Hybrid-mode protocol: the Otari/platform wire contract, for building a platform that Otari connects to.
• Code-execution protocol: the Otari/sandbox contract, for building a code-execution backend that Otari dispatches to. Its machine-readable form is public/code-execution-openapi.yaml.

For contributors

• Architecture: the two-plane model and the extension seam (ports, adapters, and capability lines) that mark what Otari's core ships versus what an overlay can add.