# Omnia vs LiteLLM

> Omnia runs the agent behind the gateway: it tests each version, rolls it out and checks each tool call against the caller’s identity. LiteLLM routes the model call, and doesn’t see whether the agent works or what its tools are asked to do.

Category: Gateways and guardrails. Checked against BerriAI’s published material on 2026-10-22. Canonical page: https://www.altairalabs.ai/vs/litellm/

## LiteLLM routes the model call. Omnia runs the agent around it.

Omnia handles what a model gateway can’t see: whether the agent works, how a new version ships and what each tool call may do. LiteLLM routes the model call, with budgets and per-customer limits.

## When it matters: A support agent is about to get a new model behind the same gateway.

**On Omnia:** Swapping the model makes a new version. Simulated customers try it through the real tools before release. Once it passes, it gets part of the traffic and is rolled back if its metrics drop. (Omnia docs: https://promptarena.altairalabs.ai/arena/explanation/scenario-design/)

**On LiteLLM:** LiteLLM routes the call to the new model, with fallbacks if it fails. Testing and releasing the agent aren’t in scope. (source: https://docs.litellm.ai/docs/proxy/users)

## Testing the agent behind the gateway

Each version is tested as a whole agent, in multi-turn conversations with hostile and duplex voice callers, through the tools it’ll use in production. It ships when the suite passes. (Omnia docs: https://promptarena.altairalabs.ai/arena/explanation/scenario-design/)

LiteLLM: A gateway and an agent SDK that routes model calls. (source: https://github.com/BerriAI/litellm)

## The caller’s identity in the policy

The end user’s identity comes in from OIDC or your gateway and travels with the agent to every tool call. The policy rule reads it alongside the call’s arguments, and a call it can’t clear is refused. *(enterprise)* (Omnia docs: https://omnia.altairalabs.ai/how-to/security/configure-tool-policies/)

LiteLLM: Pre-MCP-call guardrails see the arguments; end-user identity drives MCP permissions and budgets. (source: https://docs.litellm.ai/docs/mcp_guardrail)

## Budgets without extra plumbing

Daily and monthly budgets per agent, provider or workspace come with the platform, each with an action on breach. (Omnia docs: https://www.altairalabs.ai/scale)

LiteLLM: Budgets block when exceeded and require a database. (source: https://docs.litellm.ai/docs/proxy/users)

## At a glance

| Topic | Omnia | Omnia docs | LiteLLM | LiteLLM docs | Source |
|---|---|---|---|---|---|
| Model providers | Seven native protocols and any OpenAI-compatible URL. | https://omnia.altairalabs.ai/reference/core/provider/ | 100+ providers. | documented | https://github.com/BerriAI/litellm |
| Self-hosted on Kubernetes | Helm. | https://omnia.altairalabs.ai/how-to/workspaces/manage-workspaces/ | Helm chart. | documented | https://github.com/BerriAI/litellm |
| Blocking budgets | Yes. | https://www.altairalabs.ai/scale | Yes. | documented | https://docs.litellm.ai/docs/proxy/users |
| Argument-level tool policy | Deterministic, with caller identity. *(enterprise)* | https://omnia.altairalabs.ai/how-to/security/configure-tool-policies/ | Guardrail hooks before MCP calls. | partly documented | https://docs.litellm.ai/docs/mcp_guardrail |
| Simulated users before release | Yes. | https://promptarena.altairalabs.ai/arena/explanation/scenario-design/ | Not documented. | not documented | https://github.com/BerriAI/litellm |
| Stepped rollout, auto rollback | Yes. | https://omnia.altairalabs.ai/tutorials/progressive-rollouts/ | Not in scope. | not documented | https://github.com/BerriAI/litellm |

## Questions

**Can I keep LiteLLM in front of the models?**

Yes. Point an Omnia provider at LiteLLM’s OpenAI-compatible endpoint, and Omnia’s testing, rollout and tool policy sit on top.