AirLLM vs LiteLLM

At a glance

The biggest difference is who runs the gateway. With LiteLLM, your team deploys and operates an open-source proxy and configures the providers behind it. AirLLM is a hosted service: you point your coding agent at one endpoint with one AirLLM key, and Air Router chooses the model.

Routing approach

LiteLLM gives platform teams routing building blocks. You define model groups and deployments, then choose a strategy. The options are weighted shuffle (the recommended default), usage-based routing that respects rate limits, least-busy, latency-based and cost-based routing. When a call fails after its retries, LiteLLM falls back to another model group. It also has separate fallbacks for context-window and content-policy errors, plus cooldowns, tag-based routing and provider budget routing.

LiteLLM also offers an Auto Router, marked as a beta add-on, which aims to send each request to the lowest-priced model that can still answer it well. It sorts requests into tiers using a heuristic, an LLM classifier, keyword rules or a plugin. Customising the classifier is an Enterprise capability.

AirLLM packages the routing decision as a product rather than a configuration. You choose a routing model: airllm-auto across supported providers, airllm-anthropic for Anthropic's Claude family, airllm-openai for OpenAI's models, or airllm-agent for your own agents. Air Router then picks the underlying model per request. It is built around coding-agent sessions: it routes agent steps, weighs existing prompt caches before switching models, escalates to stronger models when needed and falls back across providers.

Coding-agent integration

Both document how to connect the popular coding agents:

• Claude Code: LiteLLM uses ANTHROPIC_BASE_URL pointed at your proxy with a virtual key as ANTHROPIC_AUTH_TOKEN. AirLLM uses ANTHROPIC_BASE_URL="https://api.airllm.ai/" with your AirLLM key.
• Codex CLI: both use a provider block in ~/.codex/config.toml over the Responses API. AirLLM's base URL is https://api.airllm.ai/v1.
• Cursor: LiteLLM's guide uses Cursor's OpenAI base URL override and says, "Cursor does not officially support AI Gateways, our work here is best effort." AirLLM lists Cursor as a compatible endpoint with the same override.

Anthropic's documentation says it doesn't endorse third-party gateways and doesn't support routing Claude Code to non-Claude models through any gateway. On AirLLM, airllm-anthropic keeps Claude Code on Claude models; see the Claude Code router guide. AirLLM's own coding agent, AirCode CLI, uses Air Router out of the box.

Cost controls and caching

LiteLLM's cost controls are extensive and fully in your hands. Virtual keys carry their own budgets and model access. Budgets can also be set globally and for teams, team members, users, models, agents and customers, alongside token and request rate limits. Spend tracking covers keys, users and teams across providers, and callbacks send logs to tools such as Langfuse, OpenTelemetry and Datadog.

AirLLM's controls are fewer and managed for you. Monthly plans show a weekly usage budget for each key, the Token Plan draws down prepaid credits, and the dashboard shows usage by team, user and model. Air Router is also designed to interrupt unproductive agent loops before they consume more tokens. These controls are best-effort, not a guarantee that every charge is stopped.

For caching, LiteLLM supports several response-cache backends, including semantic caches on Redis or Qdrant, and passes provider prompt caching through. AirLLM reuses eligible cached responses and trims repeated context, such as duplicated files and completed tool history, before the request reaches the model.

Deployment and data

This is where the two differ most. LiteLLM runs wherever you deploy it, including fully air-gapped environments. You keep requests inside your network, choose your providers and supply their credentials. In exchange, your team operates the proxy, its database and its upgrades: LiteLLM releases weekly. By default each process also downloads a model pricing map from GitHub at startup; an environment setting turns that off.

AirLLM is hosted only, so there's nothing to deploy. Model availability depends on AirLLM's upstream providers. Prompts and responses pass through short-lived, account-scoped caches, which generally expire within 24 hours of last use. When a request fails, AirLLM may keep its content, with secrets removed, to diagnose the failure, and it keeps samples of responses to check routing quality. AirLLM never uses any prompt to train models. The model provider that answers a request processes it under its own terms: on paid plans AirLLM avoids providers that train on prompts, while on the Free plan providers may train on and retain them.

When to choose which

Choose LiteLLM if

• You need to self-host, including in air-gapped environments, or want an MIT-licensed gateway you can inspect and extend.
• Your platform team wants fine-grained budgets, rate limits and routing strategies across many providers and teams.
• You already hold provider contracts and want one internal gateway in front of them.

Choose AirLLM if

• You don't want to run gateway infrastructure, and one hosted endpoint and key is enough.
• Your main workload is coding agents or multi-step agents, and you want the model chosen per step for you.
• You want routing that accounts for prompt caches, repeated context and agent loops without writing routing rules.

Using both

Teams can run both side by side, for example keeping internal applications on a self-hosted LiteLLM proxy while developers point their coding agents at Air Router. Each coding tool uses one base URL at a time, and each service tracks its own usage, so budgets and reporting live in two places.

Note. Product details change often. This comparison was compiled from each vendor's public documentation on October 20, 2026. LiteLLM and other product names are trademarks of their respective owners.

Frequently asked questions

Related

Sources

• LiteLLM on GitHub (README and license)
• LiteLLM website
• LiteLLM docs — overview
• LiteLLM docs — Deploy
• LiteLLM docs — Enterprise
• LiteLLM docs — Routing
• LiteLLM docs — Fallbacks and reliability
• LiteLLM docs — Auto Router
• LiteLLM docs — Virtual keys
• LiteLLM docs — Caching
• LiteLLM docs — Anthropic /v1/messages
• LiteLLM docs — Claude Code
• LiteLLM docs — Codex CLI
• LiteLLM docs — Cursor integration
• LiteLLM docs — Data security
• Claude Code docs — LLM gateway configuration