What LiteLLM cost of ownership includes and when teams work it out
The cost of a self-hosted LiteLLM gateway is mostly people and infrastructure around an MIT-licensed core. The proxy and SDK code sit under the MIT license, and only content under the enterprise/ directory uses the separate enterprise license, so a license fee applies only when your team needs specific governance features. Teams usually open this question for one of three reasons: a budget request that needs a line-item total, a security review that asks which controls are included, or a move away from a managed or commercial gateway that changes who pays for what. Most teams build the cost model in-house, using their own platform, finance and security staff, and then ask an outside reviewer to test the assumptions before the decision goes to sign-off.
Split the model into one-time and recurring costs. One-time work covers architecture, provisioning PostgreSQL and Redis, Kubernetes manifests, secure handling of LITELLM_MASTER_KEY, connecting providers and private models, and the first set of teams and virtual keys. Recurring work covers upgrades within the four most recent supported minor versions, database migrations between versions, testing routing and budgets before each rollout, on-call coverage and key rotation. Infrastructure is the most measurable line. LiteLLM's production guide names PostgreSQL as the primary database, requires Redis 7.0 or newer once more than one proxy instance runs, and suggests 1 vCPU and 4 GiB memory per worker. It also recommends one Uvicorn worker per pod with horizontal scaling, so cost rises with pod count. Size pods from measured traffic and confirm the numbers in a load test.
The edition decision turns on governance features, not on gateway traffic. Virtual keys, per-team budgets and TPM and RPM limits run on the open-source core with PostgreSQL. SSO in the admin UI is free for up to five users from v1.76.0, and an Enterprise license is needed beyond that. Enterprise adds SSO and SCIM beyond the free limit, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations for AWS, Azure, Google, HashiCorp Vault and CyberArk, and team-level guardrails and logging. List the controls your security review requires, then mark each one as covered by the core, covered by Enterprise, or handled by your own controls. Confirm the license terms in the enterprise/LICENSE file and in writing with LiteLLM, because the license scope determines what you can deploy.
A partner is worth considering when the team lacks Kubernetes, database or identity skills for the first rollout, when the security review sets a deadline that internal staff cannot meet, or when several business units need separate environments. LiteLLM's enterprise documentation describes a dedicated support channel with its engineering team and optional 24/7 SLAs, including a 1 hour response for critical issues and 72 hours for security patches. Ask whether your internal support needs match those windows and what LiteLLM charges for them. DeployOpen plans and implements self-hosted platforms inside your own infrastructure, but it does not publish prices or estimate LiteLLM licensing. A quote follows a written scope that lists providers, environments, teams, identity and support requirements, so request that scope in writing before you compare numbers.
What a cost of ownership study covers and what you receive
A cost of ownership study turns the open-source versus Enterprise question into numbers and decisions your finance, security and platform leads can review. Each card below is one part of the study or one deliverable, so you can see what is measured, what is handed over, and what stays with the implementation work.
Edition mapping against governance needs
Each governance requirement you hold, such as SSO for the admin UI, SCIM provisioning, JWT authentication, audit logs, organization and team RBAC, IP allowlisting or secret manager integration, is mapped to the MIT open-source code or to LiteLLM Enterprise. The mapping also notes the free SSO limit of five users from v1.76.0, so you can see where licensing begins. Confirm each mapped feature against the current license terms and enterprise documentation before you rely on it.
Proxy pod sizing
The study estimates how many proxy pods your traffic profile needs, using LiteLLM's guidance of one Uvicorn worker per pod on Kubernetes and horizontal scaling. Inputs include peak request rates, average payload size, streaming share and the number of providers in use. The output is a pod count range with the CPU and memory assumption behind it, which the production guide suggests starting at 1 vCPU and 4 GiB per worker.
PostgreSQL and Redis sizing
PostgreSQL holds virtual keys, budgets and spend records, so the study sizes it by key count, log retention and spend-update frequency. Redis becomes required once more than one proxy instance runs, for shared rate limits, router state and cache, and the study requires Redis 7.0 or newer. Ask your database and cache teams which managed or self-run service they will support, because that choice drives the recurring cost.
Staffing model
The study lists the internal roles needed to run the gateway after go-live: platform engineering for Kubernetes and databases, security for key and secret handling, and application owners for model access requests. It estimates the share of each role that recurs, with the basis for each figure stated. Where a role does not yet exist in your organization, the study names it so the cost is visible rather than hidden in another team's budget.
Support model options
The study compares community support, a retainer with DeployOpen for ongoing operations, and LiteLLM Enterprise support, which includes a dedicated engineering channel and optional 24/7 SLAs with a 1 hour response for critical issues and 72 hours for security patches. For each option it records what is covered, who responds, and what your internal team still owns. Confirm the current support terms with LiteLLM before you sign.
One-time versus recurring cost split
Every cost line is tagged as one-time (design, initial configuration, integration with identity and secret managers, and cutover) or recurring (licenses, infrastructure, staff time, support and upgrades). The split shows how the total changes over a multi-year horizon and which lines move with traffic. Use it to test budget assumptions against the cost of the in-house alternative.
Cost model and assumptions register
The cost model is a spreadsheet with every input, formula and scenario, so finance can change a pod count, a support tier or a staffing percentage and see the result. The assumptions register lists each assumption with its owner, its source and the date it was last checked. Keeping the two together lets your team re-run the study when LiteLLM publishes new releases or your traffic changes.
Edition decision record and vendor confirmation list
The edition decision record states which edition you chose, why, which features it depends on and what would trigger a review. The list of items to confirm with the vendor collects the questions the study could not settle from public documentation, such as license coverage for specific enterprise features and support response terms. Together they give your procurement and security reviewers a single document to approve.
Exclusions and the implementation boundary
The study does not include the implementation itself: installing the proxy, connecting providers, configuring keys and teams, or moving applications onto the gateway. Those costs and phases are covered in the implementation plan topic. The study uses the implementation estimate only as an input, so keep it separate in your business case to avoid counting the same work twice.
What drives the cost of a LiteLLM deployment up or down
This table compares the main drivers of LiteLLM cost and effort, from users and identity providers to providers, traffic, environments, compliance evidence and support. Read each row for why it changes spend and which choice keeps it contained. The main takeaway is that the edition decision usually turns on SSO user count, audit and secret manager needs and support tier, while infrastructure grows with traffic and proxy instance count.
| Driver | Why it moves cost | How to keep it down |
|---|---|---|
| Users and teams needing keys | Virtual keys, budgets and limits need a PostgreSQL database, and admin effort grows with each team and key issued. | Issue keys per team or application, and use budgets and model restrictions to contain sprawl. |
| Identity providers and SSO users | From v1.76.0, SSO is free for up to 5 users. Beyond that, an Enterprise license is needed. | Count admin UI users before rollout, confirm the figure with the vendor, and keep the admin group small. |
| Providers and private models | Each provider adds credentials, model aliases, routing settings and test effort, even though connecting them has no license cost. | Connect only approved providers, start with a short model list and add more after testing. |
| Traffic and TPM or RPM limits | Higher throughput needs more proxy workers. The suggested starting point is 1 vCPU and 4 GiB memory per worker. | Size from measured load, run one Uvicorn worker per pod and scale out with more pods. |
| Number of proxy instances | Once more than one instance runs, Redis 7.0 or newer is required for shared rate limits, router state and cache. | Run a single instance until availability needs justify a second, and confirm the Redis version early. |
| Number of environments | Each environment needs its own database, keys and configuration, and Redis when several instances run. | Keep non-production environments small and deploy all of them from the same templates. |
| Compliance evidence needs | Audit logs, IP allowlisting and secret manager integrations are Enterprise features, and evidence collection takes ongoing effort. | Confirm which controls the assessor expects before choosing the edition, and prepare evidence without claiming certification. |
| Required support response times | Optional 24/7 SLAs in Enterprise offer a 1 hour response for critical issues and 72 hours for security patches. This is recurring. | Request the response tier you need in writing and choose business-hours coverage where the risk allows. |
Which LiteLLM governance features need an Enterprise license
The first thing to know is that LiteLLM is dual licensed. Content under the enterprise/ directory of the BerriAI/litellm repository uses the license in enterprise/LICENSE, and everything else in the repository is under the MIT license, according to the repository's LICENSE file. For a cost model, this means the open-source proxy can be deployed and used without an Enterprise license, but any feature whose code lives under enterprise/ carries its own terms. Before you budget, have your legal or procurement team read enterprise/LICENSE directly and compare its scope with the features listed below, rather than relying on a summary.
The governance features that sit beyond the open-source core are the ones your security and identity teams will ask for first. Enterprise adds SSO and SCIM beyond the free limit, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, and IP allowlisting. It also adds integrations with secret managers, including AWS, Azure, Google, HashiCorp Vault and CyberArk, and team-level guardrails and logging. On SSO specifically, the admin UI supports Google, Microsoft Entra ID, Okta and generic OIDC, and it is free for up to 5 users from v1.76.0. Beyond five users, you need an Enterprise license, so the seat count of your admin population should be fixed in the cost model.
Entitlements change between releases, so treat any feature list as a snapshot. Ask the vendor in writing which features your chosen release includes, and request the specific version or build number that your deployment will run. Check each item against enterprise/LICENSE and the current LiteLLM Enterprise documentation, and record the answers in your evaluation file. Pay particular attention to team-level guardrails, logging and JWT authentication, because the names of these capabilities can be used for both open-source and Enterprise functionality in different versions.
Map each governance requirement to a named control before you decide whether a license is needed. For example, if your policy requires admin sign-in through your corporate identity provider with SCIM deprovisioning, you need Enterprise for SCIM regardless of user count. If your policy requires keys to be retrieved from a central vault, confirm that your vault is on the supported list and that the integration works with your chosen release. If audit logging is a regulator-facing requirement, ask the vendor to describe exactly which events are recorded, where they are stored and how long they are retained, and whether that depends on the license tier.
Finally, agree on the commercial terms in writing before you rely on any feature in production. Ask what the license covers in terms of deployment count, environments and users, whether it renews annually, and what happens to features if the license lapses. Also ask about support, including whether a dedicated channel and any response commitments are included in your edition. Document these answers alongside the open-source fallback plan, so that the platform team knows which controls remain in place and which must be disabled if the license changes.
Recurring and one-time costs of running LiteLLM in your environment
This table splits the cost of a self-hosted LiteLLM gateway into one-time work and recurring running costs, and shows who pays for each item and what to ask for in a quote. The MIT core carries no license fee, so most of the cost sits in infrastructure, people and the Enterprise terms you choose. Use the right-hand column to build your request for quote from the same list.
| Cost component | Who pays and when | What drives it | What to ask for in a quote |
|---|---|---|---|
| One-time: solution design | Your organization or implementation partner, once before build | Number of providers, private models, teams, identity sources and compliance requirements in scope | A written design covering key hierarchy, routing, data flows and logging, with named deliverables |
| One-time: initial configuration and key migration | Partner or internal platform team, once per environment | Count of virtual keys, budgets, model aliases and provider credentials to create and replace | Itemized configuration tasks, the key replacement approach and who rotates provider credentials |
| One-time: application migration | Application teams with partner support, once per application | How many applications still call provider SDKs directly and how many code paths change | Scope per application, cutover plan and regression testing included or excluded |
| One-time: security review and load testing | Your security team and the partner, once before go-live | Exposure of the proxy, master key handling, secret manager choice and expected peak request volume | Test scope, environment used, evidence delivered and retest terms if findings are raised |
| Recurring: proxy hosting | Your cloud or data center budget, monthly | Proxy pod count, CPU and memory per worker (the production guide suggests 1 vCPU and 4 GiB per worker), and traffic growth | Node sizing assumptions for your expected load, and how autoscaling is configured |
| Recurring: PostgreSQL and Redis | Your cloud or data center budget, monthly | PostgreSQL is the primary supported database. Redis 7.0 or newer is needed once more than one proxy instance runs, for shared rate limits and router state | Managed or self-hosted choice, backup retention, high availability setup and who patches these services |
| Recurring: Enterprise license or subscription | Your organization, to LiteLLM, only if Enterprise features are required | The MIT core carries no license fee. Enterprise adds SSO beyond five users (free from v1.76.0 up to five users), SCIM, JWT, audit logs, RBAC, IP allowlisting and secret manager integrations | Exact license terms, user or seat basis, renewal terms and which features the license covers |
| Recurring: support tier | Your organization, to LiteLLM, if you choose Enterprise support | Optional 24/7 SLA terms are offered under Enterprise: 1 hour response for critical issues and 72 hours for security patches. Standard options differ | Response targets in writing, coverage hours, escalation path and whether the SLA is in the Enterprise contract |
| Recurring: upgrade and regression testing | Your platform team or a retained partner, each release cycle | LiteLLM releases are frequent, and only the four most recent stable minor versions are supported. Routing and budget tests repeat on each upgrade | Upgrade cadence, test scripts delivered, and whether database migration checks are included |
| Recurring: provider spend | Your business units or cost centers, directly to each model provider | Token volume per model, provider price changes and routing choices. This spend is separate from the gateway itself | Budget owners per team, budget limits on virtual keys and a monthly spend report |
| Recurring: internal skills | Your staff, as salary or partner retainer | Kubernetes operations, PostgreSQL and Redis administration, on-call duties and security monitoring of the proxy | Named owners for each skill, and whether the partner covers on-call or only business hours |
How a LiteLLM cost model moves from scope to decision
The sequence starts with a written, fixed-scope agreement and ends with a decision record that separates confirmed costs from estimates and open questions for LiteLLM. Each phase produces an artifact that the next phase depends on, so the model can be audited and revised.
Agree a fixed scope in writing
Before any analysis starts, DeployOpen and your team agree the scope, deliverables and timeline in a written, fixed-scope agreement. For cost of ownership, the scope names the environments, provider families, team counts and LiteLLM editions the model covers, and it lists what falls outside. Output: a scope document that sets the boundary for every later cost line. Done when the assumptions list is attached to the agreement and both sides have reviewed and accepted it.
Discover governance and compliance needs
Run workshops with security, compliance and platform leads to list the controls the gateway must support, such as single sign-on, audit logging, role-based access, IP restrictions, secret manager use and evidence retention. Tag each need as required, preferred or not needed, and link it to the policy or assessment that drives it. Output: a governance requirements register. Done when every requirement has an owner and a source document, and anything still unclassified sits in the open items list.
Inventory providers, private models, teams and environments
Record every LLM provider account, private or self-hosted model, team and application that will call the gateway, along with the environments (development, staging, production and any air-gapped network) where it runs. Estimate the virtual keys each team needs and note which applications still call provider SDKs directly. Output: an inventory sheet that feeds sizing and edition mapping. Done when the platform owner has confirmed each row and a named owner is recorded for each provider account.
Size proxy, PostgreSQL and Redis tiers
Translate the inventory into infrastructure tiers using LiteLLM's production guidance. PostgreSQL is the primary supported database, and Redis 7.0 or newer is required once more than one proxy instance runs, for shared rate limits, router state and cache. The guidance suggests about 1 vCPU and 4 GiB memory per worker, and it recommends one Uvicorn worker per Kubernetes pod with horizontal scaling. Output: a sizing sheet with pod counts, database and Redis tiers and the assumed peak load. Done when each tier traces to a guidance line and the load assumptions are written down.
Map requirements to LiteLLM editions
Compare the governance register with the feature split between the MIT-licensed code and the enterprise directory, which uses its own license. Confirm which requirements the open source edition meets and which need LiteLLM Enterprise, such as SSO beyond the free five-user limit that applies from v1.76.0, SCIM, JWT authentication, audit logs, organization and team RBAC, IP allowlisting and secret manager integrations. Output: an edition matrix marking each requirement as open source, Enterprise or unconfirmed. Done when every Enterprise line cites the requirement that triggers it.
Build the one-time and recurring cost model
Build separate one-time lines for design, build, application migration, SSO and secret configuration, testing and documentation. Build recurring lines for pod compute, PostgreSQL, Redis, any Enterprise license, support tier, upgrades and internal staff time. For each line, name who is paid: DeployOpen under the agreed scope, your staff, your cloud or data center provider, or LiteLLM. Output: a cost model with quote-ready line items and stated unit assumptions. Done when each line states its cost driver and the quote request lists what to ask for.
Write the decision record and open items
Summarize the scope, sizing, edition matrix and cost model in a decision record that states the chosen edition, the assumptions behind each cost line and the decision owner. List open items to confirm with LiteLLM, such as Enterprise pricing, support terms, SLA options and the current supported release line. Also list items to confirm in your own environment, such as network paths and cloud account limits. Output: a signed decision record. Done when every open item has a named owner and a target date set by your team.
Which parts of the cost work your team can keep and which to outsource
LiteLLM cost of ownership spans licensing, infrastructure, people and support, and each part depends on different skills inside your organization. The cards below show what each part needs from your team and where an outside partner can add an independent check before you commit budget.
Edition and license mapping
The LiteLLM repository is dual licensed: code under the enterprise directory follows its own license, and the rest is MIT. Mapping each feature you need to the correct edition requires procurement and security review, because governance features such as SCIM, JWT authentication, audit logs, RBAC and secret manager integrations sit on the Enterprise side. Confirm the SSO user threshold and support terms in writing with the vendor before the budget is approved.
Infrastructure sizing
Proxy pods, PostgreSQL and Redis each scale differently, and the production guide suggests starting points per worker that your team must translate into node counts, replicas and database capacity. Sizing needs Kubernetes and database skills, including connection pool limits and spend write batching. An independent review of sizing assumptions is useful before you commit to reserved capacity, since the assumptions drive most of the recurring infrastructure line.
Staffing model
Operating a gateway is ongoing work: onboarding providers, issuing virtual keys, tuning routing and reviewing budgets all need a named owner. Engineering management must decide how many people carry that load, whether it sits with platform engineering or an application team, and how on-call coverage is shared. Estimate the hours per month for each task with your own team before comparing against a partner retainer, because these hours recur for the life of the gateway.
Support model
Enterprise support terms, including response targets for critical issues and security patches, must be matched to your internal operations and security owners. Operations staff need to know who triages a failed upgrade or a provider outage, and security staff need to confirm how vulnerability notices reach them. Ask the vendor to specify exact response targets in the contract, and decide which tier your organization needs before you size the internal rota.
Written cost model
A cost model brings licensing, infrastructure, staffing and support together as one-time and recurring lines, each with an owner and an assumption. Finance input is needed to set the depreciation period, currency, cloud commitment terms and the review cycle for usage growth. Keep the model in a shared document with its assumptions listed, so that a later quote or a change in provider pricing can be tested against the same baseline.
What usually goes wrong in LiteLLM cost models and how to prevent it
The most expensive LiteLLM cost model errors come from assumptions made before the first invoice arrives. Six patterns recur: treating the MIT core as complete for governance, miscounting SSO users, underbudgeting PostgreSQL and Redis, leaving provider spend out of the model, ignoring the support window when planning upgrades, and assuming support SLAs are included. Each one is cheap to check at the start and expensive to discover after go-live.
Assuming the MIT core covers every governance need. LiteLLM is dual licensed. Code under the enterprise/ directory uses the license in enterprise/LICENSE, and everything else is MIT. Audit logs, organization and team RBAC, IP allowlisting, JWT authentication, SCIM and team-level guardrails and logging sit in the Enterprise feature set. Prevention: map every control your assessor or risk committee expects against the Enterprise feature list, then mark each as open source, Enterprise or custom build. Confirm with LiteLLM, in writing, which features are covered by the enterprise/ license and which are not, because a custom build that replicates a licensed feature carries its own maintenance cost.
Forgetting that SSO is free only up to five users. From v1.76.0, admin UI SSO with Google, Microsoft Entra ID, Okta or generic OIDC is free for up to 5 users. Beyond that, an Enterprise license is required. Many teams pilot with a small admin group, then add platform engineers, team leads and finance reviewers without re-checking the count. Prevention: count the people who will sign in to the admin UI, not the people who use the gateway through virtual keys, and set a review point before the sixth user is added. Confirm with LiteLLM whether the count includes service or break-glass accounts.
Underestimating PostgreSQL and Redis once more than one proxy instance runs. PostgreSQL is the primary supported database, and virtual keys require it for budgets and spend. Redis 7.0 or newer becomes necessary once more than one proxy instance runs, for shared rate limits, router state and cache. Teams often budget for a single small database and no cache, then find they need managed, highly available instances in production. Prevention: size both as production services from the start, including backups, failover and networking. Ask LiteLLM and your platform team which high availability and backup configurations they support, and get the resulting infrastructure cost into the model.
Leaving provider spend out of the model. The gateway cost is only part of the total. Model provider and cloud inference charges usually dominate, and they are billed by OpenAI, Anthropic, Gemini, Bedrock, Azure or your own model hosting. LiteLLM budgets limit spend per key, user and team, but they do not replace the provider invoices. Prevention: model provider spend as a separate line, forecast it by team and model, and reconcile it monthly against gateway spend records. Confirm how your chosen providers report usage and whether gateway budgets are enforced against provider prices you have configured.
Ignoring the four-minor-version support window when budgeting upgrades. LiteLLM maintains support for the four most recent stable minor versions for open source and Enterprise deployments. If you fall outside that window, you lose the path to supported fixes without an unplanned upgrade. Each upgrade also needs time for database migrations and regression testing of routing and budgets. Prevention: schedule upgrades on a fixed cadence, budget staff time for each one, and keep a test environment that mirrors production. Confirm the current supported versions and release dates on the LiteLLM releases page before you commit to a schedule.
Treating support SLAs as included by default. LiteLLM Enterprise support includes a dedicated channel with the engineering team. Optional 24/7 SLAs offer a 1 hour response for critical issues and 72 hours for security patches. These are options, so the response times in a quote depend on the agreement you sign. Prevention: decide which severity levels and hours your business needs, then price those SLAs explicitly. Confirm with LiteLLM exactly what is included in the base Enterprise agreement, what the SLA covers, and whether DeployOpen's retainers would sit alongside or replace any part of it.
How the cost model changes by starting point and environment
Teams leaving a commercial AI gateway already pay a license line, so the comparison is between the current contract and the infrastructure, labor and transition work that replace it. Open-source LiteLLM removes the gateway subscription for the MIT-licensed core, but the proxy, PostgreSQL, Redis and migration effort become visible costs. Two lines often grow during the switch: running both gateways in parallel while applications move, and recreating existing budgets, keys and team mappings in LiteLLM.
- Shrinks: the gateway subscription, once you confirm the MIT-licensed core covers the features you use.
- Grows (one-time): migration work to move keys, model aliases and applications, plus a period of duplicate running costs.
- Grows or stays (recurring): Enterprise licensing if your current gateway provides SSO for more than five users, audit logs, SCIM or secret manager integrations that you rely on.
- Moves to your team (recurring): PostgreSQL and Redis hosting, proxy pods, upgrades and on-call time.
Check which features in your current contract map to Enterprise features, and ask LiteLLM to confirm the licensing position in writing before you compare totals.
Without an existing gateway, every cost line is new, and one-time build work is large relative to the recurring run. Early decisions decide whether the Enterprise license enters the first budget. Questions about how many users need SSO, whether audit logs are required and how many proxy instances you expect to run should be answered before procurement starts.
- Build (one-time): provider connections, teams, virtual keys, budgets and routing configuration are all new work, and model changes add recurring effort.
- Database (recurring): PostgreSQL is required for virtual keys, so a managed or self-run database is a baseline line item from day one.
- Cache (recurring): once more than one proxy instance runs, Redis 7.0 or newer is needed for shared rate limits and router state, so plan it before you scale out.
- Identity (recurring): the free SSO allowance covers up to five users from v1.76.0, and Enterprise licensing is required beyond that.
- Support (recurring): decide between internal ownership and Enterprise support, including whether you need the optional 24/7 terms described in the Enterprise documentation.
Ask for the license tier, the support terms and the minimum supported version in writing, and confirm the free SSO user limit with LiteLLM before you fix the first-year budget.
Existing PostgreSQL and Redis services shift cost from new purchases to added load and capacity. The proxy runs as pods, and LiteLLM recommends one Uvicorn worker per pod with horizontal scaling, so compute grows with replica count. Shared data services then absorb the extra key lookups, spend writes and rate-limit traffic, and those costs appear on other teams' budgets.
- Shrinks: new database or cache provisioning, if the existing services meet the version and capacity needs.
- Grows (recurring): load on shared PostgreSQL from virtual key checks and spend writes. LiteLLM batches spend updates to the database every 60 seconds at scale, which your DBA should review.
- Grows (one-time): Redis separation or sizing, since shared rate limits and router state depend on it. Confirm the version is 7.0 or newer.
- Recurring: pod compute using the production guide's sizing of 1 vCPU and 4 GiB memory per worker, multiplied by replicas and environments.
- Recurring: Kubernetes operations, secret handling for LITELLM_MASTER_KEY and upgrade testing across the supported minor versions.
Confirm with your database and cache owners whether shared services will carry the added load and meet the Redis minimum, and validate sizing against LiteLLM's current production guidance.
In air-gapped or regulated settings, the Enterprise question depends on controls as much as features. Where secrets must sit in an approved manager, where administrative access must be restricted to defined networks, or where audit records must be retained, the Enterprise feature set determines licensing and integration effort. Isolated networks also add delivery work, because images, updates and documentation must reach the environment without direct public access.
- Grows (recurring): Enterprise licensing if you need audit logs, organization and team RBAC, IP allowlisting or secret manager integrations for AWS, Azure, Google, HashiCorp Vault or CyberArk.
- Grows (recurring): internal delivery of images and release updates into the isolated network, with each upgrade retested before rollout.
- Grows (one-time and at review): control evidence for assessors. DeployOpen prepares systems and evidence, and independent auditors reach the conclusions.
- Shrinks (variable): external provider usage and duplicate provider keys where private models handle some workloads. The size of this change depends on your model mix.
- Recurring: Enterprise support terms that match your incident and patch obligations, including the 72-hour security patch figure in the Enterprise documentation.
Confirm with LiteLLM which controls are included in your license, whether the secret manager integrations and IP allowlisting fit your network design, and how security patches reach an offline environment.
What your team needs to provide before a LiteLLM cost review
A cost review for a self-hosted LiteLLM gateway can only be as accurate as the inputs your team brings to it. Before any edition decision or infrastructure estimate, gather a current inventory of model providers and private models, because each provider account, each self-hosted model endpoint and each contract term changes both the routing design and the number of keys and budgets that have to be administered. The platform or AI engineering lead should own this list, with procurement attaching contract details for every commercial provider. If the inventory is missing, the review will assume a generic provider mix, and the Enterprise and infrastructure lines will be wrong in ways that surface only after rollout.
Next, supply expected user and team counts, along with the number of applications that will call the gateway. These figures drive how many virtual keys, team budgets and admin accounts the deployment must manage, and they determine whether the free five-user SSO allowance is enough or whether an Enterprise license will be needed for single sign-on. The head of IT or the business owner of AI services should own this estimate, and it should distinguish named administrators from application consumers. Without it, the review can only describe licensing thresholds in general terms, not show where your organization crosses them.
Identity and environment details come next. Provide the identity provider in use (Google, Microsoft Entra ID, Okta or a generic OIDC service), the group or claim structure you plan to map to teams, and a list of environments such as development, staging and production, including whether each runs in a separate cloud account or cluster. The identity team should own the identity details and the platform team should own the environment list. If identity requirements such as JWT authentication, SCIM provisioning, IP allowlisting or audit log retention are not stated, the review cannot separate features you need from features you merely want, and the Enterprise cost line stays open.
Traffic estimates, compliance obligations and existing data standards complete the input set. Ask the application owners for request volumes, peak patterns and token profiles, and ask the security or compliance lead to name the frameworks, logging retention rules and data residency requirements that apply to prompts and responses. Your database and cache teams should state whether PostgreSQL and Redis must come from a standard managed service, an approved internal platform or a specific version baseline, since the production guide requires Redis 7.0 or newer once several proxy instances run. Confirm the Redis and PostgreSQL versions with your own standards and the LiteLLM documentation before the review, rather than assuming them.
Finally, name two people before the review starts: a budget owner who approves recurring spend for infrastructure, licenses and support, and a decision owner who selects the edition and signs the licensing terms. These are often different roles, and the review will stall if they are not identified. A missing budget owner means infrastructure and support costs cannot be classified as recurring operating expense or one-time project spend. A missing decision owner means the MIT open source option and the Enterprise option cannot be compared on a single agreed basis. Put both names in writing alongside the rest of the input pack.
Questions buyers ask about LiteLLM cost and editions
Does the open-source LiteLLM edition have a license fee?
The core code carries no license fee under the MIT license. LiteLLM is dual licensed: content under the enterprise/ directory uses the license in enterprise/LICENSE, and everything else is MIT, according to the project's LICENSE file. Your main costs are therefore infrastructure, people and support. Treat the enterprise/ directory as a separate license category in your cost model, and have your legal team confirm which files your build includes before rollout. Infrastructure for proxy pods, PostgreSQL and Redis applies in either edition and is covered in the cost breakdown. Confirm current license terms in the LICENSE file for the release you plan to deploy, and check them with the vendor before you sign anything.
Which LiteLLM features push a team to the Enterprise edition?
The most common trigger is single sign-on beyond the free limit. From v1.76.0, admin UI SSO is free for up to 5 users, and an Enterprise license is needed beyond that. Other Enterprise features include SCIM, JWT authentication with identity provider tokens, audit logs, organization and team RBAC, IP allowlisting, secret manager integrations for AWS, Azure, Google, HashiCorp Vault and CyberArk, and team-level guardrails and logging. Teams usually reach this decision when user counts grow, when audit evidence is requested, or when secrets must live in an enterprise vault. Map each control your organization requires to the current Enterprise documentation, then confirm eligibility with the vendor before you budget for the license.
How long does a LiteLLM cost study take to complete?
No fixed duration applies, because the length depends on the scope. The number of model providers and private models to cost, the number of teams and applications that will hold keys, and whether an existing gateway or direct provider SDK use must be inventoried all change the workload. Open decisions on Kubernetes, PostgreSQL and Redis hosting add review cycles. Most DeployOpen engagements are fixed-scope, so the timeline is agreed in writing before work starts and tied to named deliverables. Ask for the milestone list in the quote, along with the client dependencies that could move dates, such as access to pricing data, cloud accounts or approval windows.
What does the client need to provide for a cost study?
The client supplies the facts the model depends on. Expect to provide a list of model providers with current contract terms, expected request volume by team or application, and an inventory of applications that call providers directly. You will also need access to the target cloud account, cluster or data center, identity provider details if SSO is planned, data residency and logging rules, and the names of people who approve budgets and key issuance. Existing spend reports help validate assumptions. Missing inputs usually widen the range of the model, so agree an owner and due date for each item before the study starts. Ask the partner which inputs it needs and how it will handle sensitive data.
Can an in-house team build a LiteLLM cost model alone?
Yes, an in-house team can build the model alone if it has the right skills. The work includes sizing proxy pods, where LiteLLM's production guide suggests 1 vCPU and 4 GiB memory per worker as a baseline, and understanding PostgreSQL, plus Redis 7.0 or newer once more than one proxy instance runs. It also requires current provider pricing, an edition decision based on identity and audit needs, and someone who can read license files and support terms. Check whether the same team can keep the model current after each release. A cost model that nobody maintains loses value quickly. If internal capacity is thin, ask a partner to review your assumptions before you commit budget.
How do LiteLLM support tiers differ between open source and Enterprise?
The open-source edition does not include the Enterprise support terms, so teams rely on public project resources, documentation and their own engineers. LiteLLM Enterprise adds a dedicated channel with the engineering team and optional 24/7 SLAs, with a 1 hour response for critical issues and 72 hours for security patches, according to LiteLLM's enterprise documentation. Treat the tier you need as a budget line, because response times are a cost decision. Check whether the SLA covers your hours, the severity definitions and the escalation path, and whether it applies to the pods, database and Redis you operate yourself. Partner support is scoped and priced separately in writing, so confirm those terms with the vendor and your partner.
How does LiteLLM's four-version support window affect budgeting?
LiteLLM maintains support for the four most recent stable minor versions for both open source and Enterprise deployments, according to its enterprise documentation. For budgeting, this means upgrades are recurring work, not a one-time event. Each upgrade needs regression testing of routing, budgets, virtual keys and database migrations before rollout. The GitHub releases page lists v1.105.1, published October 14, 2026, so your planning calendar should track new minor releases against your own upgrade cycle. Ongoing upgrades and testing are available as DeployOpen retainers, and the cost depends on the agreed scope. Confirm the current support policy with the vendor before you set the annual figure.
Who pays for proxy pods, PostgreSQL and Redis hosting?
The client pays for this infrastructure in its own cloud accounts, data centers or air-gapped network, in either edition. These costs recur. They include compute for proxy pods, PostgreSQL, and Redis 7.0 or newer once more than one proxy instance runs, since Redis holds shared rate limits, router state and cache. LiteLLM recommends one Uvicorn worker per pod on Kubernetes and horizontal scaling, and it batches spend updates to the database every 60 seconds at scale, which affects database sizing. Main drivers are request volume, the number of teams and keys, log retention and resilience targets. Ask for these sizing assumptions in any quote so you can compare options fairly.
How DeployOpen scopes, delivers and hands over LiteLLM cost work
DeployOpen scopes LiteLLM cost of ownership and editions as a written, fixed-scope piece of work. We separate what the MIT-licensed core covers from features that need a LiteLLM Enterprise license, then document the proxy, PostgreSQL and Redis costs as one-time and recurring items your team can review.
How we scope
- Written scope lists which governance features your team needs and whether each requires an Enterprise license.
- Infrastructure inventory covers proxy pods, PostgreSQL, Redis and the hosting environment they run in.
- Cost model separates one-time setup effort from recurring infrastructure, licensing, support and staff time.
How we build
- Deployment in your own cloud accounts, data centers or air-gapped network, with one Uvicorn worker per Kubernetes pod.
- Configuration of virtual keys, budgets and TPM or RPM limits so spend is tracked per team.
- Testing of routing, budgets and Enterprise-only features so cost decisions rest on observed behavior.
How we hand over
- Cost of ownership document with the license boundary, cost components and a list of items to confirm with LiteLLM.
- Runbook covering the LITELLM_MASTER_KEY secret, spend update batching and database sizing decisions.
- Quote-ready list of recurring items: infrastructure, Enterprise licensing if needed, support tier and staff time.
How we support
- Ongoing support is available as a retainer for upgrades and operations after go-live.
- Support tier is a cost decision: LiteLLM Enterprise offers optional 24/7 SLAs, which you should confirm for your needs.
- LiteLLM maintains the four most recent stable minor versions, so plan your upgrade cadence against that window.
