AirLLM vs OpenRouter

At a glance

Both products put one API in front of many AI models, but they start from different questions. OpenRouter asks which of hundreds of models and providers you want to reach. AirLLM asks which model each step of a coding agent's work needs, and answers it for you through Air Router.

Routing approach

With AirLLM you don't pick a vendor model. Every AirLLM model is a routing model: airllm-auto routes across supported providers, airllm-anthropic stays within Anthropic's Claude family and airllm-openai within OpenAI's models. Air Router then chooses the underlying model for each request, so quick edits get fast handling and hard problems get a stronger model.

Air Router is built around coding-agent sessions. It routes individual agent steps, considers existing prompt caches before switching models (a switch can force an expensive cache rebuild), escalates to stronger models when a task needs it, and falls back to another provider when one fails. Eligible routine work can run on AirGPU, AirLLM's own GPU capacity, with fallback to cloud providers.

OpenRouter's default is explicit: you name the model and it picks a provider, weighting toward lower prices and skipping providers with recent outages. Its Auto Router classifies each prompt into a task type and ranks candidate models by community share of spend for that task. A cost_tier setting and allow and deny lists shape the choice, and there's no extra fee. OpenRouter also documents a Pareto Router that picks a coding model by an external coding benchmark percentile.

So both offer automatic model selection. The difference is what drives it: OpenRouter ranks models for a task type across a very large catalog, while Air Router makes its choice inside a coding-agent session, with prompt caches, tool calls and loops in view.

Coding-agent integration

Both document setups for the common coding agents.

• Claude Code: AirLLM uses ANTHROPIC_BASE_URL="https://api.airllm.ai/" with your AirLLM key as ANTHROPIC_AUTH_TOKEN. OpenRouter's guide sets ANTHROPIC_BASE_URL to https://openrouter.ai/api and notes it is only guaranteed to work with the Anthropic first-party provider.
• Codex CLI: both use a custom provider in ~/.codex/config.toml. AirLLM's base URL is https://api.airllm.ai/v1 with wire_api = "responses".
• Cursor: both rely on Cursor's OpenAI base URL override. OpenRouter labels its Cursor integration beta.

Anthropic's own documentation says it doesn't endorse third-party gateways and doesn't support routing Claude Code to non-Claude models through any gateway. That applies to both products. If you want Claude Code to stay on Claude models through AirLLM, use airllm-anthropic; airllm-auto routes across providers. The Claude Code router guide covers both options.

AirLLM also ships its own coding agent, AirCode CLI, which uses Air Router with no extra setup. Step-by-step instructions for every supported tool are in the Developer Guide.

Cost controls and caching

OpenRouter's controls are about money in and money out: prepaid credits, credit limits on each API key with optional scheduled resets, and workspace budgets that return an error once they're reached. Its activity view filters spend by model, provider, key, app and user.

AirLLM's controls sit on your plan and on agent behaviour. Monthly plans show a weekly usage budget for each key, and the Token Plan draws down prepaid credits. Air Router is also designed to interrupt unproductive agent loops (repeated searches, edits and tool calls) before they consume more tokens. These controls are best-effort, not a guarantee that every charge is stopped.

On caching, OpenRouter passes the providers' prompt caching through and keeps a conversation on the same provider so the cache stays warm. You can opt in to exact-match response caching with a header. AirLLM reuses eligible cached responses and trims repeated context, such as duplicated files and completed tool history, before a request reaches the model.

Deployment and data

Both are hosted services, so neither needs you to run gateway infrastructure. OpenRouter offers in-region hosts and a Private Endpoints add-on on its higher plans. AirLLM has no on-premises or self-hosted deployment, and model availability depends on its upstream providers.

On data, OpenRouter says it doesn't log prompts and completions by default but does log request metadata. It offers opt-in input and output logging, provider filtering by data policy, and zero data retention routing. AirLLM never uses any prompt to train models. Requests 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. With either product, the model provider that answers a request processes it under its own terms. On AirLLM's paid plans, AirLLM avoids providers that train on prompts; on its Free plan, providers may train on and retain them.

When to choose which

Choose OpenRouter if

• You want to reach a very large catalog directly: its homepage lists 500+ models from 80+ providers.
• You want to pin exact models and steer provider selection by price, throughput or latency.
• You want to bring your own provider keys, use free model variants, or serve many kinds of applications from one bill.

Choose AirLLM if

• Your main workload is coding agents (Claude Code, Codex CLI, Cursor, AirCode) or multi-step agents, and you want the model chosen per step.
• You want routing that accounts for prompt caches, repeated context and agent loops, not only the price of a token.
• You'd rather choose a provider family or use case (a routing model) than track individual model releases.

AirLLM doesn't expose a list of individual vendor models to pick from. If that kind of direct, per-model control is what you need, OpenRouter is the closer fit.

Using both

A coding tool points at one base URL at a time, but nothing stops a team from using both products for different jobs. A common split is to send coding agents through Air Router and keep other applications on OpenRouter. Each service bills and limits usage separately, so budgets have to be managed in both places.

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

Frequently asked questions

Related

Sources

• OpenRouter FAQ
• OpenRouter pricing
• OpenRouter — Auto Router
• OpenRouter — Pareto Router
• OpenRouter — Provider selection
• OpenRouter — Model fallbacks
• OpenRouter — Anthropic Messages API
• OpenRouter — Responses API
• OpenRouter — Workspace budgets
• OpenRouter — Prompt caching
• OpenRouter — Response caching
• OpenRouter — Data collection
• OpenRouter — Claude Code integration
• OpenRouter — Codex CLI
• OpenRouter — Cursor integration
• Claude Code docs — LLM gateway configuration