Pith. sign in

REVIEW 4 major objections 6 minor 28 references

ORI: O Routing Intelligence

T0 review · 4 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read ORI claims a cluster-dominance router lets a pool of LLMs beat every single member, reporting up to 2.7-point gains on MMLU and 1.8 on MuSR.

desk verdict A simple embedding-cluster-router whose headline MMLU score is not supported by its own routing rule. read the letter →

arxiv 2502.10051 v2 pith:OLSJUT2M submitted 2025-02-14 cs.CL

Ahmad Shadid , Rahul Kumar , Mohit Mayank This is my paper · ORCID
classification cs.CL
keywords LLMroutingqueryembeddingclusteringbenchmarkmappingmixtureofmodelscost-awareinferenceK-nearestneighbors
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish that a lightweight vector-space router can outperform every single member of a pool of large language models by learning which benchmark each query belongs to. ORI embeds each query, assigns it to a cluster of similar queries, reads off the dominant benchmark of that cluster, and sends the query to the model that scores best on that benchmark. The reported results are accuracy gains on MMLU (85.0 vs 83.7 next best) and MuSR (38.1 vs 36.3), a tie on ARC (93.0), and 78.0 on BBH against the top pool model's 78.8, achieved while keeping cost and latency in line with a single mid-size model. If true, this means a multi-model system can beat individual models on mixed workloads without training a task classifier or collecting preference labels.

What carries the argument

The load-bearing mechanism is cluster-to-benchmark dominance routing. ORI converts each query into a 384-dimensional sentence embedding, clusters the combined training splits of six benchmarks with K-Means (20 clusters), assigns each cluster its dominant benchmark by counting which benchmark supplies most of the cluster's points, and routes new queries to the model with the top public-leaderboard score on that benchmark. The KNN model formed on the training embeddings is what generalizes the mapping to new queries; the routing decision itself is a single nearest-centroid lookup, which is what keeps overhead small.

What would settle it

Run ORI on a held-out set of queries whose true task categories are not among the six fitted benchmarks and compare the routed accuracy with always using the best pool model; if routed accuracy does not exceed the single-model baseline, the cluster-dominance proxy has failed.

Watch

Extended reading notes

Core claim

ORI's central discovery claim is that query-level LLM routing can be reduced to a cluster-dominance rule: embed each incoming prompt, find its nearest cluster, identify the benchmark that dominates that cluster, and route to whichever model in the pool scores highest on that benchmark. On MMLU this yields 85.0, surpassing the next-best model (83.7); on MuSR it yields 38.1, above the strongest individual model (36.3); on ARC it ties at 93.0; and on BBH it lands at 78.0, essentially matching Deepseek-67B's 78.8. The paper argues this shows a multi-model system can beat every single model in its pool without needing human preference labels.

Load-bearing premise

The load-bearing premise is that the benchmark dominating a query's embedding cluster is a trustworthy stand-in for the query's task identity, so the model best on that benchmark is the right model for the query; this mapping is fitted on the training splits of the same six benchmarks used for scoring, and the reported cluster-separation scores are below 0.11.

Editorial extensions

If this is right

  • On MMLU, a user who swaps the best single pool model for ORI gains 2.7 accuracy points, and on MuSR gains 1.8 points, with no additional labeled training data.
  • Because routing is a nearest-centroid lookup after one embedding call, the added overhead per query is tiny compared to generating a response, so the accuracy gain does not require heavier inference.
  • On ARC, ORI ties the top pool model at 93.0, and on BBH it lands at 78.0, effectively matching Deepseek-67B's 78.8, so adopting the router costs little or no accuracy on those benchmarks.
  • The cost analysis on MMLU shows ORI's total cost ($1.94) sits between the cheapest single model ($1.49) and the most expensive ($7.06), supporting the claim that routing controls rather than multiplies spend.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If cluster-dominance routing is the active ingredient, the same recipe should transfer to any model pool and any benchmark suite: embed training queries, cluster, map clusters to the locally best model, and route. This is an extension the paper does not test.
  • Because the cluster-to-benchmark mapping is fitted on the training splits of the same benchmarks used for scoring, the reported gains are strongest for queries drawn from those benchmark distributions; distribution shift to new task families would be a harsher test.
  • The low silhouette scores reported in the paper suggest the top-level benchmark label is a noisy proxy for cluster identity; a finer, sub-benchmark labeling might be what actually carries the routing signal and could be tested by replacing benchmark-dominance with sub-task-dominance.
  • One can benchmark ORI against an oracle router that knows each query's true best model; the gap between ORI and that oracle would isolate how much accuracy is lost to cluster noise.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. This paper proposes ORI (O Routing Intelligence), a framework that routes each incoming query to one of several large language models. The method embeds queries with a Sentence Transformer, clusters them with K-Means or Agglomerative clustering (K=20), labels each cluster by the dominant benchmark using training-split data, and routes each query to the model with the highest leaderboard score on that dominant benchmark. The authors report accuracy results on MMLU, BBH, MuSR, and ARC, claiming gains up to 2.7 points on MMLU and 1.8 points on MuSR over the strongest individual models, along with cost, speed, and latency analyses on MMLU. The central claim is that routing based on embedding clusters and benchmark dominance yields accuracy improvements without relying on human preference data.

