> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slng.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 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](/api-reference/context-router/chat-completions)
for request and response fields.

## Prerequisites

* An SLNG API key. See
  [Create your API key](/guides/get-started/quickstart#create-your-api-key).
* A model for the router to answer with. Give it one of two ways:
  * **Register a BYOK LLM key** in the dashboard. The router then routes `slng/auto`
    to that model with nothing extra in the request. Use this for a voice platform
    integration, which only lets you set a base URL, an API key and a model. See
    [Bring your own key](/guides/models/bring-your-own-key).
  * **Send your configuration inline** in the `slng_config` body field when you call
    the API from your own code. Nothing to register in advance, and a request that
    carries it ignores any registered configuration. See
    [BYOK Context Router](/guides/execution-layer/llm/integration-guide#byok-context-router-slng_config).

## Configuration

Point your integration's custom LLM at these values:

| Setting  | Value                                                                                                                                                                             |
| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Base URL | The base URL SLNG gave you, for example `https://eu-west.context-router.slng.ai/v1`. Pick the region closest to your callers. See [Regions](/guides/execution-layer/llm/regions). |
| API key  | your SLNG API key, sent as `Authorization: Bearer <SLNG API key>`                                                                                                                 |
| Model    | `slng/auto` to let the router pick per turn, or the exact model name from your configuration to pin one. A pinned model has no failover to another entry.                         |

The [Custom LLM](/guides/integrate/custom) guide covers the OpenAI-compatible
setup. Each platform guide has the exact steps for its dashboard or SDK:
[ElevenLabs](/guides/integrate/elevenlabs), [Vapi](/guides/integrate/vapi),
[Deepgram](/guides/integrate/deepgram), [LiveKit](/guides/integrate/livekit),
and [Pipecat](/guides/integrate/pipecat).

## Agent and session headers

The router **requires** two headers on every request so it can tie each turn to the right agent and call:

| Header              | Identifies                     |
| ------------------- | ------------------------------ |
| `X-Slng-Agent-Id`   | The agent handling the call    |
| `X-Slng-Session-Id` | The individual call or session |

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, send them as the
body fields `slng_agent_id` and `slng_session_id` instead.

<Note>
  The agent ID also scopes the response cache, so answers cached for one agent ID
  are never served to another. When you change an agent's prompt in a meaningful
  way, give it a fresh agent ID, for example by adding a version suffix. Otherwise
  answers produced under the old prompt stay in scope for the new one.
</Note>