← /blog
· ACE Engineering#llm-router #scorecard #routing #cost #classifier #latency #eval #managed-api-stack

LLM Router v1 Scorecard: Quantitative Benchmark of Model Tiering and Cost Savings

The v1 baseline for ACE's request router: two trained heads over a shared embedder plus a priced model catalog. Measured at 0.975 held-out macro-F1 on category, sub-10ms median classification latency on CPU, and an 86.7% cost reduction over a single-flagship baseline on a 798-prompt eval.

Out-of-Distribution Update (2026-08-08). The metrics in this post reflect in-distribution performance on a held-out split of the classifier's seed training corpus (0.975 macro-F1). To evaluate real-world generalization under distribution shift, we conducted an 800-prompt benchmark across 8 disjoint public datasets. For the latest Router v2 performance metrics, zero under-service guarantees, and feature fusion architecture, see LLM Router v2: A Scorecard.

ACE's router decides, per request, which model to serve. v1 uses three inputs and makes no call to a language model on the hot path:

  1. a query-category classifier — what kind of work the request is,
  2. a separate complexity scorer — how hard the instance is, and
  3. the Model Market Matrix — the per-offering price and capability score for each candidate model.

The first two are trained in-house: a multinomial logistic-regression category head and a ridge-regression complexity scorer, both running numpy-only inference over a shared 384-dimension bge-small sentence embedder, in-process, on CPU, with no network call and no external LLM in the loop.

The routing decision: rank every model in the catalog by expected dollars, keep the ones whose capability at the request's category clears a complexity-dependent quality floor and that carry direct evidence for that category, and serve the cheapest one reachable. If nothing qualifies, the request stays on the default model. A structural check on the response triggers a one-time retry against the strongest available model when the cheap answer fails.

Everything here is a v1 baseline — the first fully measured version of these heads. The figures come from the seed corpora and the router's own code paths; no production traffic is involved.


Scorecard 1 — the category classifier

Held-out performance and a full-corpus regression pass (798 labeled prompts across 8 categories):

Metric?Value?
Held-out macro-F1 (in-distribution — see update above) 0.975
Full-corpus agreement (train+test, not held-out) 792 / 798 = 0.9925
Decisions made by the trained head 773 / 798 = 96.9%
Decisions made by a structural rule 20 / 798 = 2.5%
Decisions made by the lexical fallback 5 / 798 = 0.6%

Per-category full-corpus accuracy:

Category?n?correct?acc?
code 100 100 1.000
extraction 100 100 1.000
reasoning 100 100 1.000
summarization 100 100 1.000
chat 99 98 0.990
math 100 99 0.990
translation 99 98 0.990
qa 100 97 0.970

The residual error is concentrated in one adjacency: 3 of the 6 misses are qa → chat, categories that route to similar tiers, so the dollar impact of the confusion is small. Structural facts (image attached, JSON response requested, input length) are read as ground truth and can override the learned head; a lexical rule is the floor under both.

Scorecard 2 — routing savings

Setup: the 798-prompt seed corpus (real benchmark prompts, 8 categories). For each prompt the router's own classifier and complexity scorer assign (category, complexity); the input leg is priced with the router's token estimator and the output leg with the catalog's per-category output priors.

  • Baseline — every request served by one flagship, claude-opus-4-8 (5/5 /25 per 1M).
  • Routed — cheapest catalog model with direct capability evidence that clears the complexity floor; otherwise the flagship is retained.
Corpus rows 798
Routed to a cheaper model 603 (75.6%)
Retained on the flagship 195 (24.4%)
Baseline cost $7.4317
Routed cost $0.9864
Reduction (cross-vendor; ~80% is the within-vendor ceiling) 86.7%

By category — the destinations, and the two categories the router does not move:

Category?n?moved?baseline $?routed $?reduction?routed to?
chat 103 103 0.4985 0.0114 97.7% deepseek-v4-base
code 101 101 1.5257 0.0537 96.5% deepseek-v4-pro
extraction 100 100 0.2021 0.0081 96.0% deepseek-v4-pro
math 99 99 1.2599 0.0287 97.7% deepseek-v4-base
reasoning 100 100 2.8902 0.2545 91.2% deepseek-r1
summarization 100 100 0.4433 0.0181 95.9% deepseek-v4-pro
qa 97 0 0.2972 0.2972 0.0% (held on flagship)
translation 98 0 0.3147 0.3147 0.0% (held on flagship)

The two 0.0% rows are the evidence requirement in numbers. For qa no cheaper model carries a capability score, and for translation no model in the catalog carries one at all, so both are held on the flagship rather than routed on a borrowed general-purpose score. The alternative was measured: allowing a general "chat" score to satisfy a hard floor collapses the policy to "always cheapest".

Scorecard 3 — classification latency

The router adds one classification pass in front of every request. The full pass — embed with bge-small, category head, complexity head — timed over all 798 prompts, single-threaded on CPU, steady-state after warmup:

Percentile?Latency?
p50 8.9 ms
mean 10.9 ms
p90 19.1 ms
p95 20.2 ms
p99 23.6 ms
max 25.8 ms

The embedding forward pass dominates the budget; the two regression heads are numpy dot products and contribute microseconds. This measurement is single-thread CPU with no batching, no GPU, and no ONNX thread tuning — a floor rather than a ceiling.

Scorecard 4 — decision robustness

Two structural checks on whether the policy's decisions are stable, independent of its dollar totals:

  • Output-length invariance. Across all 55 model pairs in the current price set, one model is cheaper on both the input and output leg in 55 / 55 cases. No pair reverses ranking as the output grows, so the hand-estimated output priors move the reported dollar figure but not which model is selected.
  • Catalog vs. the earlier routing table. The models the previous static routing matrix could rank and the models on the 2026-07 market table have an intersection of 0 (the single prefix match, gpt-5gpt-5.6-sol, is spurious). The router that predates the catalog was ranking a set of models disjoint from what the market offers.

What the baseline establishes

  • The classifier's 0.975 held-out macro-F1 is a direct measurement. The residual error is one low-cost adjacency (qa → chat).
  • The savings figure is a projection on benchmark prompts, not measured production savings. The corpus carries no completion tokens, so output length is a prior, and prompt lengths are short (p50 ≈ 38 tokens) relative to real traffic. The magnitude also depends on the baseline: "everything to a 5/5/25 flagship" is a high starting point, and a deployment already on a mid-tier default would see a smaller headline. The category-level structure — which work moves, which is held — does not depend on the output priors.
  • Latency is a floor, not a ceiling. Sub-10ms median on single-thread CPU is measured without batching, quantization, or thread tuning.
  • The cheap destinations' capability scores are operator-supplied and unverified. Promoting them to cited benchmark evidence is in progress and changes which routes the evidence gate allows.

The classifier accuracy and the latency are measurements; the savings figure is a projection with its assumptions stated above.


References

  1. L. Chen, M. Zaharia, J. Zou. FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. 2023. arXiv:2305.05176
  2. I. Ong, A. Almahairi, V. Wu, et al. (LMSYS). RouteLLM: Learning to Route LLMs with Preference Data. 2024. arXiv:2406.18665
  3. D. Ding, A. Mallick, C. Wang, et al. Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing. ICLR 2024. arXiv:2404.14618

Sign up to ACE now