Model routing and the Frontier Gateway
How Sparq chooses a model deployment for every call, and why it can refuse.
Agents and services never name a model. They ask for a model class, and the Frontier Gateway chooses a deployment from the model registry.
| Class | Typical use |
|---|---|
fast | Short, cheap steps: classification, routing, extraction |
standard | Most conversation and tool use |
reasoning | Multi-step planning and analysis |
code | Code generation and review |
embed | Embeddings for knowledge search |
rerank | Reranking search results |
vision | Images as input |
How a deployment is chosen
For each call the gateway starts with every deployment of the requested class and removes the ones that are not allowed, in this order:
- the workspace's deployment model and model allowlist;
- the client's compliance profile: providers, regions and provider retention;
- the data sensitivity of the run so far, which only ever rises;
- the capabilities the call needs.
It then ranks what is left by quality, cost and latency. Retries, a circuit breaker per deployment
and fallback all stay inside the filtered list. When the list is empty, the call fails with
no_compliant_model.
Every decision is recorded
The profile version, the rules applied, the candidates removed, and the deployment and region chosen
are recorded with every call. Read where one call was processed with
GET /v1/admin/usage/{usage_id}/location.
The registry
The registry lists deployments (provider, model, class, region, retention terms, context window, capabilities), routing rules and prices. Read it with:
curl "$SPARQ_API_URL/v1/admin/model-classes" -H "Authorization: Bearer $SPARQ_KEY"
curl "$SPARQ_API_URL/v1/admin/deployments" -H "Authorization: Bearer $SPARQ_KEY"
curl "$SPARQ_API_URL/v1/admin/routing-rules" -H "Authorization: Bearer $SPARQ_KEY"
curl "$SPARQ_API_URL/v1/admin/prices" -H "Authorization: Bearer $SPARQ_KEY"Provider support today: Azure OpenAI and any OpenAI-compatible endpoint, which includes self-hosted open-weight models.