Models & Providers

Aura Workshop is model-agnostic. Bring your own keys for 16 built-in providers and aggregators, plus any OpenAI-compatible endpoint — point a custom provider at any OpenAI-compatible server you run yourself, set sampling parameters per model, and let Aura Routing 2.0 pick the right model for each task — with a circuit breaker, load balancing, conditional rules, a semantic cache, and spend-limit fallback layered on top.

Cloud providers (direct API)

Aura Workshop connects directly to each provider's own API. The provider is auto-detected from the model slug (org/model), so in most cases you only need to paste an API key and pick a model. Each provider appears as an expandable card on the Models page.

Authentication

Keys are held per provider, so one install can carry several at once (provider_keys), with optional per-provider base-URL overrides (provider_urls) and per-model key selection (key_overrides) when a single model should bill to a specific plan.

Configuring a cloud provider

1. Open the Models page from the sidebar.
2. Click a provider card to expand it.
3. Paste your API key. Aura queries the provider's /models endpoint and caches the result (~24h TTL), so the model dropdown stays current without manual entry.
4. Select a model. Adjust sampling parameters if needed (see Model parameters).
5. Save. The model is immediately available in the quick model switcher for all new tasks.

Aggregator services

Aggregators expose many models behind a single key. All speak an OpenAI-compatible API with Bearer-token auth, so adding one key unlocks a wide catalog. Aura auto-detects the underlying vendor from the model slug's prefix.

Cloud tool integrations (Slack, Gmail, GitHub, Notion and 100+ more) are handled separately through Composio and MCP — see Integrations.

Custom & local providers

Any endpoint that speaks the OpenAI API format can be added as a custom provider. This is how you run models on your own hardware: stand up a local OpenAI-compatible server and point a custom provider at it.

Adding a custom provider

• Name — a human-readable label for the provider.
• Base URL — the API base, e.g. http://localhost:11434/v1 (Ollama) or http://localhost:1234/v1 (LM Studio).
• API key — a bearer key if the server requires one; local servers often need none.
• API format — OpenAI, Anthropic, Google, or generic OpenAI-compatible.
• Context window — set it so context compaction triggers at the right point for the model.
• Test connection — verify the endpoint is reachable before saving.

A custom provider stores its own base_url and (optional) key. Once saved, its models sit alongside cloud models in the quick switcher and can back teams and routing tiers like any other provider.

Common local servers

Model parameters

Sampling parameters shape a model's output. The values below are the global defaults; a per-model override in model_params always wins over them, and is the source Aura Routing, fallback, and hot-swap read to pull the correct settings for whatever model they switch to.

Per-model overrides

model_params is a map of modelId → {temperature, topP, topK, maxTokens, …}, seeded from the built-in model presets and updated whenever you override a value on the Models page. Notable built-in defaults: Gemma (temp 1.0, top_p 0.95, top_k 64) and Qwen3 (temp 0.6). Keeping overrides per model means routing to a different model automatically carries that model's correct sampling settings.

Thinking-mode wiring

A single thinking_level maps to whatever each provider's API expects. Budget tokens are derived from the level: low = 1024, medium = 4096, high = 16384.

Aura Routing 2.0

Aura Routing automatically picks a cost-appropriate model for each task. A 23-dimension scorer classifies every request into a tier and resolves a model from that tier, and five phases layer on top of the scorer. Everything runs locally and in-DB, and every decision is written to a routing decision log that powers the Routing Debug Log UI.

Enable it in Settings → Routing (routing_enabled). When disabled, every task uses the globally selected model.

Tiers

Four tiers, each with its own model and boundary score, are configured in routing_config:

The five phases

A request first checks conditional rules; on no match it falls through to the scorer, then load balancing, the health breaker, the semantic cache, and finally the guardrails registry before the provider call.

Routing analytics

The routing view reports tasks per tier, actual cost versus the hypothetical cost of running everything on the most capable model, and the resulting dollar and percentage savings — updated in real time. Reset from the billing reset control.

Spend limits & fallback

Spend limits and the fallback chain are their own tables, managed under Settings → Billing (or via GET/PUT /api/billing/limits and /api/billing/fallback-order).

• Spend limits — per-provider {daily_limit_usd, monthly_limit_usd, enabled}. When the current provider is over budget, the resolver walks the fallback chain until it finds a provider that is in budget and reachable.
• Fallback order — priority-ordered {provider, model, base_url, api_key_ref} rows that define where routing spills over.

For every knob referenced here — routing config, semantic-cache keys, spend limits, provider keys and URL overrides — see the full reference in Settings.