LiteLLM Enterprise Pricing: Quote and Migration Workbook

LiteLLM Enterprise pricing is usage-based and quote-led. No numeric Enterprise rate appears in the current first-party documentation, although LiteLLM offers a free 30-day trial and says pricing depends on deployment size. Procurement therefore needs a workbook that separates the license quote from model-provider charges, customer-operated infrastructure, support options and migration work. The published move from open source keeps the gateway image and configuration, while acceptance tests cover SSO, license behavior, shared budget counters and rollback.

TL;DR

• LiteLLM publishes usage-based, quote-led Enterprise pricing rather than a numeric rate card on the assigned documentation pages.
• Enterprise uses a license credential on the same gateway image and adds SSO, audit logs, delegated administration, security controls and support.
• Keep license, model usage, Postgres, Redis, observability, operations and optional SLA costs in separate workbook lines.
• Treat the open-source migration as a controlled production change even though the image, configuration and stored gateway data remain in place.

LiteLLM Enterprise pricing needs a normalized quote

The LiteLLM Enterprise overview says pricing is based on usage and directs buyers to request a quote tailored to their team. Pricing also depends on deployment size. The same page advertises a free 30-day trial, direct invoicing and procurement through AWS or Azure Marketplace, but none of those statements supplies a public dollar rate.

Start with the usage unit. Request bands for normal volume and peak volume, then record minimum commitments, overage treatment, the contract term, renewal basis, currency and marketplace fees. Pin every optional support charge, including any 24/7 SLA. State what happens when usage crosses the contracted band.

I would send back a proposal that labels one line "Enterprise platform" without a unit definition. A useful quote fits on a ledger where every grey cell has an owner and a source. The license line should reconcile to the usage forecast, with model tokens and customer-operated infrastructure shown as separate subtotals.

The LLM cost-management guide provides the adjacent workload forecast and chargeback model.

Enterprise adds licensed controls to the same gateway

LiteLLM describes Enterprise as a license applied to the same gateway image used for the open-source AI Gateway. The page lists SSO and SCIM, audit logs, organization and team administrators, secret managers, IP allowlists, per-team logging, multi-region support and support SLAs as Enterprise capabilities. It also lists a set of callback-based guardrail integrations that require the Enterprise license, while custom guardrails and Presidio remain in the open-source framework.

Translate those entitlements into quote lines and acceptance tests. Confirm the number of users, teams and environments covered. LiteLLM says SSO is free for up to five users and requires Enterprise beyond that point, so record how non-human identities, administrators and read-only reviewers count. Ask which support tier includes the dedicated Slack or Teams channel. Check whether the optional 24/7 SLA changes the price.

The product page says Enterprise is intended for teams with at least 100 users or 10 production AI use cases. Treat that language as vendor positioning, not a licensing threshold unless the quote makes it contractual. Preserve the quoted meter in your workbook rather than substituting those examples.

The AI gateway guide helps separate gateway routing and operational features from the security evidence required around each call.

Infrastructure is a customer cost

LiteLLM runs on customer infrastructure, according to its Enterprise page. The moving from OSS guide says keys, teams, models and spend data are in the customer's database. It requires Postgres for the Admin UI, virtual access credentials, MCP and agent registries, plus budget tracking. For multiple gateway instances or workers, Redis 7.0 or newer is recommended so they share counters, budgets and cache hits.

Create separate rows for compute, ingress, certificates, Postgres, Redis, backups, telemetry storage and secrets management. Add image scanning and signature verification, then include upgrades, on-call coverage and disaster recovery.

Provider spend stays on another line. Put model tokens there with the provider's meter, currency and account owner.

Run a realistic peak test before accepting the subtotal, measuring the gateway instances and data services together. Then stop Redis on one node. Shared state changes budget enforcement. Watch the counters on every instance because LiteLLM warns that without Redis each instance enforces limits independently, which can turn a nominal team budget into several independent ceilings.

The visual I want from this test is two budget counters side by side, one before the shared Redis path and one after. If they diverge under the same traffic, the infrastructure line is also a control line.

Open-source migration still needs a release record

The moving-from-OSS page says the image, config.yaml and version line remain unchanged when Enterprise is enabled. The operator adds LITELLM_LICENSE to each gateway instance, restarts it and checks that the API description shows Enterprise Edition. That is a low-change commercial transition.

It still alters authentication, administration and support assumptions.

Build a release record with the image digest, exact version, configuration hash, database backup and rollback owner. Test license expiry or an invalid credential in a non-production environment. Confirm the resulting gateway behavior and identify which Enterprise features become unavailable. Preserve the result instead of assuming an expired commercial entitlement leaves every production route unchanged.

LiteLLM's checklist advises SSO before exposing the Admin UI, disabling environment-credential login, rotating the master key and pinning an exact image or digest. It also warns against changing the salt key after models have been added. Put each step beside an evidence field, including an SSO login event, rejected environment login, rotated credential test and verified image signature.

Separate routing evidence from authorization evidence

LiteLLM can provide virtual credentials, budgets, routing, spend tracking, guardrails and administrative audit logs. Give each record type an explicit claim in the acceptance plan.

An admin audit event can establish that a team or credential changed, while a gateway trace can show provider selection, cost and response behavior. Neither automatically establishes that a natural person was permitted to submit a particular prompt under an identity-bound policy.

For one production-shaped request, preserve the application identity and represented user, then the credential or team and model destination. Include the prompt classification, evaluated policy and decision, followed by the provider response and cost record. Use stable correlation identifiers across the layers.

The AI policy enforcement guide covers the narrower request-authorization record. If LiteLLM performs retries or fallbacks after a permitted decision, carry the decision reference to the final destination.

A policy denial should never be retried as a transient provider error.

DeepInspect

DeepInspect evaluates authenticated user or agent HTTP requests sent to LLM endpoints through its stateless proxy. It can apply identity-bound policy to the prompt route and preserve a per-decision audit record, while LiteLLM retains its documented routing, provider abstraction, budgets and operational telemetry.

Local administration, provider billing, LiteLLM infrastructure and direct routes that bypass the proxy stay with their existing owners. Price those systems separately in the procurement workbook, then join their evidence with correlation identifiers.

Book a technical deep dive at deepinspect.ai.