Significance. If the reported results were correct, ORI would provide a simple, explainable, and human-preference-free routing baseline, with a clear algorithmic description and a cost analysis that would be useful to practitioners. The authors do make several commendable choices: the routing rule in Section 3.2.4 is stated explicitly, Table 3 gives the benchmark-to-model mapping used for routing, and Tables 5-7 break down cost, speed, and latency. These choices make the paper's claims directly checkable, and the check reveals serious problems. The headline MMLU score (85.0) is not derivable from the stated routing rule and the paper's own tables; ARC is evaluated but never integrated into the training or mapping procedure; and the clustering quality is acknowledged by the authors to be weak (Silhouette scores below 0.11). The empirical gains, as presented, are therefore unsupported by the evidence in the manuscript.

major comments (4)
  1. [§4.1, §3.2.4, Tables 3 and 4] The reported ORI score of 85.0 on MMLU cannot be produced by the routing rule stated in Section 3.2.4. Table 3 maps MMLU to Qwen2.5-72B with a leaderboard score of 82.3, and Table 4 reports the best individual model on MMLU as Samba-CoE v0.3 at 83.7. If all MMLU test queries are routed to the model assigned to the MMLU-dominant cluster, ORI's MMLU score would be at most 82.3; if queries are routed to clusters dominated by other benchmarks, the result would be a weighted average of the per-cluster model scores on MMLU, which the paper does not report. Thus, the headline gain of 2.7 points is not derivable from the paper's own equations and tables. The ambiguity is compounded by the fact that the training data in Section 3.2.1 come from MMLU-PRO while the evaluation in Table 4 is on MMLU; the authors do not explain how the cluster-to-benchmark mapping transfers from MMLU-PRO to MMLU.
  2. [§4.1, Table 4 vs. §3.2.1 and Table 3] The claimed ARC result (ORI 93.0, tying the top performance) is unexplained by the method. ARC is not among the six training benchmarks listed in Section 3.2.1 (MMLU-PRO, GPQA, MUSR, BBH, IFEVAL, Math L5), and Table 3 does not provide a benchmark-to-model mapping for ARC. Under the routing rule in Section 3.2.4, a query can only be routed to the model that is best on the dominant benchmark of its cluster; without a mapping for ARC, there is no mechanism in the described method by which ORI can match the best ARC model. The authors need to specify how ARC queries are clustered, which model they are routed to, and report the resulting per-benchmark accuracy, or remove the ARC claim.
  3. [§3.2.3, Table 2, and §3.2.4] The cluster-to-benchmark mapping is the sole basis for routing, yet the authors report Silhouette scores below 0.11 for both K-Means and Agglomerative clustering (Table 2), and the text in Section 3.2.3 itself states that this indicates limited cluster separability. With such weak cluster structure, the dominant-benchmark label of a cluster may not generalize to new test queries, making the router's decision rule effectively a noisy benchmark classifier. The manuscript should provide held-out evidence that cluster membership predicts query type and routing quality; for example, report per-cluster test accuracy of the assigned model versus alternative models, and compare ORI against a random-routing baseline and a 'route-all-queries-to-the-single-best-model' baseline. Without such evidence, the claimed gains cannot be attributed to the clustering-based routing mechanism.
  4. [§4.1 and §4.2] All benchmark results are single-run point estimates with no error bars, confidence intervals, or significance tests. The claimed improvements (e.g., 1.8 points on MuSR over Calme-2.4-78B, and 0.1-0.9 points on BBH) are within the range of typical run-to-run variance for LLM evaluations on these benchmarks. Additionally, the routing model's performance is compared against values in Table 4 that appear to be taken from leaderboards or external sources rather than measured under the same evaluation protocol. The paper should either re-run all baselines under identical conditions or clearly state which numbers are externally reported, and should report multiple runs with variance estimates.
