Semantic routers in LLM inference gateways select tools in the critical request path, where every millisecond of added latency compounds across millions of requests. We propose Outcome-Aware Tool Selection (OATS), which interpolates tool embeddings toward the centroid of queries where they historically succeed -- an offline process that adds no parameters, latency, or GPU cost at serving time. On MetaTool (199tools, 4,287queries), this improves NDCG@5 from 0.869 to 0.940; on ToolBench (2,413~APIs), from 0.834 to 0.848. We also evaluate two learned extensions: a 2,625-parameter MLP re-ranker and a 197K-parameter contrastive adapter. The MLP re-ranker hurts or matches baseline when outcome data is sparse relative to the tool set; the contrastive adapter provides comparable gains on MetaTool (NDCG@5: 0.931). All methods are evaluated on the same held-out 30% test split. The practical takeaway is to start with the zero-cost refinement and add learned components only when data density warrants it. All mechanisms run within single-digit millisecond CPU budgets.
Figures & tables
Method
Latency
Parameters
GPU
Viable at
(ms)
Required
10K rps?
BM25 (lexical)
∼ 7
0
No
✓
Static embedding
∼ 5
22M †
No ∗
✓
OATS-S1 (offline)
∼ 4
22M †
No ∗
✓
OATS-S2 (+ MLP)
∼ 5
22M + 2.6K
No ∗
✓
OATS-S3 (+ adapter)
∼ 5
22M + 197K
No ∗
✓
Table 1: Cost of tool selection mechanisms. Latency is per-request p50 on 2,413 tools (ToolBench). All methods run on CPU.
Figure 1: (a) LLM-based tool selection requires a GPU-bound orchestrator in the request path (500–2,000 ms). (b) OATS performs selection on CPU in the router (3–7 ms), with all learning offline. LLM serving latency is the same in both cases.
Figure 2: The OATS pipeline. Top: the online serving path runs on CPU in 3–7 ms. Bottom: offline learning from outcome logs. The core mechanism (Stage 1, dashed arrow) refines tool embeddings in the Tool DB at zero serving cost. Stages 2 and 3 are ablation mechanisms that optionally update the Re-Rank and Embed components respectively.
Figure 3: Geometry of OATS-S1 for the buildbetter example. The original embedding (blue circle) sits in a generic “SaaS” region, far from the test query (star). Positive training queries Q+ (teal dots) cluster around “meeting transcripts”; negative queries Q− (red dots) cluster around “call management.” The refinement pulls the tool embedding toward eˉ+ and away from eˉ− , placing the refined embedding (teal circle) closer to the test query. The description text never changes.
MetaTool
ToolBench
Method
Δ NDCG@5
AG/ms
Δ NDCG@5
AG/ms
SE (baseline)
—
—
—
—
Emb. refinement (core)
+0.071
∞
+0.014
∞
+ Contrastive (ablation B)
+0.062
∞
+0.008
∞
SE + Lexical
-0.053
—
+0.020
∞
Table 2: Cost efficiency: NDCG@5 gain per additional millisecond of p50 latency vs. SE baseline. ∞ means accuracy improved with no latency increase.
Method
Accuracy
Latency
Hardware
LLM-based (from published benchmarks)
ChatGPT (GPT-3.5) †
69.1%
∼ 1–3 s
API / GPU
Vicuna-7b †
73.5%
∼ 2–5 s
GPU
Vicuna-13b †
58.2%
∼ 3–8 s
GPU
LLaMA2-13b †
44.1%
∼ 2–5 s
GPU
Average (9 LLMs) †
∼ 57%
—
GPU
Table 3: Comparison with LLM-based tool selection on the MetaTool “similar choices” subtask (295 test queries). LLM results report Correct Selection Rate (CSR) from Huang et al. (2024) ; retrieval-based results report Recall@1 on the same subtask and split. Both metrics measure whether the top-selected tool is correct.
ToolBench
MetaTool
Method
R@1
R@3
R@5
NDCG@5
R@1
R@3
R@5
NDCG@5
Random
0.238
0.656
0.829
0.692
0.096
0.308
0.492
0.298
BM25
0.392
0.772
0.921
0.853
0.397
0.617
0.753
0.595
SE
0.382
0.765
0.897
0.834
0.716
0.904
0.958
0.869
SE + Lexical
0.388
0.783
0.919
0.854
0.640
0.860
0.927
0.816
OATS-S1
0.381
0.793
0.915
0.848
0.830
0.964
0.986
0.940
Table 4: Selection performance on ToolBench (2,413 tools, 180 test queries) and MetaTool (199 tools, 1,287 test queries). Same 30% test split for all methods. Best in bold , second underlined .
Serving
Added
ToolBench
MetaTool
params
latency
NDCG@5
Δ
NDCG@5
Δ
SE (baseline)
0
—
0.834
–
0.869
–
+ Emb. refinement (core)
0
0 ms
0.848
+0.014
0.940
+0.071
+ MLP re-ranker (ablation A)
2.6K
< 0.5 ms
0.823
-0.011
0.869
+0.000
+ Contrastive (ablation B)
197K
< 0.1 ms
0.841
+0.007
0.931
+0.062
Table 5: Ablation: incremental cost and contribution of each OATS component. Same 30% test split. Embedding refinement adds zero cost; the MLP re-ranker degrades ToolBench due to data sparsity ( < 0.15 examples/tool).
MetaTool
ToolBench
Method
p50 (ms)
p99 (ms)
p50 (ms)
p99 (ms)
GPU
SE (baseline)
3.66
6.47
4.59
9.83
No
OATS-S1
3.53
5.99
4.42
6.19
No
OATS-S2
3.92
6.91
5.04
16.38
No
OATS-S3
3.87
7.25
4.95
11.11
No
Table 6: Inference latency per request (CPU-only). All methods stay within single-digit millisecond p50.
Figure 5: Selection performance across all methods. Left: MetaTool. Right: ToolBench.
Appendix figures & tables2 assets
Supplementary material from the paper’s appendix.
Appendix
Tool
Description
buildbetter ⋆
Chat with the knowledge of all your calls in BuildBetter (Zoom, GMeet, Webex). Start for free @ BuildBetter.ai
QuiverQuantitative
Access data on congressional stock trading, lobbying, insider trading, and proposed legislation.
MixerBox_WebSearch
Search and summarize the web with our customized search engine powered by Google Search API!
brandfetch
Retrieve company and brand data including logos, colors, fonts, and other brand information.
C3_Glide
Get live aviation data for pilots. Ask questions about METARs, TAFs, NOTAMs…
locator
Displaying the current coordinates of the ISS and the names of the current crew.
Appendix
Table 7: Candidate tools for the example query, with original descriptions from MetaTool.
Query (truncated)
Correct
SE top-1
SE
S1
“Show me diverse and amusing memes…”
lsongai
PolishTool
0.287
0.450
“Discount codes for booking hotels or flights?”
Discount
TripTool
0.585
0.691
“Meaning of arigatou in Japanese?”
speak
ResearchFinder
0.077
0.149
Appendix
Table 8: Additional OATS-S1 corrections on MetaTool test queries. “SE sim” and “S1 sim” are cosine similarities to the correct tool before and after refinement. “SE top-1” is the wrong tool selected by static embedding.
Large language model routing selects models, tools, experts, or inference strategies to balance answer quality, cost, latency, and deployment constraints.
Tool-augmented LLM agents increasingly access the same tool type through multiple functionally equivalent providers, such as web-search APIs, retrievers, or LLM backends exposed behind a shared interface. This creates a provider-routing problem under runtime load: the router must choose among providers that differ in latency, reliability, and answer quality, often without gold labels at deployment time. We introduce LQM-ContextRoute, a contextual bandit router for same-function tool providers. Its key design is latency-quality matching: instead of letting low latency offset poor answers in an additive reward, the router ranks providers by expected answer quality per service cycle. It combines this capacity-aware score with query-specific quality estimation and LLM-as-judge feedback, allowing it to adapt online to both load changes and provider-quality differences. On the main web-search load benchmark, LQM-ContextRoute improves F1 by +2.18 pp over SW-UCB while staying on the latency-quality frontier. In a high-heterogeneity StrategyQA setting, LQM-ContextRoute avoids additive-reward collapse and improves accuracy by up to +18 pp over SW-UCB; on heterogeneous retriever pools, it improves NDCG by +2.91--+3.22 pp over SW-UCB. These results show that same-function tool routing benefits from treating latency as service capacity, especially when runtime pressure and provider-quality heterogeneity coexist.
Tool retrieval is a critical bottleneck for LLM-based agents operating over large, heterogeneous API ecosystems. Existing approaches face an inherent trade-off: semantic retrievers are fast but suffer from the semantic-functional gap, while execution-based validation improves precision at the cost of prohibitive latency. We propose Lookahead-R, a planning-based framework that reformulates tool retrieval as a resource-constrained sequential decision-making problem. At its core, Lookahead-R introduces a lightweight execution-aware surrogate world model that jointly predicts tool execution success, latency cost, and semantic utility---without invoking real APIs. This world model drives a cost-sensitive, uncertainty-guided Monte Carlo Tree Search that navigates the tool space under strict budget constraints. Evaluated on the large-scale ToolBench benchmark, Lookahead-R achieves a superior accuracy-efficiency trade-off across all test scenarios. On the most challenging I3 split, it attains an NDCG@5 of 91.40%, outperforming the state-of-the-art ToolGen (90.16%) by 1.24%. Ablation studies confirm that explicit latency modeling is the key discriminative signal for identifying high-quality tools under resource constraints.
Zongze Wu, Yani Guo, Runnan Li
Beijing University of Posts and Telecommunications Beijing, China
The rapid development of large language models, each with distinct capabilities and inference costs, raises a practical deployment question: given an incoming request, which model should handle it? We present OrcaRouter, a production-oriented LLM router that combines a LinUCB-based contextual bandit over lexical and sentence-embedding features with a hybrid offline-online learning protocol. Offline, OrcaRouter obtains full-information feedback by evaluating each candidate model on a curated set of routing prompts, yielding a reward matrix used to fit one ridge regressor per arm. At deployment time, it initializes from these parameters and can optionally continue learning from bandit feedback, updating only the selected model's arm after observing its reward. At the time of our RouterArena submission (May 20, 2026), OrcaRouter-Adaptive ranked second on the public RouterArena leaderboard with an arena score of 72.08, achieving 75.54% accuracy at a cost of USD 1.00 per 1,000 queries.