Models & providers
Connect any provider with your own key, pick models from its live catalogue and let LinuxAir measure them.
Supported providers
| Provider | API format | Notes |
|---|---|---|
| OpenAI | OpenAI | GPT and o-series chat models |
| Anthropic | Anthropic Messages | System prompts and stop sequences translated automatically |
| Google Gemini | OpenAI-compatible endpoint | |
| Groq, Together, DeepSeek, Mistral, xAI | OpenAI-compatible | Presets fill in the base URL |
| OpenRouter | OpenAI-compatible | Exact prices from the feed |
| Ollama | OpenAI-compatible | Local models, priced as free |
| Custom | OpenAI-compatible | Any endpoint that implements /chat/completions |
Use Test on a provider card to check the key and list its models.
Adding models
Models → Add models shows the provider's chat models (embedding, audio, image and moderation models are filtered out). Search, tick several and add them together. You can also enter a model id manually.
Automatic pricing
Input and output prices (USD per million tokens) and context windows come from a public model feed — OpenRouter's model list by default — matched against your provider's model ids:
- Exact id, for example
openai/gpt-4o-mini. - Same vendor, normalised id — dates, dots and separators are normalised, so
claude-haiku-4-5-20251001matchesanthropic/claude-haiku-4.5. - Loose id — serving suffixes such as
-versatileor-instructare ignored. These prices are labelled Estimated, because hosts like Groq and Together set their own prices.
Prices refresh daily and on Refresh prices. If you edit a price by hand it's locked and won't be overwritten; Switch back to automatic pricing unlocks it. If the feed is unreachable, a small built-in table is used.
Fingerprinting
A new model runs the probe set in the background — calls are made on your provider key. Progress shows on the model card; it usually takes a minute or two. The model then shows its overall quality, median and p95 latency, typical answer length, and a per-cluster quality chart. Open a model to see scores by category and its weakest probe answers.
| Status | Meaning |
|---|---|
| Probing | Being measured. Not routed yet. |
| Active | Taking part in routing. |
| Disabled | Kept but excluded from routing. |
| Failed | Every probe call errored — usually a wrong model id or key. Fix and re-probe. |
Capabilities
Probing also checks whether the model can call tools and honour a strict JSON response format. Both show as chips on the model card, and requests that need them are only routed to models that passed. You can override either in the model's edit dialog if you know better than the check.
Drift
Each re-probe compares the model's new quality with the previous run. A move beyond the threshold flags the card with a drift badge and emails your alert address — useful when a provider changes a model behind the same id.
Managed keys
If the platform operator publishes managed provider keys, they appear alongside your own providers and you can add models from them without holding an account with that provider. Usage on a managed key is charged in credits at cost plus a published markup; everything else — routing, caching, reports — works the same.
Shared catalogue
When a public model (a well-known provider host plus model id) has already been fingerprinted by another workspace, its fingerprint is reused: the model goes live instantly and no fingerprint fee is charged. Your own live feedback still personalises it for your workspace.
Re-probing
Models are re-probed automatically when the probe set changes. You can re-probe manually from the model card at any time, for example after a provider silently updates a model.
Choosing a good model mix
- Include at least one strong model — it sets the quality bar and handles hard prompts.
- Add one or two cheap, fast models; they take most of the easy traffic.
- Models from different families often have different strengths per task type, which gives the router more to work with.