minor comments (6)
  1. [§3.2.3, item 4(a)] The text states that silhouette scores 'ranged from 0.08 to 0.11, indicating moderate cluster quality,' but values below 0.11 are generally considered weak; this characterization is inconsistent with the earlier statement in the same section that the scores indicate limited cluster separability.
  2. [Abstract] The sentence 'ties the top performance on ARC, and on BBH' is grammatically incomplete, and Table 4 shows that ORI's BBH score (78.0) is below Deepseek-67B (78.8), so the claimed tie or match on BBH is not supported by the table.
  3. [Table 4] Several entries are marked with a dash ('-') for baseline models (e.g., RouteLLM on BBH, MuSR, and ARC; RouterDC on BBH and MuSR), which prevents a full comparison; the authors should report the missing values or state explicitly that those models were not evaluated on those benchmarks.
  4. [§4.2.1-§4.2.2, Tables 5-7] The cost, speed, and latency figures are computed for the MMLU dataset, but the paper does not specify whether these figures include the embedding and clustering overhead of the ORI router itself; the overhead should be reported or explicitly excluded so that the cost comparison is interpretable.
  5. [Figures 1 and 2] The manuscript references Figure 1 (Silhouette score comparison) and Figure 2 (t-SNE clusters), but the figures are not present in the version under review; the authors should include the figures or remove the references.
  6. [§3.2.1 and Table 1] The notation is inconsistent between 'MUSR' in Section 3.2.1 and 'MuSR' in Table 1 and elsewhere, and between 'MMLU-PRO' (training) and 'MMLU' (evaluation); please unify the terminology throughout the paper.

Circularity Check

2 steps flagged · score 8.0 of 10

ORI's reported gains reduce to a lookup of test-set benchmark scores; the headline 85.0 on MMLU is not derivable from the paper's own tables.

  1. fitted input called prediction [Section 3.1.4 (Metrics) and Section 3.2.4 (Routing Process)]
    "Once the models are trained, they are evaluated solely on the test portion Btest. ... We define each model's score on a particular benchmark bk as: Score(mj, bk) = ... To determine which model handles pi, we use benchmark dominance within the identified cluster, routing pi to the model that achieves the highest score on the dominant benchmark of the cluster: R(pi, mj) = 1 if mj = arg max_mj Score(mj, bdominant)."

    The routing decision is the argmax of the same Score values that are then reported as ORI's benchmark performance. Because Score is computed on the test split, the router is not predicting ORI's accuracy; it is selecting the model whose test-set Score on the dominant benchmark is highest. ORI's per-benchmark result is therefore determined by the input Scores by construction, and any 'gain' over individual models is a restatement of the argmax selection rule rather than an independent outcome. The paper's own reported 85.0 on MMLU does not even equal any input Score (best mapped MMLU model is 82.3; best tabulated model is 83.7), so the claimed result is also not reproducible from the stated equations.

  2. renaming known result [Section 3.2.3(d) Model Mapping to Benchmark]
    "For each benchmark, only the top-performing models—those achieving the highest scores relative to competitors—were mapped."

    ORI's routing content is entirely the lookup of the leaderboard's top-performing model per benchmark. Once a cluster's dominant benchmark is known, the assigned model is by definition the model with the highest Score on that benchmark, so ORI's benchmark-level performance cannot exceed, and in the best case equals, the leaderboard best model for that benchmark. Presenting this per-benchmark best-model selection as ORI 'outperforming the strongest individual models' renames the known practice of using each benchmark's best model rather than deriving a new capability.

full rationale

