LLM-роутер: маршрутизація запитів і мінус 60% витрат [2026]

LLM-роутер: маршрутизація запитів і мінус 60% витрат [2026]

LLM-роутер — це тонкий шар між вашим застосунком і кількома мовними моделями, який вирішує, яка модель обробить кожен запит. Він оглядає запит (тип завдання, складність, бюджет токенів), пересилає його найвідповіднішій моделі, а якщо та помиляється, перемикається на резервну. Мета: відповідь правильного рівня за найнижчу ціну токена.

Платити frontier-моделі за відповідь «яка у вас політика повернень?», ось як роздуваються рахунки. AWS у квітні 2025 року виміряв альтернативу: роутер-класифікатор додає 0,53 секунди затримки, семантичний роутер додає 0,10 секунди, а маршрутизація всередині однієї родини моделей дає до 30% економії. Повторіть той самий розрахунок між вендорами за прайсами липня 2026 року, як ми зробили нижче, і скорочення сягне 70%. Левова частка економії припадає на одне рішення, ухвалене ще до генерації першого токена.

Головні висновки

• LLM-роутер вирішує, яка модель обробить кожен запит, на основі типу завдання, вартості або виміряної якості.
• Існує п'ять стратегій: на основі правил, з урахуванням вартості, з урахуванням затримки, семантична (ембедінги) та маршрутизація LLM-класифікатором.
• Маршрутизація за правилами додає ~0 мс і $0; класифікатор додає 300–800 мс плюс вартість токенів класифікатора на кожен запит.
• Маршрутизація може скоротити витрати на токени до 60%, коли більшість простого трафіку переходить на модель, дешевшу в 10–20 разів.
• Один провайдер, менш як 10 тис. запитів на день, немає тиску на бюджет? Пропустіть роутер. Звичайних фолбеків достатньо.

Що насправді робить LLM-роутер?

LLM-роутер виконує невеликий крок ухвалення рішення перед кожним викликом моделі: прочитати запит, оцінити його за правилом маршрутизації, обрати модель, надіслати виклик і повторити спробу на резервній моделі, якщо перша помилилася. Усе інше у вашому застосунку лишається без змін. Ви так само надсилаєте один запит і отримуєте одну відповідь.

Життєвий цикл запиту по порядку:

1. Запит надходить на ендпоінт роутера, точно так само, як на API моделі.
2. Аналіз. Роутер оглядає промпт: ключові слова, кількість токенів, ембедінг або оцінку класифікатора.
3. Вибір. Стратегія маршрутизації зіставляє цей сигнал із рівнем моделі (дешева, середня, frontier або локальна).
4. Пересилання. Виклик іде до обраної моделі через OpenAI-сумісний API.
5. Фолбек. У разі тайм-ауту, ліміту запитів або помилки запит повторюється на наступному рівні ланцюжка.

Люди гуглять «llm gateway vs router», бо документація вендорів змішує ці терміни. Одне речення усе розставляє по місцях: шлюз — це труба, роутер — це рішення. Це шари, а не суперники, і більшість шлюзів мають роутер усередині.

Згідно з документацією LiteLLM, той самий проксі, який зберігає ваші віртуальні ключі, також запускає роутер. Порівнюєте саме інструменти рівня труби? Наш огляд найкращих LLM-шлюзів ранжує десять із них.

Чи взагалі потрібен вам LLM-роутер?

Більшості невеликих застосунків він не потрібен. Роутер виправдовує себе, коли трафік чітко ділиться на різні типи завдань, коли рахунок за токени є вашою головною статтею інфраструктурних витрат, або коли ви працюєте з кількома провайдерами й потрібен фолбек. Нижче цих порогів звичайні повтори плюс одна резервна модель дають надійність без зайвого рухомого елемента.

Скажемо прямо, бо в цій ніші ніхто інший не скаже: якщо у вас один провайдер і менш як 10 тис. запитів на день, роутер буде лише накладними витратами, яких можна уникнути. Звичайні фолбеки виграють.

Чому так прямо? Кожен маршрут є твердженням («цей клас завдань безпечний для дешевої моделі»), яке старіє в міру того, як змінюються моделі, ціни та ваш продукт. Погоджуйтеся на ці витрати підтримки лише тоді, коли економія їх явно перевищує.

5 стратегій LLM-маршрутизації (і коли яку обрати)

