AI Providers — Technical Reference
Reference for how bring-your-own-model behaves at runtime: supported providers, how a selection resolves, billing, degradation and limits.
Supported providers
| Provider | Notes |
|---|---|
| OpenAI | |
| Anthropic | Runs over Anthropic's native interface (not an OpenAI-compatibility shim) |
| Google Gemini | |
| Azure OpenAI | |
| Fireworks AI | |
| DeepInfra | |
| OpenRouter | |
| Custom | Any OpenAI-compatible chat-completions service; requires the service's base URL |
Each provider row holds its own key, an enabled-model list, and a default model. Up to 10 providers per account.
Model resolution
A conversation resolves its model in this order of precedence:
- Explicit selection — the model menu in that conversation.
- Account default — applies only to new conversations on surfaces that support it; existing conversations keep their model.
- The surface's Nirvai default — always available, always last.
For saved agents the model is stored on the agent itself and always resolves against the agent owner's providers — a teammate running a shared agent, or a customer messaging it on a channel, uses the owner's account, never their own.
Where it applies
| Surface | Own model supported |
|---|---|
| Main chat (Work) | ✅ |
| Custom agents — web chat and all channels (WhatsApp, Telegram, Slack, Discord, Instagram, Messenger, chatbot) | ✅ via the agent's model |
| Research | ✅ the lead researcher; background sub-searches run on Nirvai models |
| Setup assistants (tools, credentials, databases, memories) | ✅ |
| Automations steps, Live Apps, Help | Nirvai models |
| Exported API with a strict answer format (JSON schema) | Nirvai models |
Billing
- A reply generated on your model records 0 credits. Usage (tokens in/out, model, provider) is still tracked and visible in the Analytics tab, alongside an estimated credits figure — what the same reply would have cost on Nirvai models.
- Replies on Nirvai models bill credits exactly as before, including any fallback replies (see below).
- Deleting a provider keeps its historical usage records.
Degradation rules
The design goal: a broken key degrades a conversation, never breaks it.
| Situation | Behavior |
|---|---|
| Key revoked / out of funds / provider unreachable | The turn runs on the surface's Nirvai default and bills credits; the provider card flips to Needs attention |
| Model disabled or removed from the provider row | Same fallback |
| Provider deleted while an agent still points at it | The agent runs Nirvai models; reassigning agents is offered at delete time |
| Account default points to something unavailable | New chats quietly start on Nirvai models; the AI Providers page flags the stale default |
Repeated failures are tracked per provider (consecutive-failure count and a first-failure timestamp) so a failing key is surfaced once, not on every message.
Security
- Keys are encrypted at rest and never returned by any read — only a short prefix and the last 4 characters are stored in plain text for display.
- The decrypted key exists only in memory for the duration of a reply; it is never logged and never included in analytics.
- Validation messages use a fixed vocabulary — provider error bodies are never stored verbatim.
Limits
| Limit | Value |
|---|---|
| Providers per account | 10 |
| Request timeout on your model | 90 s (longer than Nirvai's own, to accommodate slower gateways) |
| Test message | one minimal "hi" completion per save / manual test |