The central derivation chain of ORI is circular in the following sense: the routing rule selects a model by maximizing Score(mj, b_dominant), where Score is computed on the test portion of the benchmarks, and the paper then reports ORI's performance on those same test portions. The reported benchmark scores are therefore constructed from the same test-set numbers used to make routing decisions, so the 'prediction' that ORI performs well reduces to the input Scores by construction. In addition, the model-to-benchmark mapping is taken from the Hugging Face leaderboard's per-benchmark top performers, and the paper presents the resulting aggregate as ORI outperforming individual models, which is a renaming of per-benchmark best-model selection. Separately, the headline MMLU score of 85.0 is not derivable from the paper's own tables: Table 3 maps MMLU to Qwen2.5-72B with 82.3, and Table 4's best MMLU model is Samba-CoE v0.3 with 83.7, so the claimed 85.0 is arithmetically inconsistent with the stated routing rule. Similarly, ARC appears in the evaluation (93.0) but is absent from the six training benchmarks listed in Section 3.2.1 and from the Table 3 mapping, so the ARC result is unexplained by the method. These are correctness risks as well as symptoms of the circular construction. The paper contains no self-citations that are load-bearing; all references are to external prior work. However, the central claim itself reduces to a fit: the router is fit to benchmark labels and test-set scores, and ORI's benchmark performance is a selection from those same scores.

Assumptions & free parameters 3 free parameters · 3 assumptions · 0 invented entities

The central claim depends on three fitted choices (cluster count, embedding model, dominance mapping) and three domain assumptions about transfer from training to test and leaderboard to API. There are no newly invented physical or mathematical entities.

free parameters (3)
  • Number of clusters K = 20
    Selected by maximizing Silhouette score over K in [2,30] on training embeddings (Section 3.2.3); all scores below 0.11.
  • Embedding model = unspecified Sentence Transformer, 384-dim
    Chosen for 'industry adoption and lightweight architecture' with no comparative evaluation (Section 3.2.2).
  • Cluster-to-benchmark dominance mapping = dominant benchmark per cluster j*(k) = argmax_j D_{k,j}
    Fit to the training splits of the six evaluation benchmarks (Section 3.2.3, step 3); this mapping is the routing decision rule itself.
assumptions (3)
  • domain assumption Embedding distance reflects task-level similarity across the six benchmarks
    The routing rule assumes queries from the same benchmark cluster together; the paper's own silhouette scores (<0.11) indicate weak cluster separation (Section 3.2.3).
  • domain assumption The best model on a benchmark's training split is also the best on its test split
    Model-to-benchmark mapping uses leaderboard scores (Table 3) with no validation on the actual API evaluation used in Table 4 (Section 3.2.3d).
  • domain assumption Leaderboard scores and API-based scores are comparable across providers
    The routing rule uses scores from the Hugging Face leaderboard while evaluation is run through a single API provider (aimlapi.com), with no cross-check (Sections 3.2.3d and 4.2).

how reviews work

0 comments
Cite this review

Pith. "Pith review of ORI: O Routing Intelligence." pith.science (2026). https://pith.science/paper/OLSJUT2M

@misc{pith2026250210051,
  author       = {Pith},
  title        = {Pith review of: ORI: O Routing Intelligence},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/OLSJUT2M}},
  note         = {Machine review of arXiv:2502.10051}
}
read the original abstract

Single large language models (LLMs) often fall short when faced with the ever-growing range of tasks, making a single-model approach insufficient. We address this challenge by proposing ORI (O Routing Intelligence), a dynamic framework that leverages a set of LLMs. By intelligently routing incoming queries to the most suitable model, ORI not only improves task-specific accuracy, but also maintains efficiency. Comprehensive evaluations across diverse benchmarks demonstrate consistent accuracy gains while controlling computational overhead. By intelligently routing queries, ORI outperforms the strongest individual models by up to 2.7 points on MMLU and 1.8 points on MuSR, ties the top performance on ARC, and on BBH. These results underscore the benefits of a multi-model strategy and demonstrate how ORI's adaptive architecture can more effectively handle diverse tasks, offering a scalable, high-performance solution for a system of multiple large language models.

Figures

Figures reproduced from arXiv: 2502.10051 by the authors.