Кожна стратегія LLM-маршрутизації відповідає на одне запитання: якому сигналу ви довіряєте настільки, щоб обрати модель? Правила довіряють ключовим словам. Маршрутизація за вартістю довіряє бюджету токенів. Маршрутизація за затримкою довіряє таймеру. Семантична маршрутизація довіряє ембедінгам. Маршрутизація класифікатором довіряє іншій LLM. Компроміс завжди один і той самий: якісніший сигнал означає більшу додану затримку й вартість на запит.

Автодоповнення підказує варіанти «llm routing strategies», «llm task routing», «llm intent routing» та «llm dynamic routing». Усі вони зводяться до п'яти патернів:

Один патерн перетинає всі п'ять: каскад, також званий рівнями моделей. Починайте з дешевого й ескалуйте лише в разі помилки або низької впевненості. Підтримка-бот відповідає з моделі за $0,25 на мільйон токенів; якщо його впевненість падає нижче 0,7, той самий запит повторюється на frontier-моделі. Ви платите за інтелект лише тоді, коли дешевий рівень визнає, що зайшов у глухий кут.

Для академічної глибини: бібліотека LLMRouter від ulab-uiuc каталогізує понад 16 досліджених алгоритмів маршрутизації (KNN, SVM, MLP, матрична факторизація, Elo, графові та BERT-подібні). Якщо ви обрали семантичну маршрутизацію, то ембедінги зразків вирішують майже все; наш гід про найкращі моделі ембедінгу розповідає, які з них тримаються на реальних корпусах.

Як зібрати LLM-роутер на Python?

Досить приблизно 80 рядків звичайного Python проти будь-якого OpenAI-сумісного ендпоінта. Жодного фреймворку не потрібно. Чотири роутери нижче зростають за складністю: правила за ключовими словами, поріг вартості, подібність ембедінгів і модель-класифікатор із фолбеком. Кожен друкує обрану модель, тож ви бачите рішення на власні очі.

Якщо ви гуглили «how to build an llm router» і знаходили лише AWS CDK-стеки та академічні репозиторії, цей розділ і є простою відповіддю. Референсна реалізація AWS надійна, але намертво приварена до Bedrock, Lambda та CDK. Наша працює скрізь, куди вказує клієнт OpenAI: OpenAI, Anthropic через проксі, Ollama на ноутбуці, vLLM на сервері з GPU. Ось роутер, який ми спершу начертуємо клієнтам.

Крок 1: роутер на правилах (ключові слова → моделі)

Базовий варіант із нульовою затримкою. Карта регексів вирішує; усе, що не збіглося, іде на frontier-рівень.

import re
from openai import OpenAI

client = OpenAI()  # works with OpenAI, Ollama, vLLM, or a LiteLLM proxy

def ask(model: str, prompt: str) -> str:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.choices[0].message.content

ROUTES = [
    (re.compile(r"\b(refund|cancel|invoice|password|hours)\b", re.I), "gpt-5-mini"),
    (re.compile(r"\b(summarize|translate|rewrite)\b", re.I), "gpt-5-mini"),
]
FRONTIER = "gpt-5"

def rule_router(prompt: str) -> str:
    for pattern, model in ROUTES:
        if pattern.search(prompt):
            return model
    return FRONTIER

prompt = "How do I cancel my subscription?"
model = rule_router(prompt)
print(model)  # gpt-5-mini: regex hit on "cancel"
print(ask(model, prompt))

Вхід: запитання до підтримки. Рішення: збіг регекса на «cancel». Обрана модель: gpt-5-mini. Для маршрутизації не потрібен жоден виклик API, тому цей підхід лишається усталеним.

Крок 2: роутер за вартістю (поріг бюджету токенів)

Та сама ідея, але сигналом слугує розмір запиту, а не ключові слова. Короткі промпти з малим бюджетом виводу йдуть у дешевий рівень; усе інше прямує у frontier.

def cost_router(prompt: str, max_output_tokens: int = 500) -> str:
    word_count = len(prompt.split())
    if word_count < 60 and max_output_tokens <= 300:
        return "gpt-5-mini"  # $0.25 in / $2 out per M tokens
    return "gpt-5"           # $1.25 in / $10 out per M tokens

prompt = "Write a two-line product description for a ceramic mug."
model = cost_router(prompt, max_output_tokens=120)
print(model)  # gpt-5-mini: short prompt, small output budget

