Model router
The Model router decides which model serves each request. By default everything runs on platform-hosted, EU-resident models. The router lets you choose which models your organisation can use, give them friendly names with automatic fallback, bring your own provider keys, and — once you have accepted the risk — route to external providers outside the EU.
You will find it under Services > Model router.
EU by default
Out of the box the router only allows EU-sovereign models: requests stay on infrastructure inside the EU. External providers (OpenAI, Anthropic, Google, Mistral) sit outside the EU and are blocked until your organisation explicitly accepts non-compliant routing. That acceptance is recorded once, with the identity and timestamp of the admin who made it, and can be revoked at any time.
Even after acceptance, an external call only proceeds when the request is protected: either the PII firewall is on for that request, or the request carries a valid compliance acknowledgement. The egress guard enforces this in code and fails closed — if neither condition holds, the call is refused rather than sent.
Models
The Models tab lists the model catalogue with the credit cost per 1,000 input and output tokens for each. Use it to enable or disable individual models for your organisation. A disabled model is rejected for your tenant even though it exists in the catalogue. You can sort the table by model, provider, or input/output price to compare options.
Routing aliases
A routing alias is a name you invent that maps to one or more real models. You send the alias as the model in your request; the router resolves it to the first target, and if that target is unavailable it falls back to the next one in order.
Aliases let you keep a stable name in your code — for example fast or default — and change what it points to here without redeploying. They also give you resilience: a primary model with an external fallback (or vice versa) keeps requests flowing if one provider has an outage.
Provider keys (bring your own key)
By default, calls to external providers use the platform's relationship with that provider. On the Provider keys tab you can instead store your own API key for a provider. When a key is present, requests to that provider are billed to your account with them rather than brokered through the platform.
Keys are encrypted at rest and never shown again after you save them — only the last few characters are displayed so you can tell which key is stored.
Compatibility
The Compatibility tab tunes how the router handles requests that do not map cleanly onto every provider:
- Unsupported parameters — when a request uses an OpenAI parameter a target provider does not support, choose lenient (drop the unsupported parameter and proceed) or strict (reject the request so nothing is silently ignored).
- Firewall tool content — when on, the PII firewall also scans the content of tool and function-call messages, not just ordinary message text, before anything leaves the platform.
Good to know
External routing is never on by default. It requires a recorded acceptance, and each external call still needs the firewall or a valid acknowledgement. The opt-out is deliberate and auditable.
Pseudonymised data is still personal data. Routing a firewalled request to a non-EU provider reduces exposure but does not remove your GDPR obligations. Review the warning shown when you accept non-compliant routing.
Routing decisions are audited. The model chosen, the region it ran in, and whether egress was allowed or blocked are written to the audit log for every request.