Figure 1
Figure 1. Silhouette Score comparison of K-Means and Agglomerative clustering across different cluster [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. t-SNE Clusters and Example Prompt Annotation. The red star indicates the new prompt, [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

28 extracted references · 12 canonical work pages

  1. [1]

    Clustering analyzes provide evidence for these nuanced task differences, ensuring more accurate and context- sensitive model selection

    Granular Task Identification in Overlapping Benchmarks We delve beyond top-level benchmarks to isolate more granular task structures, recognizing that a model that performs well on an entire benchmark may falter on specific sub-tasks. Clustering analyzes provide evidence for these nuanced task differences, ensuring more accurate and context- sensitive mod...

    work page

  2. [2]

    perceptive router

    Dimension-Flexible Optimization with ORI The ORI framework unifies multiple models and empirically determines which one excels under given constraints such as accuracy, speed, or cost. By prioritizingaccuracy as a core constraint, ORI ensures that the most reliable model is selected for each subtask or benchmark, while still optimizing for speed and cost ...

    work page

  3. [3]

    , pn} ⊂Rd represent a set ofn prompts embedded in ad-dimensional space

    K-Means Cluster Assignment: Let {p1, p2, . . . , pn} ⊂Rd represent a set ofn prompts embedded in ad-dimensional space. The goal is to assign each prompt to one ofK clusters based on its proximity to the cluster centroids. The assignment is determined by: c(pi) = arg min k∈{1,...,K} pi − µk 2 , where c(pi) denotes the cluster label assigned to promptpi, an...

    work page

  4. [4]

    This grouping helps analyze how the 6 prompts within each cluster are distributed across benchmarks

    Benchmark Distribution in Clusters: The dataset is grouped by cluster labels, with each prompt assigned to a cluster based on the K-Means algorithm. This grouping helps analyze how the 6 prompts within each cluster are distributed across benchmarks. Assume that we haveB benchmarks, denoted b1, b2, . . . , bp. After clustering, define: Dk,j = #{pi | c(pi) ...

    work page

  5. [5]

    For example: To identify the benchmark that dominates clusterk, we select the indexj∗(k) that satisfies: j∗(k) = arg max 1≤j≤p Dk,j

    Cluster-Benchmark Mapping:Clusters were analyzed for dominance of the benchmark, showing clear associations between specific clusters and benchmarks. For example: To identify the benchmark that dominates clusterk, we select the indexj∗(k) that satisfies: j∗(k) = arg max 1≤j≤p Dk,j . Hence, bj∗(k) is the most frequent (or dominant) benchmark in clusterk, w...

    work page

  6. [6]

    (a) Silhouette Scores: • The scores showed variability, but generally improved with more clusters

    Benchmark Mapping by Cluster: This detailed mapping aids in identifying which benchmarks dominate each cluster, ensuring appropriate routing, and enhancing query specialization. (a) Silhouette Scores: • The scores showed variability, but generally improved with more clusters. • The scores ranged from 0.08 to 0.11, indicating moderate cluster quality. (b) ...

    work page

  7. [7]

    Cost Efficiency: ORI offers a competitive cost structure, being more affordable than most models while slightly more expensive than Meta-Llama-3-70B

    work page

  8. [8]

    Token Generation Speed: ORI achieves high token generation speed, outperforming several models, and providing quick response times

    work page

Show all 28 references
  1. [9]

    2Token generation speeds were calculated by dividing the total number of tokens generated by the total processing time (in seconds)

    Latency Performance: ORI maintains efficient response times, demonstrating lower latency compared to many models, ensuring rapid query processing. 2Token generation speeds were calculated by dividing the total number of tokens generated by the total processing time (in seconds...

  2. [10]

    B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P.,

    Brown, T. B., Mann, B., Ryder, N., Subbiah, M., Kaplan, J., Dhariwal, P., ... & Amodei, D. (2020). Language Models are Few-Shot Learners. arXiv. https://arxiv.org/abs/2005.14165

    2020 arXiv

  3. [11]

    & Petrov, S

    Chowdhery, A., Narang, S., Devlin, J., Bosma, M., Mishra, G., Roberts, A., ... & Petrov, S. (2022). PaLM: Scaling Language Modeling with Pathways. arXiv. https://arxiv.org/abs/2204. 02311

    2022

  4. [12]

    N., Kaiser, Ł., & Polosukhin, I

    Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A. N., Kaiser, Ł., & Polosukhin, I. (2017).Attention Is All You Need. arXiv. https://arxiv.org/abs/1706.03762

    2017 arXiv

  5. [13]

    Radford, A., Narasimhan, K., Salimans, T., & Sutskever, I. (2018). Improving Language Understanding by Generative Pre-Training. arXiv. https://arxiv.org/abs/1801.00173

    2018 arXiv

  6. [14]

    H., Hoang, D

    Nguyen, Q. H., Hoang, D. C., Decugis, J., Manchanda, S., Chawla, N. V., & Doan, K. D. (2024). MetaLLM: A High-performant and Cost-efficient Dynamic Framework for Wrapping LLMs. arXiv. https://arxiv.org/abs/2407.10834

    2024 arXiv

  7. [15]

    (2024).OptLLM: Optimal Assignment of Queries to Large Language Models

    Liu, Y., Zhang, H., Miao, Y., Le, V.-H., & Li, Z. (2024).OptLLM: Optimal Assignment of Queries to Large Language Models. arXiv. https://arxiv.org/abs/2405.15130

    2024 arXiv

  8. [16]

    T., & Zhang, Y

    Chen, S., Jiang, W., Lin, B., Kwok, J. T., & Zhang, Y. (2024).RouterDC: Query-Based Router by Dual Contrastive Learning for Assembling Large Language Models. arXiv. https://arxiv.org/abs/2409.19886

    2024 arXiv

  9. [17]

    E., Kadous, M

    Ong, I., Almahairi, A., Wu, V., Chiang, W.-L., Wu, T., Gonzalez, J. E., Kadous, M. W., & Stoica, I. (2024). RouteLLM: Learning to Route LLMs with Preference Data. arXiv. https://arxiv.org/abs/2406.18665

    2024 arXiv

  10. [18]

    P., Mishra, S., Zhou, P., Gupta, A., Rajagopal, D., Kappaganthu, K., Yang, Y., Upadhyay, S., Faruqui, M., & Mausam

    Aggarwal, P., Madaan, A., Anand, A., Potharaju, S. P., Mishra, S., Zhou, P., Gupta, A., Rajagopal, D., Kappaganthu, K., Yang, Y., Upadhyay, S., Faruqui, M., & Mausam. (2024).AutoMix: Automatically Mixing Language Models. arXiv. https://arxiv.org/abs/2310.12963v4

    2024 arXiv

  11. [19]

    K., Srivatsa, K

    Maurya, K. K., Srivatsa, K. V. A., & Kochmar, E. (2024).SelectLLM: Query-Aware Efficient Selection Algorithm for Large Language Models. arXiv. https://arxiv.org/abs/2408. 08545 12

    2024

  12. [20]

    (2024).EmbedLLM: Learning Compact Representations of Large Language Models

    Zhuang, R., Wu, T., Wen, Z., Li, A., Jiao, J., & Ramchandran, K. (2024).EmbedLLM: Learning Compact Representations of Large Language Models. arXiv. https://arxiv.org/abs/ 2410.02223v2

    2024 arXiv

  13. [21]

    F., Chow, T., Khare, I

    Guha, N., Chen, M. F., Chow, T., Khare, I. S., & Ré, C. (2024, December 9).SMOOTHIE: Label-Free Language Model Routing. arXiv. https://arxiv.org/abs/2412.04692v1

    2024 arXiv

  14. [22]

    (2024).GraphRouter: A Graph-Based Router for LLM Selections

    Feng, T., Shen, Y., & You, J. (2024).GraphRouter: A Graph-Based Router for LLM Selections. arXiv. https://arxiv.org/abs/2410.03834

    2024 arXiv

  15. [23]

    (2024).Your Mixture-of-Experts LLM is Secretly an Embedding Model for Free

    Li, Z., & Zhou, T. (2024).Your Mixture-of-Experts LLM is Secretly an Embedding Model for Free. arXiv. https://arxiv.org/abs/2410.10814v2

    2024 arXiv

  16. [24]

    H., & Wang, C

    Zhang, J., Krishna, R., Awadallah, A. H., & Wang, C. (2023).EcoAssistant: Using LLM Assistant More Affordably and Accurately. arXiv. https://arxiv.org/abs/2310.03046

    2023 arXiv

  17. [25]

    Shnitzer, T., Ou, A., Silva, M., Soule, K., Sun, Y., Solomon, J., Thompson, N., & Yurochkin, M. (2023). Large Language Model Routing with Benchmark Datasets. arXiv. https: //arxiv.org/abs/2309.15789

    2023 arXiv

  18. [26]

    N., & Thomson, M

    Hari, S. N., & Thomson, M. (2023).Tryage: Real-time, Intelligent Routing of User Prompts to Large Language Models. arXiv. https://arxiv.org/abs/2308.11601

    2023 arXiv

  19. [27]

    Jiang, D., Ren, X., & Lin, B. Y. (2023).LLM-BLENDER: Ensembling Large Language Models with Pairwise Ranking and Generative Fusion. arXiv. https://arxiv.org/abs/ 2306.02561v3

    2023 arXiv

  20. [28]

    (2023).FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance

    Chen, L., Zaharia, M., & Zou, J. (2023).FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance. arXiv. https://arxiv.org/abs/2305. 05176 13

    2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.