Грубо? Так. Ефективно? Теж так, бо обсяг токенів корелює з розміром завдання краще, ніж більшість очікує. Саме на цьому побудована вся стратегія кількох платних продуктів категорії «cheap llm router».

Крок 3: семантичний роутер (ембедінги проти зразків)

Для розмитих запитів користувачів, які оминають ключові слова, вбудуйте промпт у вектор і порівняйте його з векторами промптів-зразків. Запит дістається тому кластеру, який найближчий.

import numpy as np

EXEMPLARS = {
    "gpt-5-mini": [
        "classify this support ticket into a category",
        "extract the shipping address from this email",
    ],
    "gpt-5": [
        "debug this race condition in our worker pool",
        "design a multi-tenant billing schema",
    ],
}

def embed(texts: list[str]) -> np.ndarray:
    r = client.embeddings.create(model="text-embedding-3-small", input=texts)
    return np.array([d.embedding for d in r.data])

CENTROIDS = {m: embed(xs).mean(axis=0) for m, xs in EXEMPLARS.items()}

def semantic_router(prompt: str) -> str:
    v = embed([prompt])[0]
    scores = {
        m: float(np.dot(v, c) / (np.linalg.norm(v) * np.linalg.norm(c)))
        for m, c in CENTROIDS.items()
    }
    return max(scores, key=scores.get)

print(semantic_router("pull the tracking number out of this message"))
# gpt-5-mini: closest to the extraction exemplars

Виклик маршрутизації коштує один ембедінг (кілька сотень токенів) і 50–150 мс. Обчислюйте центроїди під час запуску, а не на кожен запит.

Крок 4: роутер на LLM-класифікаторі з фолбеком

Найсильніший сигнал: дешева модель читає промпт і оцінює його складність. Саме цю стратегію AWS виміряв у 0,53 секунди доданої затримки, тож ми загортаємо її в ланцюжок фолбеків.

def classify_router(prompt: str) -> str:
    verdict = client.chat.completions.create(
        model="gpt-5-mini",
        messages=[{"role": "user", "content":
            "Reply HARD or EASY only. Task: " + prompt}],
        max_tokens=5,
    ).choices[0].message.content.strip().upper()
    return "gpt-5" if verdict.startswith("HARD") else "gpt-5-mini"

def route_and_call(prompt: str) -> str:
    model = classify_router(prompt)
    try:
        return ask(model, prompt)
    except Exception:
        backup = "gpt-5-mini" if model == "gpt-5" else "gpt-5"
        return ask(backup, prompt)  # fallback tier catches the failure

print(route_and_call("Prove this greedy algorithm is optimal."))
# classifier says HARD, so gpt-5 answers

Ось і весь приклад llm-роутера: чотири функції, один клієнт, жодної інфраструктури понад ту, що у вас уже є. Про продакшен-зміцнення йдеться у наступному розділі.

Скільки насправді економить LLM-маршрутизація?

AWS виміряв накладні витрати роутера у $107,90–$188,90 на місяць на кожні 100 000 запитань на день: класифікатор додає 0,53 секунди на запит, семантичний роутер додає 0,10 секунди. Економія затьмарює ці накладні витрати. Наш розрахунок нижче, побудований на прайсах липня 2026 року, дає скорочення витрат на 70,7%. Підступ у структурі трафіку: більшість запитів мають потрапляти в дешевий рівень.

Дві таблиці. Перша показує, скільки коштує сам роутер на 1 000 запитів:

Допис AWS від квітня 2025 року залишається єдиним незалежно опублікованим набором вимірювань у цій ніші, тож ми спираємося на нього, а власні розширення позначаємо як оцінки, а не як числа, які ми проганяли самі. Згідно з AWS, Bedrock Intelligent Prompt Routing скорочує витрати всередині родини моделей до 30%.

Друга містить розрахунок економії, що обґрунтовує наш заголовок:

Припущення, з позначками: 100 000 запитів на місяць; у середньому 800 вхідних плюс 200 вихідних токенів на запит; розподіл 80% простих / 20% складних; прайси зі сторінки цін Anthropic та сторінки цін OpenAI станом на липень 2026 року, повна таблиця тарифів є у нашому порівнянні цін LLM API. Арифметика на запит: Sonnet 4 коштує 800 × $3/млн + 200 × $15/млн = $0,0054; GPT-5 mini коштує 800 × $0,25/млн + 200 × $2/млн = $0,0006.

