Session Aware
Overview
session_aware selects one model from a decision's modelRefs while respecting agentic multi-turn context. It wraps a base selector such as hybrid, then applies a router-owned stay-vs-switch policy for sessions, tool loops, idle timeout, handoff cost, switch history, confidence-gated remaining-turn priors, and prefix-cache cost.
Use it when clients send a stable x-session-id header and you want long-running agent sessions to avoid unnecessary model churn. Provider-managed continuation state, such as a Response API previous_response_id, is treated as non-portable state and hard-locks the session to the previous physical model. Router memory stores routing facts only, so model selection can reason about continuity without becoming application memory.
It aligns to config/algorithm/selection/session-aware.yaml.
Scope Boundary
session_aware is an Agentic Context Routing policy for model selection. It chooses one model from the matched decision's modelRefs and emits router evidence for that decision. It does not choose upstream endpoints or override Envoy load balancing inside a selected cluster. Endpoint membership, locality, and load-balancing behavior stay in the Envoy or Kubernetes configuration that serves the selected model.
Key Advantages
- Preserves KV/prefix-cache locality across long-horizon agent sessions.
- Hard-locks active tool loops to avoid mid-loop model changes.
- Lets idle sessions reselect after the cache is likely cold.
- Uses replay-derived remaining-turn priors to be stricter for task families that usually continue for many turns.
- Scales switch cost up for expensive/frontier model checkouts.
- Records
session_policyin router replay for audit, experiments, and paper/blog analysis.
What Problem Does It Solve?
Single-turn routers often pick the best model for the latest message only. In long-running agent loops that can churn models between tool calls, waste prefix-cache locality, and make frontier model checkouts unnecessarily expensive. session_aware makes the router aware of session continuity before it decides whether a switch is worth the cost.
When to Use
- Clients set a stable
x-session-idheader or use Response API conversation IDs. - The route serves agents that call tools over multiple turns.
- Candidate models have materially different costs or prefix-cache behavior.
- You want replayable policy traces for experiments and release validation.