> ## Documentation Index > Fetch the complete documentation index at: https://docs.valarhq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Model routing > How Valar decides which model serves each coding request Routing decides which model serves each request an engineer's harness makes. You set it once per coding key, and it applies to everyone using that key. ## How a request is routed Every request goes through three steps in the gateway: The harness asks for an Opus-, Sonnet-, Haiku-, or Fable-class model, and Valar sorts the request into one of those four **aliases**. Anything that matches none of them is treated as **Sonnet**, the working tier for most coding traffic. Using the client id on the request (most harnesses send it as an `X-Valar-Client-Id` header; Cursor, which cannot set headers, rides it as a token suffix), Valar assigns the engineer to one **cohort** in the key's split. The assignment is deterministic and sticky, so the same engineer always lands in the same cohort for a given key and split. Their experience stays consistent from one request to the next. The cohort pins each alias to a target model. Valar looks up the target for the request's alias and routes there. For example, an engineer whose cohort maps Sonnet to GLM-5.2 has their Sonnet-class calls served by GLM-5.2. If a key's routing cannot be read, ValarCode falls back to the frontier Claude tiers instead of failing the request, so a misconfiguration never blocks an engineer. ## Auto mode vs. Manual mode ValarCode has two ways to decide the split. Valar picks the target model for you. A new coding key starts on Auto, so routing works before you configure anything. Auto runs a **Balanced** objective today. **Max savings** and **Max quality** appear in the dashboard marked "Soon". You choose which model serves each request class. In the routing editor you pick a target model for Opus, Sonnet, Haiku, and Fable from a dropdown of available models. Valar applies that selection to matching requests. A manual mapping is available for Claude Code today; the other harnesses route on Auto. A single selection is all you need to get started. To run more than one selection at once, split traffic across cohorts and give each cohort its own model choices (see [Cohorts](#cohorts)). Saving asks for a reason, which goes into an audited change log, and each save is versioned so you keep a full history of what changed and why. Manual suits you when you want direct control over which model handles each class: running a specific A/B, holding a known baseline, or rolling a model out on your own schedule. ## Editing routing Routing is set **per coding key**, in the dashboard under **ValarCode → Routing**: 1. Pick the coding key. 2. Choose the target model for each class (Opus, Sonnet, Haiku, Fable). To run more than one selection at once, split traffic across cohorts and set models per cohort. 3. Enter a reason and save. If you use multiple cohorts, their shares have to total 100%. Changes are versioned and take effect for new requests once you save. Because assignment is sticky to the current split, changing a cohort's share can move some engineers to a different cohort. That is expected when you rebalance an experiment. ## Cohorts A **cohort** is one arm of a split. Each cohort has: * a **share**, the percentage of engineers it covers, and * a **target model for each alias**: Opus, Sonnet, Haiku, and Fable. A split holds 1 to 5 cohorts, and their shares add up to 100%. Engineers are spread across cohorts by the sticky assignment above, so a cohort set to 30% gets about 30% of your engineers and keeps them there rather than re-rolling on every request. That is what makes a controlled comparison possible. Put 70% of engineers on a cohort that targets Claude and 30% on an open-weight cohort, then compare cost and outcomes between the two in [Analytics](/valarcode/analytics). ## Next steps Which models you can route to, and how each harness's traffic is served. Compare cohorts and see what each split saved.