Skip to main content
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:
1

Classify the request

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.
2

Assign the engineer to a cohort

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.
3

Resolve the target model

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”.

​
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.

​
Next steps

Models

Which models you can route to, and how each harness’s traffic is served.

Analytics & savings

Compare cohorts and see what each split saved.