LinuxAir documentation
LinuxAir is an OpenAI-compatible endpoint that sends each request to the cheapest of your models that is predicted to be as good as the best one.
QuickstartConnect a provider, add models and send your first routed request in five minutes.
API referenceEndpoints, parameters, the linuxair response block, streaming and errors.
Routing & policyThe routing math, quality tolerance, modes, answer checks and learning.
Models & providersSupported providers, automatic pricing, fingerprinting and the shared catalogue.
Billing & costingHow model cost, savings and platform credits are calculated.
Evals & testingCompare models, evaluate on your own prompts, shadow-test and catch drift.
Teams & privacyRoles and invitations, PII redaction and spend caps.
Self-hostingRun LinuxAir on your own servers — requirements, settings and offline operation.
Key concepts
| Term | Meaning |
|---|---|
| Workspace | Your account's container for providers, models, API keys, requests and credits. |
| Provider | A connection to a model API (OpenAI, Anthropic, Groq, Ollama…) using your own key. |
| Model | A specific model on a provider that takes part in routing, with its prices and context window. |
| Probe set | A shared set of test prompts across task types, used to measure every model the same way. |
| Cluster | A group of similar prompts (for example code or structured output). About eight by default. |
| Fingerprint | A model's error rate in each cluster — what the router uses to predict quality. |
| Tolerance (τ) | The most predicted quality you'll give up to save money. |
| Price weight (λ) | How eagerly the router takes a cheaper model among near-equals. |
| Answer check | A judge model scoring an answer and escalating weak ones to a stronger model. |
| Credits | The unit for platform fees: per routed request and per model fingerprint. |
| Semantic cache | Reuse of an earlier answer for a near-identical prompt — no tokens, no credits. |
| Eval set | Prompts from your own traffic that models are scored on. |
| Shadow test | A sampled request quietly re-run on a second model and judged. |
| Role | Owner, Developer or Viewer — what a workspace member may do. |
The request lifecycle
- Your app calls
POST /v1/chat/completionswith a LinuxAir key andmodel: "auto". - Sensitive values are masked if redaction is on, and the semantic cache is checked — a hit returns immediately, free.
- The prompt is embedded and matched to its nearest clusters.
- Each eligible model's quality is predicted from its fingerprint, with an uncertainty range.
- Models outside your tolerance are dropped; the best value among the rest is chosen.
- The request is sent to that model on your provider key. On a provider error, the next candidate is tried.
- If a weaker model was chosen or the router was unsure, a judge may check the answer and escalate once.
- The response returns with a
linuxairblock explaining the decision, and the request is logged.
New here? Start with the Quickstart, then read Routing & policy to choose the right trade-off.