Repository navigation
[Roadmap] Switchyard v0.4.0 (November 2026) #1026
Description
Target release: ~ Late Nov 2026
Status: In development
Last updated: October 16, 2026
Switchyard v0.4.0 is focused on making routing results easier to reproduce and expanding how routing strategies can be configured and combined.
Note
This roadmap reflects our current plans and is intended to be directional, not a firm commitment. Scope and timing may change.
Reproducible evaluation configurations
We plan to make it easier for users to reproduce and evaluate Switchyard configurations by publishing specific details of tested configurations.
- Publish the versioned Switchyard configuration used for evaluation.
- Document the benchmark, model details, and harness versions needed to reproduce results.
- Provide a tested evaluation playbook for Terminal-Bench 4.0 and SWE-Atlas-QnA that works from a clean environment.
- Report task-success, cost, and latency results, along with relevant limitations and deviations.
The goal is to give users a practical path from a published configuration to a comparable evaluation result.
Composable routing strategies
Today, different Switchyard routing strategies make decisions using different signals available before, during, or after execution. In v0.4.0, we plan to make these strategies easier to combine.
- Introduce a configurable routing surface that composes multiple existing routing strategies.
- Support decisions at different points in a request or agent session, including initial model selection, execution-time escalation, and recovery.
- Document combined configurations and provide validated examples.
- Benchmark the combined strategies against individual routing approaches and fixed-model baselines.
This work is intended to let users tailor routing behavior to their workload instead of selecting a single isolated algorithm.
Plan/Execute routing
A new Plan/Execute strategy for agent workloads that benefit from separating higher-level planning from execution.
- Route planning and execution stages independently.
- Improve handoffs between planning and execution.
- Support configurable tool semantics for agent frameworks with custom tools.
- Publish a validated example configuration and evaluation results.
Repeated planning and execution through delegated subagents remains experimental and is not part of the committed v0.4.0 experience.
Adaptive reasoning routing
Add bounded routing across reasoning-effort levels.
- Select both a model target and an appropriate reasoning level.
- Compare adaptive reasoning against fixed-effort baselines under matched conditions.
- Report task outcomes, resource usage, and latency.
- Document configuration behavior, boundaries, and known limitations.
This is intended to help workloads use additional reasoning when it is valuable without applying the highest reasoning effort to every request.
Jev and optional decision-model classification
Add Jev as the initial non-LLM decision-model integration through TypeSafe’s System One API.
- Preserve existing routing policies and fallback behavior.
- Document when the classifier is invoked and how it affects routing.
- Publish benchmark results for the supported configuration.
Existing classifier configurations will remain available; adopting Jev will be optional.
Privacy-constrained routing
We are working on an initial privacy-routing capability that limits requests to eligible targets based on an explicit restriction signal.
- Allow callers or an upstream policy layer to provide a routing restriction.
- Limit routing to model targets configured as eligible for that restriction.
- Define safe behavior when no eligible target is available.
- Document the configuration boundary and benchmark the initial approach.
The initial scope focuses on enforcing a supplied restriction. Automatic detection or classification of sensitive request content is not part of the committed v0.4.0 scope.
Initial Dynamo interoperability
We plan to publish an initial, validated path for using Switchyard together with NVIDIA Dynamo.
The v0.4.0 scope focuses on interoperability and defining the boundary between capability-based routing and infrastructure-aware serving. Broader routing based on live load, topology, or KV-cache signals remains future work.
Feedback
We would particularly value feedback from gateway developers, agent-platform teams, and other Switchyard integrators:
- Which new routing capabilities from the 0.4.0 plan seem most helpful for your use of Switchyard?
- What questions do you have about configuration or compatibility information that would help you get more out of Switchyard?
- Which benchmarks or types of agent workloads would you like to see represented in future evaluation results and guidance from NVIDIA?
Please comment on this issue or open a feature request in the Switchyard repository.
Activity