У результаті маємо скорочення на 70,7%, звідки й беруться 60% у нашому заголовку, ще й із запасом. Чесні застереження: це розрахунковий приклад, а не бенчмарк, який ми проганяли. Він припускає, що ваш дешевий рівень у 10–20 разів дешевший і що 80% трафіку справді кваліфікується. Маршрутизація всередині родини, сценарій AWS, лишається біля 30%. Та й маршрутизація є лише одним із багатьох важелів; кешування та обрізання промптів часто окупаються швидше, а наш гід зі скорочення витрат на LLM API ранжує всі дванадцять способів.

Продакшен-патерни маршрутизації

Іграшковий роутер обирає модель. Продакшен-роутер ще й повторює спроби, балансує навантаження, кешує повтори та ізолює API-ключі для кожної команди. Після кількох тисяч запитів на день припиніть писати це вручну й запустіть шлюз із вбудованим роутером.

Чотири патерни, які мають значення:

• Ланцюжки фолбеків. Спершу дешевий рівень, frontier у разі помилки або тайм-ауту. Єдиний найцінніший патерн; більша частина вашої надійності береться лише з нього.
• Балансування навантаження. Розподіляйте виклики між дубльованими деплоями або API-ключами, щоб обійти ліміти на ключ.
• Кешування відповідей. Ідентичні промпти повертають кешовані відповіді. Трафік підтримки повторюється частіше, ніж ви гадаєте; влучання у кеш на рівні 10–30% трапляються часто.
• Віртуальні ключі та бюджети. Видавайте ключі для кожної команди з місячними лімітами, щоб один зациклений процес не спалив увесь рахунок.

Це близьке до конфігурації, яку ми тримаємо на нашому стейджинг-стеку агентів (файл: litellm-router.yaml, монтується в контейнер проксі LiteLLM):

model_list:
  - model_name: cheap
    litellm_params:
      model: openai/gpt-5-mini
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-opus-5

router_settings:
  routing_strategy: simple-shuffle
  fallbacks: [{"cheap": ["frontier"]}]
  num_retries: 2
  timeout: 30

Де місце кожного інструмента, з нашими думками:

• LiteLLM. Обирайте, якщо хочете self-hosted і open source й уже працюєте з Docker. Наш гід із налаштування проксі LiteLLM проводить через повний деплой, включно з ключами та бюджетами.
• OpenRouter. Обирайте, якщо хочете сотні моделей за одним ключем і нуль операційної роботи. Їхня сторінка рейтингів водночас слугує даними про пропускну здатність.
• Portkey. Обирайте, якщо рішення визначають корпоративні вимоги (SSO, аудит-логи, звіти про відповідність).
• Власний код із цієї статті. Обирайте, якщо у вас до ~50 тис. запитів на день і ви не хочете жодної нової інфраструктури.

Що б ви не обрали, огляд інструментів LLM-шлюзів порівнює десять із них віч-на-віч.

Чи можна маршрутизувати між локальними моделями та хмарними API?

Так, і арифметика токенів вабить: локальна модель тарифікує $0 за токен, тож кожен запит, який обробляють Ollama або vLLM, це чиста економія. Розплата: затримка й якість на ват. Локальний рівень виграє для високооб'ємних простих завдань на заліззі, яке у вас уже є; хмарне API підхоплює все, що потребує мозку frontier-рівня.

Механіка антиклімактична, і в цьому суть. Ollama відкриває OpenAI-сумісний ендпоінт на localhost:11434/v1, і vLLM віддає ту саму форму. Тож кожен роутер вище працює без змін: спрямуйте base_url на локальний сервер, поставте qwen3:8b у дешевий слот і тримайте gpt-5 як резервний рівень. Для self-hosted коробки з роутером LiteLLM постачається як Docker-образ, і саме це люди шукають за запитом «llm router docker».

Дві нотатки про чесність. Модель на 70B на одній A100 видає приблизно 30–40 токенів на секунду; хмарні API б'ють цей показник на піковій пропускній здатності, тож локальна маршрутизація краще пасує рівномірному фоновому трафіку, ніж сплескам у чаті з користувачами. А локальні моделі на 8B спотикаються на багатокрокових викликах інструментів, тож тримайте складні маршрути спрямованими у хмару. Якщо обираєте сам рушій інференсу, vLLM проти SGLang бенчмаркать обидва.

