The "low" setting turning reasoning on for deepseek-3.2 is the row I'd have walked straight into. We set a reasoning effort per role when we start a run, and I had read that scale as one-directional the whole time. Do you keep that switch in a per-model table by hand, or re-probe it when a new model id shows up?
The minimax-m2.5 case is the one worth flagging hardest for anyone building a router across a model pool like this. A 200 that silently does nothing is worse than a 400 -- a 400 fails loud, a silent no-op just eats a budget you thought you'd capped. Feels like the only safe pattern for a heterogeneous pool is a canary: run one known reasoning-sensitive prompt per model/param combo at setup and check the measured token count actually moved, rather than trusting the response code to mean the parameter took.
The minimax-m2.5 case is the one that would bite you in prod - it accepts every switch, returns 200, and just ignores all of them, so nothing tells you it did nothing. We got burned by something close: a router model silently choosing different temperature/top_p depending on which backend it picked that request, and we only caught it because a batch of outputs came back oddly uniform. Three-sample runs would've missed that too, same as your minimax retraction. Did you check whether the router: targets report reasoning_tokens more honestly because they're just passing through the real model's usage object, or was that just how your sample landed?