One name in front of every model you run.

A route is a decision rather than a model. A client asks for dynamic/support, and rules you set decide which model answers that particular call.

A decision drawn, not coded
A route is a graph of a few steps: a condition, a split, a ceiling, a model, a refusal. It is stored as data and checked before it is saved, so it is a form somebody fills in rather than an expression language to learn.
Conditions on what the call already carries
The key, the person, the stated purpose, the model asked for, how long the prompt is, how long the last message is, whether there are pictures, and how many calls a second this key, this person and this organization are making. Nothing that only the answer could tell you.
Ceilings that steer instead of refusing
A rate limit and a budget limit each have two ways out: within and exceeded. Traffic over the ceiling goes to the cheaper model, or to a refusal written into the route, rather than spending what nobody planned to spend.
A fallback, and a way to try one
Every model in a route has a branch for the case where it fails, so a provider refusing does not end the call. And dynamic/beta/name runs the graph still being edited against real traffic from a staging client, before anybody puts it in front of everybody.

The answer names the route it took and the path through it, in its own headers
Only models this organization has enabled can be placed in a route
A refusal comes back in the standard error shape, with the status, sentence and code the author chose
Every deployment is a version, and an earlier one can be restored
A route taken off the model lists keeps answering the integrations already calling it

What your team gets

Five parts, one account, one set of permissions.

Point a staging client at the draft address, read the path the answer reports, then deploy.