[Proposal] Pass model list at runtime instead of construction time. Operate on a vector of models not just capable/efficient.

[grahamking]

Today the algorithms take their "capable" and "efficient" models at construction time in new. I propose changing that to pass them at runtime alongside the request, and to allow passing more than two.

1. run_stream gets a Vec<ModelId>. This is a list of available models ordered by accuracy, best first. Today that will usually be two models: [capable, efficient]. Some algos like random will be able take N models today. It shouldn't be too hard to map the score later into that list.

2. RoutingOutcome merges selected_model_id and fallback_models into a single Vec<ModelId> which are the models the algorithm recommends, best first. It is [selected_model_id, fallback_models..].

3. switchyard-server changes some TOML to replace e.g. capable = with a list of models.

The input vector of ModelId is the pareto frontier of models you have available ordered by accuracy. The other axis doesn't matter to the algos. You are saying "I am prepared to spend more X (time, money, energy) in exchange for more accuracy", as you move up the vector. input[0] is most accuracy and most X. input[input.len()-1] is least accuracy and least X. The algorithm doesn't need to know what X is.

Example today for two models:

• Input to algo is [openai/gpt-5.6-sol, openai/gpt-5.6-luna], being [capable, efficient].
• The task is difficult, so output is [openai/gpt-5.6-sol].

Example when we support more than two models:

• Input to algo is [anthropic/claude-opus-5, openai/gpt-5.6-sol, z-ai/glm-5.2, openai/gpt-5.6-luna]. Assuming that's your pareto curve, where as we go down the vector we lose accuracy and reduce cost.
• RoutingOutcome for a difficult task might be [openai/gpt-5.6-sol, anthropic/claude-opus-5]. Only those two can solve it, and Sol is cheaper.

The code changes are quite small. We move the models from new to run_stream for the input, and for the output we merge selected_model_id and fallback_models.

This maps nicely onto how LiteLLM plugins operate.