Маршрутизація також живить багатомодельні конфігурації кодинг-агентів. Проксі у стилі LiteLLM дає Claude Code змогу говорити з локальними та хмарними моделями через один ендпоінт; точну схему з'єднань дивіться в матеріалі про використання різних моделей у Claude Code.

Як зрозуміти, що маршрутизація працює?

Або ви вимірюєте, або вгадуєте. Логувати, яка модель відповіла на кожен запит, оцінювати вибірку відповідей за рубрикою та подавати оцінки назад у правила маршрутизації. Команди, які пропускають цей крок, отримують статичну конфігурацію, що тихо гниє, поки моделі й ціни змінюються під нею.

Дуга дозрівання іде від правил до вартості, а потім до виміряної якості:

1. Логувати маршрут. Зберігайте обрану модель, затримку та кількість токенів на кожен запит як одну колонку у ваших наявних трейсах.
2. Оцінювати відповіді щотижня. LLM-суддя або людська вибірка, зарахування/незарахування на кожен клас запитів. П'ятдесят оцінених відповідей на клас достатньо, щоб коригувати курс.
3. Переналаштовувати. Якщо дешевий рівень складає 95%+ на певному класі, розширте його правило, щоб захопити більше такого трафіку. Якщо падає нижче 90%, звузьте.

Ось фраза, яку ми постійно повторюємо клієнтам: роутер, який ніколи не переналаштовують, є просто статичною конфігурацією з додатковою затримкою. Логувати обрану модель, оцінювати відповіді, подавати оцінки назад.

Цей цикл поєднує евали зі спостережністю, застосовані до маршрутизації. Наш гід з евалів LLM покриває рубрики оцінювання; гід зі спостережності AI покриває те, де живуть трейси.

Куди рухаються дослідження LLM-маршрутизації?

Академічна лінія розглядає маршрутизацію як задачу навчання, а не як файл конфігурації. LLMRouter від ulab-uiuc, бібліотека, яка ранжується першою за цим ключовим словом, реалізує понад 16 алгоритмів (KNN, SVM, MLP, матрична факторизація, Elo, графові, BERT та RL-роутери) з бенчмарк-конвеєром на 11 датасетах. Найцитованіша свіжа стаття, RouteLLM (Ong та ін., arXiv:2406.18665), навчає роутери на даних людських уподобань і звітує про понад 2-кратне скорочення вартості без втрати якості на MMLU та MT-Bench. Найсвіжіший поворот: роутери на prefill-активаціях, лінійка «prefill is all you need», які читають внутрішні активації моделі під час prefill, щоб передбачити складність ще до початку генерації. Вектор руху веде до роутерів, що навчаються самі на ваших даних евалів, а це саме той цикл зворотного зв'язку з попереднього розділу.

Як Techsy підходить до цього: агентські стеки, які ми відвантажуємо B2B-клієнтам, працюють саме за цим патерном: роутер за рівнями вартості з ланцюжками фолбеків, вбудованими у шлюз, плюс переналаштування на основі евалів. Якщо зважуєте, чи пасує маршрутизація вашому стеку, отримайте безплатну консультацію, і ми разом розкладемо структуру вашого трафіку.

Про автора

Мерт Батур — співзасновник Techsy.io, де команда відвантажує AI-агентів, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він пише про стек LLM-інструментів, який команда Techsy справді використовує в продакшені. Зв'язатися в LinkedIn.

Часті запитання

Що таке LLM-роутер?

LLM-роутер — це шар між вашим застосунком і кількома мовними моделями, який вирішує, яка модель обробить кожен запит. Він перевіряє тип завдання, розмір або складність запиту, а потім пересилає його найвідповіднішій моделі, з фолбеком на випадок її відмови. Уявіть його як диспетчера трафіку для ваших викликів модельного API.

Як працює LLM-маршрутизація?

LLM-маршрутизація працює у п'ять кроків: запит надходить, роутер оглядає його (ключові слова, кількість токенів або ембедінг), стратегія обирає рівень моделі, виклик пересилається, а резервна модель підхоплює будь-яку помилку. Усе рішення ухвалюється до початку генерації, тож воно додає мілісекунди, а не секунди, хіба що оцінювання виконує модель-класифікатор.

Чи LLM-роутер — те саме, що LLM-шлюз?

