The first wave of model routing solved a small, clear problem. You had a prompt, and you had a few models to choose from. Some prompts were simple and could go to a cheaper model; some were hard and needed a stronger one. A router looked at the prompt, guessed how difficult it was, and picked. For a chatbot answering one message at a time, that was a reasonable thing to do.
The trouble is that the work has moved on. The prompt is no longer the unit. An agent finishing a task runs through many steps, and those steps are not independent. Step twenty depends on what happened at step three. The context accumulates, the same history rides along on every call, and the cost of the task is the sum of all of it. Choosing a model one prompt at a time optimises a piece of the problem while most of the cost sits in the session as a whole.
The session is the thing to route
Look at a session end to end and a different picture appears. Some steps are hard in a way that matters: the ones that decide what to do next, or that write the tricky part of the answer. Many others are routine: reformatting a result, following a fixed instruction, taking a small step in a plan that is already set. A per-prompt router has no way to tell these apart across a long run, because it never sees the run. It sees a prompt, in isolation, again and again.
Routing the session means deciding, step by step, which model each step needs, with the shape of the whole task in view. The hard steps get the model that can do them well. The routine steps go somewhere cheaper, and because they were routine, the answer holds. And because so much of a session is context sent more than once, the parts that repeat need not be paid for at full price every time. None of that is visible from a single prompt. All of it matters to the bill.
Cost and quality sit on a frontier
Once you route the whole session, cost and quality stop being a single dial. They become a frontier: a set of options, each one the best quality available at a given cost, and the best cost available at a given quality. Push for maximum quality and you sit at one end. Push for lowest cost and you sit at the other. In between is a range of points, and every one of them is a real, achievable way to run the same work.
What matters is that you get to choose where on that frontier you sit, and the right answer is not the same for everyone. A team shipping code to production may want quality held as high as it will go, and treat the saving as whatever comes for free at that level. A team running a high-volume assistant may accept a small, measured give in quality for a large cut in cost. The point is that this is a decision you make on purpose, not one made for you by whatever the default model happens to be.
Choosing the operating point
We give that choice a few plain settings. You pick an operating point that leans toward saving, stays balanced, or holds quality at the top, and you set a budget and a quality floor around it. The router works inside those. It routes each session to sit at the point you asked for, keeps the cost under the ceiling you set, and never drops below the quality standard you named. The frontier you choose from is drawn from your own traffic, so the trade-offs you are weighing are the ones your product faces.
Cost is the first thing this makes controllable, and it is the reason most teams start here. The same view of the whole session, and the same freedom to choose an operating point, is what lets you manage inference deliberately as the work keeps growing. One model per prompt was the right tool when the work was a message. The work is a session now, and Moji Router routes the session.