guides
Route a workload
The core loop of the product: shift a small slice of one call site's live traffic onto a managed model, compare the evidence, and ratchet up — with rollback one field away at every step. No application deploys involved.
Before you start
- The call site is isolated as a workload sending
x-understudy-workload— see Scope with projects. - The workload has live traffic and (ideally) existing captures, so you have a baseline to compare against.
1 — Set the route at a small slice
On the dashboard, open the project's Routing page, pick a catalog model for the workload, and set the traffic slice to 5% before you apply. Capture turns on automatically when a route is set — routed traffic is the evidence you're here for.
2 — Watch the two arms
The deterministic split means the same workload now produces two comparable capture streams. In the project's capture stream, each entry's detail shows requested model vs served model and the resolved route. From your own logs, x-understudy-route distinguishes understudy arm responses from primary ones — wire it into whatever quality signal you already track.
3 — Ratchet, pause, or clear
- Confidence grows → raise the percentage: 5 → 25 → 50 → 100. Each change is one Apply on the Routing page, effective on new requests immediately.
- Something looks off → set traffic to 0%. All traffic returns to your primary provider while the route pointer (and its capture history) stays for the next attempt.
- Done experimenting → select passthrough to clear the route entirely.
What failure looks like
If the routed model errors upstream, your users don't see it: the request falls back to your primary provider and the response reports x-understudy-route: fallback. A rising fallback rate is your signal to pause the route and read the arm's captures — not an outage.