Our take
Activeregular commits and releases- Activity
- 82
- Community
- 77
- Issues
- 74
- Pull requests
- 83
+65 stars in the last 10 days
- Merges more pull requests than 94% of the projects we track
- Releases more often than 79% of the projects we track
Otari is a capable, actively maintained gateway for teams that want control over multi-provider LLM access, but its young age and Python 3.13+ requirement are worth weighing before standardizing on it.
Good fit if
- You need a self-hosted endpoint for multiple LLM providers with centralized credentials, budgets, and usage tracking.
- Your team can run a Python 3.13+ service, and optionally Docker Compose with PostgreSQL for a persistent deployment.
- You want a project with regular recent releases and contributions from a broad contributor base.
Look elsewhere if
- Your runtime environment cannot use Python 3.13 or you do not want to operate a gateway service.
- You need a solution that does not introduce an intermediary between applications and model providers.
- Your requirements depend on features not described in the project documentation; confirm coverage before adopting it.
All health signals
| Last commit | 2026-10-08 (today) |
|---|---|
| Commits, last 90 days | 100+ |
| Releases, last 12 months | 26 (latest v0.18.0, 2026-10-08) |
| Contributors | 39 (top contributor: 19% of commits) |
| Issues closed, last 90 days | 11+ (typically closed in 1 day) |
| Pull requests merged, last 90 days | 91 (typically merged in 0 days) |
| Project age | 6 months |
Checked on 2026-10-09 with the GitHub API.
Overview
Otari sits between applications and LLM providers, giving teams one OpenAI- and Anthropic-compatible endpoint for routing requests across providers. It keeps provider credentials behind the gateway and provides a place to manage access and track usage.
It is aimed at teams that want to operate their own gateway or connect a gateway to Otari's hosted control plane. Its current development is active, with regular commits and releases and contributions spread across many people, though the project is still relatively young.
Key Features
- Routes requests to more than 40 providers through a shared endpoint.
- Supports OpenAI-compatible chat completions and Anthropic-compatible messages routes, plus a Responses route.
- Issues revocable virtual API keys scoped to users, workspaces, and models.
- Checks budgets before dispatch and records usage after requests settle.
- Offers routing policies for failover, weighted selection, and learned selection.
- Includes a dashboard for providers, models, routing, keys, members, budgets, and usage.
- Can add optional code execution, web search, MCP, inference guardrails, and file understanding.
Use Cases
- A platform team can give internal applications one endpoint while keeping provider credentials on the gateway.
- An organization can issue scoped keys and budgets to teams or applications and track their model usage.
- Developers can configure routing and failover across providers without changing each client integration.
- Teams evaluating models can use the dashboard's Playground to compare models before selecting one for an application.
- Users of coding agents can install Otari's hook or Claude Code integration to apply agent guardrails.
What you need
Detected in the repository
- Python >=3.13 (from pyproject.toml)
- A Dockerfile, so it can run in a container; a Compose file sets up the related services
- A test suite and automated checks on GitHub Actions
License in plain words
Apache-2.0permissive
- Commercial use: yes
- Modify and redistribute: yes
- You must keep: the license, the NOTICE file and a note of your changes
- Share your changes: no
- Includes an explicit patent grant from the contributors:
A summary, not legal advice: the LICENSE file is what applies.
Getting Started
For an ephemeral Docker-based quickstart:
docker run --rm -p 8000:8000 -e OTARI_MASTER_KEY=SET_A_MASTER_KEY -e OPENAI_API_KEY=YOUR_OPENAI_KEY mzdotai/otari:latest otari serve
This quickstart also requires provider configuration; see the README for the complete command, persistent Compose setup, and documentation.
Alternatives
- freellmapi: FreeLLMAPI emphasizes combining free provider accounts and quota-based retries for personal use, while Otari focuses on team keys, budgets, and usage tracking.
- a3m-router: A3M Router adds heuristic or ML-based routing, semantic caching, and parallel ensembles; Otari emphasizes virtual keys, budgets, and team usage controls.
- router: weave-os/router accepts Anthropic, OpenAI, and Gemini request formats and targets agent and coding-tool users, while Otari centers on an OpenAI-compatible endpoint with team spend controls.
| Project | Language | License | Stars | Status |
|---|---|---|---|---|
| otari | Python | Apache-2.0 | 513 | Active |
| freellmapi | TypeScript | MIT | 30.3k | New |
| a3m-router | TypeScript | MIT | 16 | New |
| router | Go | Apache-2.0 | 5.6k | New |
Considerations
Otari is a young project, despite its strong recent activity: it has a steady stream of commits and releases, contributions from dozens of contributors without one person dominating, and quick median issue and pull-request handling. The repository also has a substantial open issue list, so teams should review current issues and confirm that their deployment needs are covered.
The runtime requirement is Python 3.13 or newer. The Docker quickstart uses ephemeral SQLite storage, while the documented full-stack Compose deployment uses PostgreSQL. Optional code execution and other supporting services add deployment components when enabled. Otari is licensed under Apache-2.0; review that license for your distribution and usage needs.
Found this useful?
Share it with someone who would like otari.