Imagine you run a hospital switchboard. Most callers need a GP — fast, cheap, good enough. But some callers are having chest pain, and routing them to the GP because the GP is cheaper will kill someone. Today's LLM routers are that bad switchboard operator: they use one quality score for every call, so they cannot distinguish 'answer this coding question well' from 'refuse this jailbreak attempt.' SCRouter is a switchboard that listens to the first few words and decides whether this is a GP call or a cardiac call before picking the destination. The committed claim: existing LLM routers optimize a single quality metric for model selection and token-budget allocation. This fails on mixed workloads because utility (correct, helpful answers) and security (refusal of harmful or adversarial prompts) prefer different models and different budgets. SCRouter is the first router to decouple these two objectives, estimate them separately per model-budget pair, and blend them per query using a lightweight probe. The architecture is a multi-headed prediction pipeline. For each of 144 model-budget combinations (12 models × 12 token budgets), SCRouter first estimates the probability that a response finishes within the allocated budget. It then uses that probability to predict utility and security scores independently. A small classifier — the 'probe' — examines each incoming query and outputs a weighting between the two objectives. The router selects the model-budget action that maximizes the weighted score minus a cost penalty. This is fundamentally a constrained optimization approach over a discrete action space, closer to contextual bandits than to classifier cascades. The benchmark they built, SCRouterBench, is substantial: 38,869 queries spanning both utility tasks and nine security dimensions, each answered under all 144 model-budget combinations — yielding over 5.5 million response evaluations. They also include 2,753 out-of-domain queries to test generalization. The nine security dimensions are not just 'jailbreak yes/no' but span categories like prompt injection, over-refusal, and multi-turn manipulation. This is one of the more thorough routing benchmarks in the literature. Results: SCRouter improves over baselines by 13–29 points in-domain and 19–23 points out-of-domain on their composite metric. The out-of-domain gains are the more interesting signal — they suggest the probe genuinely learns to distinguish query types rather than memorizing templates. However, the baselines here are existing single-metric routers, not purpose-built security classifiers chained with utility routers. The gap between SCRouter and a well-engineered two-stage pipeline (detect-then-route) is not tested. The token-budget dimension is the quietly important contribution. Most routing papers only pick which model to call. SCRouter also decides how many tokens to grant — and the paper shows that security responses and utility responses have very different completion-length profiles. A refusal can be short; a helpful coding answer cannot. Granting a large budget to a model that should refuse wastes money; granting a small budget to a model that should explain truncates the answer. Joint model-and-budget selection is genuinely underexplored. The obvious next experiment is deploying SCRouter against adaptive adversaries — attackers who know the router exists and craft prompts specifically to fool the probe into misclassifying a security query as a utility query. The paper evaluates static attack sets. Whether the probe is robust to adversarial perturbation of the query itself is the load-bearing question for real deployment, and it is not addressed. Most likely explanation: it is a hard experiment that requires a separate red-teaming infrastructure, and the authors are saving it or ran out of time.