Ні. Шлюз — це труба: API-ключі, ліміти запитів, бюджети та логи. Роутер — це рішення: яка модель відповідає. Це шари, а не суперники, і більшість шлюзів (LiteLLM, Portkey, OpenRouter) мають роутер усередині. Можна запустити роутер без шлюзу, але в продакшені зазвичай потрібні обидва разом.

Чи маршрутизація моделей справді економить гроші?

Так, коли більшість вашого трафіку кваліфікується для значно дешевшого рівня. Наш розрахунковий приклад переносить 80% запитів із моделі за $3/$15 на мільйон токенів на модель за $0,25/$2 і ріже рахунок на 70,7%. AWS звітував про економію до 30% для маршрутизації всередині однієї родини моделей. Якщо ваш трафік однорідно складний, економіка прямує до нуля.

Який найкращий open-source LLM-роутер?

Для продакшену LiteLLM: self-hosted, активно підтримується й поєднує шлюз із роутером. Для алгоритмів дослідницького рівня LLMRouter від ulab-uiuc реалізує понад 16 стратегій маршрутизації з академічної літератури. RouteLLM є найсильнішим роутером за якістю на долар, навченим на даних уподобань. Більшості команд варто почати з LiteLLM і тягнутися до дослідницьких бібліотек, лише якщо потрібна власна логіка оцінювання.

Як зібрати LLM-роутер на Python?

Почніть з клієнта OpenAI і приблизно 80 рядків коду: карта правил від ключових слів до моделей, поріг вартості за кількістю токенів, подібність ембедінгу до промптів-зразків або дешева модель-класифікатор, що оцінює складність. Усі чотири патерни є в розділі про збірку вище й працюють без змін проти OpenAI, Ollama або vLLM.

Чи можна маршрутизувати між локальними моделями та хмарними API?

Так. Ollama (localhost:11434/v1) і vLLM обидва відкривають OpenAI-сумісні ендпоінти, тож той самий код роутера вказує на локальну модель для дешевого трафіку й на хмарне API для складного. Локальні токени коштують $0, але залізо й затримка лягають на вас. За цим патерном побудована більшість багатомодельних конфігурацій Claude Code.

Що таке семантична маршрутизація?

Семантична маршрутизація вбудовує кожен вхідний промпт у вектор і порівнює його з векторами промптів-зразків, надсилаючи запит тій моделі, якій належить найближчий кластер зразків. Вона обробляє розмиті, перефразовані запити користувачів, які пропускають правила за ключовими словами, ціною 50–150 мс плюс токени ембедінгу на запит. AWS виміряв для неї 0,10 секунди доданої затримки.

Яку затримку додає роутер на LLM-класифікаторі?

AWS виміряв 0,53 секунди доданої затримки для класифікації з допомогою LLM, проти 0,10 секунди для семантичної маршрутизації. Маршрутизація за правилами та за вартістю додає приблизно нуль, бо це чисті програмні шляхи. Якщо ваш продукт має жорсткий SLA на час відповіді, віддайте перевагу правилам, порогам вартості або ембедінгам, а класифікатор прибережіть для офлайн-завдань або черг.

Джерела

• Seifi, N. and Chugh, M. (2025-04-09). "Multi-LLM routing strategies for generative AI applications on AWS." AWS Machine Learning Blog. https://aws.amazon.com/blogs/machine-learning/multi-llm-routing-strategies-for-generative-ai-applications-on-aws/ (accessed July 30, 2026)
• AWS sample code: sample-multi-llm-dynamic-prompt-routing. https://github.com/aws-samples/sample-multi-llm-dynamic-prompt-routing (accessed July 30, 2026)
• LiteLLM documentation. https://docs.litellm.ai (accessed July 30, 2026)
• Anthropic pricing. https://www.anthropic.com/pricing (accessed July 30, 2026)
• OpenAI API pricing. https://openai.com/api/pricing (accessed July 30, 2026)
• ulab-uiuc LLMRouter. https://github.com/ulab-uiuc/LLMRouter (accessed July 30, 2026)
• Ong, I. et al. (2024). "RouteLLM: Learning to Route LLMs with Preference Data." arXiv:2406.18665. https://arxiv.org/abs/2406.18665 (accessed July 30, 2026)
• OpenRouter rankings. https://openrouter.ai/rankings (accessed July 30, 2026)