Context Router

The Context Router sits in front of the LLM step. Every turn goes through it first, and it decides how to answer: from cache, a small in-region model, a prepared response, or a full model call, with fallbacks when a model is slow or fails. It speaks the OpenAI API format, so any agent framework or voice platform with a custom LLM field can point at it. Call the API directly or configure it as the custom large language model in a supported agent integration. See the Context Router API reference for request and response fields.

​

Prerequisites

• An SLNG API key created in the project you call the Context Router from: open the project and go to Project Vault > SLNG API key. A key from the Call TTS/STT models API path is for calling models directly and cannot call the Context Router. The key works only in the project’s region. See Set up a project for your own code.
• A model for the router to answer with. Give it one of two ways:
  • Choose it in the project’s Think section. Requests made with the project’s key answer with the model you chose there, with nothing extra in the request. This is the only way for a voice platform integration, which lets you set just a base URL, an API key and a model. LLM keys you save on the dashboard’s BYOK page are offered there. See Bring your own key.
  • Send your models inline in the slng_config body field when you call the API from your own code. Nothing to register in advance, and the models in it answer that request. The project’s other settings still apply. See BYOK Context Router.

​

Configuration

Point your integration’s custom LLM at these values: The Custom LLM guide covers the OpenAI-compatible setup. Each platform guide has the exact steps for its dashboard or SDK: ElevenLabs, Vapi, Deepgram, LiveKit, and Pipecat.

​

Which configuration answers

The models and settings that answer a request depend on how it reaches the router:

• A key created in a project uses that project’s configuration, with the model chosen in the project’s Think section.
• An agent you deploy on SLNG uses its own configuration, with the model chosen in its Think section.

For how settings and an inline slng_config combine with it, see Which configuration answers.

​

Smart routing

Give the router two or more tiers of models, tier 1 the cheapest and tier 3 the most capable, and slng/auto picks a tier for each request: the cheapest one it expects to answer that turn well. Turns that may need a tool call, and turns that look demanding, go to your most capable tier. With one tier, that tier answers every turn. To use it, send two or more tiers inline in slng_config from your own code. See Smart routing for the configuration and how failover works.

​

Agent and session headers

The router requires two headers on every request so it can tie each turn to the right agent and call: Map them to your platform’s own agent and session values. In ElevenLabs they are the system__agent_id and system__conversation_id variables; in Vapi they are {{assistant.id}} and {{call.id}}; in code you pass a stable agent ID and the current session ID. Your platform guide lists the exact values. Values are at most 256 characters and cannot contain spaces, commas, pipes (|) or braces ({ }). An opaque ID or slug is always safe. A request missing either header, or carrying a malformed one, returns a 400 with code missing_client_id or invalid_client_id. When you call the API from your own code, you can send them as the body fields slng_agent_id and slng_session_id instead of headers. The body field wins if you send both.