alt Hacker NewsI think it really depends on what you're defining 'model routing' to include.
If you intend model routing to be 'route tasks to the best model for X task as optimized for some dimension Y', then of course ensuring availability of a model specialization on dimension Y is going to be a 'first principle' -- And perhaps this is the 'standard' definition folks would use for this.
However, my general definition of routing is inclusive of all routing that takes place in my execution pipeline, inclusive of agent/sub-agent schemes. Having frontierModelA leverage frontierModelB as a subagent gives me alloyed characteristics, and is an execution pattern that I'd route a general task.
In the above sense, you can consider this to be a difference between 'model routing' and 'model system routing', where the latter treats a multi-model execution workflow as a predefined model configuration one would route to in lieu of a single model (specialist or otherwise)
To maybe meet in the middle on this there is model optionality, and also configuration/system optionality that predefines a set of models and execution rules to follow
I'm guessing you mainly think of planning and maybe review when you say that Opus and GPT vary in their output. This is more of a qualitative judgment because it's difficult to write a planning benchmark. If you wanted planning to pass between both of these generalist models, role-model supports this via the pi-role-model extension for Pi that lets the coding agent send request metadata, define routing strategy to use and even model ID.
To implement it, you would make a rule for Pi to do another pass for any coder.planning task that it sends to the role-model router.
These types of personalizations are suited for implementation in the consumer application layer instead of in the router in my opinion.