Wayfinder Router: как автоматически решать, когда хватит локальной LLM, а когда нужен облачный гигант — VogueTech

Что нового

Wayfinder Router — это офлайн‑роутер запросов между локальной и облачной LLM, который вообще не вызывает модели, чтобы принять решение. Он:

оценивает сложность промпта детерминированно за микросекунды;
работает полностью офлайн: без API‑ключей, без сетевых запросов, без «LLM‑судьи» поверх;
по умолчанию использует только структуру текста (длина, заголовки, списки, код, таблицы, ссылки);
может опционально учитывать лексические подсказки сложности (математика, «докажи», жёсткие ограничения), но они по умолчанию выключены;
к каждому запросу возвращает числовой «complexity score» от 0.0 до 1.0 и рекомендацию: отправить на локальную модель или в облако;
умеет работать как самостоятельный CLI‑инструмент, Python‑библиотека и как прокси‑шлюз с API, совместимым с OpenAI /v1/chat/completions.

Ключевой фокус — не максимальная точность, а предсказуемость и нулевые дополнительные расходы. Wayfinder не добавляет ещё один платный вызов модели, чтобы решить, куда отправить основной запрос.

Авторы прогнали Wayfinder на независимых бенчмарках (RouterBench, RouterArena) и на собственной «фронтирной» нагрузке. Важные цифры:

чисто структурный скорер — основной режим по умолчанию;
добавление лексики без калибровки даёт прирост только на части датасетов и на чужом трафике часто проигрывает даже простому подсчёту слов;
на RouterBench короткие, но сложные запросы (где сложность только семантическая) Wayfinder оценивает примерно как случайный роутер;
при калибровке на реальном трафике с включёнными лексическими признаками и правильно подобранным порогом авторы показывают: skill‑метрика меняется с −0.038 до +0.057 и даёт около 61% экономии стоимости относительно стратегии «всё в облако».

Как это работает

Базовая идея

Wayfinder стоит между вашим клиентом (IDE, чат, агент, CLI) и двумя (или больше) LLM‑бэкендами:

локальный сервер: Ollama, vLLM, LM Studio, llama.cpp или другой OpenAI‑совместимый /v1;
облачный провайдер: OpenAI (GPT‑4o, GPT‑4o‑mini и т. п.), Anthropic (Claude), Google Gemini, Groq, Together, OpenRouter, Fireworks, DeepSeek и др.

Клиент отправляет запрос на шлюз Wayfinder по стандартному OpenAI‑интерфейсу /v1/chat/completions. Wayfinder:

Сканирует промпт.
Считает набор признаков:
- число слов;
- количество заголовков;
- число элементов списков;
- наличие и объём кода;
- ссылки, таблицы, шаги, форматирование;
- (опционально) слова‑маркеры сложных задач: доказательства, «step‑by‑step», ограничения, математические символы и т. д.
Преобразует их в скалярный score от 0.0 до 1.0.
Сравнивает score с порогом или с наборами порогов для нескольких уровней.
Решает, к какому бэкенду отправить запрос.
Возвращает ответ клиенту, добавляя HTTP‑заголовки x-wayfinder-router-model, x-wayfinder-router-score и x-wayfinder-router-mode.

Важный момент: Wayfinder не спрашивает никакую LLM «насколько это сложно». Решение — чисто вычислительное и детерминированное. Один и тот же промпт при одном и том же пороге всегда пойдёт в одно и то же место.

Режимы маршрутизации

В конфиге wayfinder-router.toml есть три режима, которые работают по приоритету: classifier > tiers > threshold.

Binary threshold (по умолчанию) — один порог между «дёшево» и «дорого»:

[routing]
threshold = 0.6
weights = { word_count = 4.0, list_item_count = 2.5 }

score < threshold → локальная модель;
score ≥ threshold → облачная.

Порог можно переопределять:

для одного запуска: --threshold N;
через переменную окружения: WAYFINDER_ROUTER_THRESHOLD.

Tiered routing — несколько диапазонов сложности и несколько моделей:

[[routing.tiers]]
min_score = 0.0
model = "llama-3b"

[[routing.tiers]]
min_score = 0.3
model = "llama-70b"

[[routing.tiers]]
min_score = 0.6
model = "claude-cloud"

Classifier — многоклассовая логистическая регрессия по тем же признакам. Wayfinder подбирает веса под ваши данные через команду calibrate и сохраняет в конфиг. Обучение идёт офлайн, детерминированным L2‑регуляризованным Newton/IRLS, за несколько итераций.

Структурные и лексические признаки

По умолчанию Wayfinder использует только структуру промпта. Есть и лексические признаки — количество терминов рассуждения, математических символов, слов, задающих ограничения. Но они выключены, потому что на независимых датасетах без калибровки к вашей лексике они дают слабый и плохо переносимый выигрыш:

ловят примерно 20% новых сложных промптов;
при этом уступают даже простой базовой метрике по количеству слов.

Авторы предлагают включать их только после калибровки на своём трафике, поднимая веса этих признаков и подбирая новый порог.

Как Wayfinder работает с ключами

Wayfinder сам ключи не хранит:

в конфиге вы указываете только имя переменной окружения, например api_key_env = "OPENAI_API_KEY";
при запросе шлюз читает значение переменной и отправляет его как Bearer‑ключ в апстрим;
ключ нигде не записывается на диск.

Если не хочется класть ключ прямо в окружение, можно задать команду, которая подтянет секрет из хранилища при старте шлюза:

api_key_cmd = "op read op://Private/OpenAI/credential"

Поддерживаются 1Password (op), macOS Keychain (security), Linux secret-tool, pass / gopass, HashiCorp Vault, AWS Secrets Manager, Bitwarden (bw), Doppler, Google Cloud Secrets и любой CLI, который печатает секрет в stdout.

Команда wayfinder-router doctor сканирует окружение, находит доступные инструменты и подсказывает конкретную строку, которую можно добавить в конфиг.

Что это значит для вас

Когда Wayfinder полезен

Гибридный стек: локальная LLM + облачный «фронтир»
Вы запускаете у себя локальную модель (через Ollama, vLLM, LM Studio, llama.cpp) и иногда подключаете дорогие модели вроде GPT‑4o или Claude 3.5. Wayfinder позволяет:

отдать локальной модели все простые задачи: саммари, исправление опечаток, лёгкие запросы в духе «объясни это проще»;
автоматически отправить сложные промпты (длинные инструкции, многоступенчатое рассуждение, тяжёлый код) в облако;
сократить расходы на облако без ручного микроменеджмента и без отдельного «классификатора‑LLM».

Оффлайн‑решения и строгие требования к приватности
Скорер сложности работает полностью офлайн и не требует ни ключей, ни сети. Можно:

локально оценивать сложность промптов внутри корпоративной среды;
не отправлять «лишние» запросы наружу даже для принятия решения о маршрутизации;
интегрировать Wayfinder как библиотеку прямо в бэкенд, где промпты уже есть.

Оптимизация стоимости и latency в продуктиве
Wayfinder стоит как прозрачный шлюз перед уже существующими клиентами:

вы меняете только base_url на стороне клиента;
не переписываете код под конкретного провайдера;
получаете в каждом ответе заголовки с информацией, какая модель реально ответила и какой был complexity score.

Это удобно для мониторинга, A/B‑тестов и последующей калибровки порога.

Калибровка под свой трафик
Если у вас есть логи запросов и ручные метки, в каких случаях достаточно локальной модели, а когда нужен облачный уровень качества, Wayfinder умеет:

читать JSONL с полями {"text": ..., "label": ...};
подбирать порог или целую схему tiered routing под ваши реальные данные;
учитывать стоимость разных моделей при поиске оптимума.

Где у Wayfinder слабые места

Чисто семантическая сложность
Если промпт выглядит коротким и простым, но задача внутри тяжёлая, Wayfinder не увидит этого по структуре. Примеры:

«Что такое 100‑е простое число?»;
короткий, но сложный фрагмент кода с тонкой ошибкой;
лаконичная формулировка сложной математической задачи.

На таких кейсах семантический роутер на базе LLM‑классификатора будет работать лучше.

Короткие, но сложные запросы в бенчмарках
Авторы честно пишут: на коротких, но сложных задачах из RouterBench Wayfinder показывает себя примерно как случайное решение. Если ваш трафик похож на этот тип задач, выгода будет ограниченной.
Требуется минимальная инженерия для максимальной выгоды
Из коробки структурный скорер даёт базовую экономию. Но чтобы выжать максимум:

нужно собрать небольшой датасет с вашими промптами и метками;
прогнать calibrate с учётом стоимости моделей;
возможно, включить и откалибровать лексические признаки.

Доступность в России
Wayfinder сам по себе — локальный инструмент на Python, его можно установить без VPN. Но он маршрутизирует запросы к внешним LLM через OpenAI‑совместимые API. Для работы с OpenAI, Anthropic, Google Gemini и другими зарубежными провайдерами обычно понадобится VPN или прокси, а также соблюдение юридических ограничений.

Практические сценарии

Разработчики и ML‑инженеры: повесить Wayfinder как шлюз перед Open WebUI, LibreChat, IDE‑плагинами (Cursor, Continue, Cline, Zed, JetBrains) и получить «умный auto‑режим» без переписывания кода.
Команды, считающие деньги в облаке: включить Wayfinder перед GPT‑4o / Claude и локальной Llama, откалибровать порог под свою метрику качества и снизить чек на 50–60% на типичных задачах «саммари и правки».
Корпоративные решения: использовать только офлайн‑скорер для внутренней маршрутизации между несколькими on‑prem LLM.

Где Wayfinder не нужен:

если вы используете только одну модель (например, только GPT‑4o) и не планируете добавлять локальный слой;
если ваши задачи почти всегда сложные и вы и так отправляете всё в «тяжёлую» модель;
если вам принципиально нужна семантическая оценка сложности, а не структурная.

Место на рынке

Wayfinder конкурирует не с LLM, а с другими роутерами, которые решают, куда отправить запрос. В исходном сравнении фигурируют:

Wayfinder — детерминированный структурный скорер, полностью офлайн, умеет self‑host и калибровку на своих данных.
RouteLLM — роутер на основе обученного классификатора по данным предпочтений, решение принимает сама модель; требует модельных вызовов, но тоже можно разворачивать у себя и переобучать.
NotDiamond / Martian — обученные и размещённые у провайдера решения, без self‑host; решение принимает удалённая модель на стороне платформы.
OpenRouter (Auto) — встроенный роутер в OpenRouter, целиком хостится у них, без локального варианта.
LiteLLM — прокси‑слой к провайдерам; сам по себе не делает маршрутизацию по сложности, но умеет объединять разных поставщиков.

Ключевые отличия Wayfinder:

Никаких дополнительных модельных вызовов.
- У большинства роутеров решение — это ещё один запрос к LLM‑классификатору или внешнему API.
- Wayfinder решает по структуре и тексту, поэтому дополнительная стоимость и задержка маршрутизации практически нулевая.
Полный офлайн‑режим.
- Скорер и калибратор не ходят в сеть и не требуют ключей.
- В продакшене сеть нужна только шлюзу для общения с реальными LLM.
Детерминизм.
- При одинаковом пороге один и тот же промпт всегда идёт в один и тот же бэкенд.
- У LLM‑классификаторов решение может слегка дрейфовать из‑за стохастики.

Где другие сильнее:

роутеры на базе LLM‑классификаторов лучше справляются с семантической сложностью, особенно на коротких промптах без структурных подсказок;
hosted‑решения вроде NotDiamond и OpenRouter Auto снимают с вас всю операционную нагрузку, если вы не хотите держать у себя конфиги, калибровку и мониторинг.

Если нужны конкретные проценты по скорости или качеству против RouteLLM или NotDiamond, их стоит смотреть в опубликованных бенчмарках RouterBench/RouterArena, которые авторы предлагают использовать для оценки.

Установка

Базовая установка скорера и CLI

pip install wayfinder-router

Вы получаете:

скорер сложности;
CLI wayfinder-router;
Python API;
терминальный чат chat.

Шлюз (gateway) с OpenAI‑совместимым API

pip install "wayfinder-router[gateway]"

Это добавляет HTTP‑шлюз, который можно поставить перед любым клиентом, говорящим с OpenAI API.

Локальный UI для калибровки и объяснения

pip install "wayfinder-router[ui]"

Полная установка

pip install "wayfinder-router[all]"

Это включает и шлюз, и UI поверх базовой установки.

Как запустить

Быстрый тест в терминале (без ключей и моделей)

uvx wayfinder-router chat --dry-run  # zero install, zero keys
# или:
pip install wayfinder-router && wayfinder-router chat

В терминальном чате вы увидите для каждого сообщения:

куда оно было направлено (● LOCAL / ◆ CLOUD);
структурный score и объяснение (/why);
накопленную экономию относительно стратегии «всё в облако».

Полезные команды внутри чата:

/init — настроить модели, не выходя из чата;
/route / /local / /cloud — принудительно задать маршрут для одного хода;
/threads — список диалогов, которые сохраняются между сессиями.

В браузере: web‑чат с живым порогом

pip install "wayfinder-router[gateway]"
wayfinder-router webchat --dry-run  # откроет http://127.0.0.1:8088/demo

Команда webchat — тонкая оболочка над serve (шлюз и его /demo‑страница). Полезные флаги:

--no-open — не открывать браузер автоматически;
--port — задать порт;
--host 0.0.0.0 — слушать на всех интерфейсах;
--dry-run — показывать только решения о маршрутизации без вызова моделей.

В веб‑чате вы видите для каждого сообщения:

куда оно ушло (local vs cloud);
complexity score и вклад признаков;
экономию стоимости против стратегии «всё в облако».

Чтобы получить реальные ответы от моделей, нужно инициализировать конфиг:

wayfinder-router init           # создаст базовый hybrid-пресет
wayfinder-router doctor         # проверит, что ключи доступны

Поддерживаемые API

Wayfinder пересылает запросы на OpenAI‑совместимый /v1/chat/completions. Если провайдер поддерживает этот формат и Bearer‑ключ, он работает «из коробки».

Поддерживаются в том числе:

Groq;
Together;
OpenRouter;
Fireworks;
DeepSeek;
локальные серверы: vLLM, LM Studio, llama.cpp;
любые другие OpenAI‑совместимые endpoints.

Для Claude Code, который использует Anthropic Messages API, шлюз умеет поднимать адаптер POST /v1/messages, который переводит формат Anthropic ⇄ OpenAI в обе стороны.

Быстрый старт: шлюз перед моделями

1. Сгенерировать конфиг

pip install "wayfinder-router[gateway]"
wayfinder-router init                  # базовый hybrid-пресет (локальный Ollama → Anthropic)
wayfinder-router init --preset openai  # два уровня OpenAI (gpt-4o-mini → gpt-4o)
wayfinder-router init --preset gemini  # два уровня Gemini (gemini-2.5-flash → gemini-2.5-pro)
wayfinder-router init --interactive    # пошаговый выбор провайдеров и моделей

Или описать всё вручную в wayfinder-router.toml:

[routing]
threshold = 0.5  # ниже -> local, от/выше -> cloud

[gateway.models.local]
base_url = "http://localhost:11434/v1"
model = "llama3.2"

[gateway.models.cloud]
base_url = "https://api.openai.com/v1"
model = "gpt-4o"
api_key_env = "OPENAI_API_KEY"  # имя переменной окружения с ключом
# api_key_cmd = "op read op://Private/OpenAI/credential"  # опционально: подтянуть ключ из хранилища

2. Настроить ключи и проверить конфиг

export ANTHROPIC_API_KEY=sk-...  # или OPENAI_API_KEY — в зависимости от конфига
wayfinder-router doctor          # ✓/✗ по каждой модели — установлен ли ключ

3. Запустить шлюз

wayfinder-router serve --port 8088

Проверить, что всё живо:

curl -s localhost:8088/healthz
# {"status":"ok","models":["cloud","local"]}

curl -s -D - -o /dev/null http://localhost:8088/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}' \
  | grep -i x-wayfinder-router
# x-wayfinder-router-model: local
# x-wayfinder-router-score: 0.00

Если бэкенды ещё не подключены, можно запустить в режиме «только решения»:

wayfinder-router serve --dry-run

В этом случае шлюз отвечает только решением о маршрутизации, не вызывая апстрим‑модели.

4. Переключить существующий клиент

На стороне клиента достаточно сменить base_url на адрес шлюза. Пример с официальным клиентом OpenAI:

client = openai.OpenAI(
    base_url = "http://localhost:8088/v1",
    api_key = "unused"  # ключ здесь не нужен, он у шлюза
)

resp = client.chat.completions.create(
    model = "auto",  # Wayfinder сам решит, куда отправить
    messages = [{"role": "user", "content": "..."}]
)

Каждый ответ будет содержать:

x-wayfinder-router-model — какой бэкенд ответил (local/cloud или конкретное имя);
x-wayfinder-router-score — complexity score;
x-wayfinder-router-mode — кто принял решение (scored / pinned / threshold-override);
x-wayfinder-router-request-id — ID запроса.

Оценка сложности из CLI

Можно напрямую оценить сложность промпта и рекомендованный маршрут:

echo "Summarise this paragraph in one sentence." | wayfinder-router route -

# Вывод:
# Recommended Model: local
# Complexity Score: 0.00 (mode: tiered)
# Tiers: >= 0.00 local <- >= 0.50 cloud
# Contributing Features:
#   Word Count: 6
#   ...

Для машинного потребления добавьте --json:

{
  "schema_version": "3",
  "score": 0.66,
  "recommendation": "cloud",
  "mode": "tiered",
  "features": {
    "word_count": 545,
    "heading_count": 12,
    "reasoning_term_count": 3,
    "...": 0
  },
  "tiers": [
    {"min_score": 0.0, "model": "local"},
    {"min_score": 0.5, "model": "cloud"}
  ]
}

Этот формат удобно использовать в собственных агентах или оркестраторах, которые сами решают, какую модель вызывать.

Калибровка на своих данных

Порог — это приближение сложности. Чтобы он отражал реальную границу между «локальная модель справляется» и «нужен облачный уровень», Wayfinder предлагает явную калибровку.

Исходные данные — JSONL с полями:

{"text": "...", "label": "local"}
{"text": "...", "label": "cloud"}

Команды калибровки:

# Подбор бинарного порога
wayfinder-router calibrate data.jsonl --mode threshold

# Многоуровневая маршрутизация (несколько моделей)
wayfinder-router calibrate data.jsonl --mode tiers

# Логистический классификатор, результат сразу в конфиг
wayfinder-router calibrate data.jsonl --mode classifier --out wayfinder-router.toml

Вы можете оптимизировать порог не только по accuracy, но и по стоимости:

wayfinder-router calibrate data.jsonl \
  --mode threshold \
  --objective knee \
  --costs local=0.2,cloud=1.0

Опции:

--objective knee — автоматически ищет «колено» кривой, максимизируя quality-recovered × cost-saved. Это защищает от сценария, когда оптимум по accuracy всегда выбирает дорогую модель.
--objective cost-quality --target-savings X — зафиксировать минимальный уровень экономии и искать порог под него.

Чтобы сразу обучать с кастомными весами признаков (например, включить лексические), можно задать:

wayfinder-router calibrate data.jsonl \
  --mode threshold \
  --objective knee \
  --costs local=0.2,cloud=1.0 \
  --weights reasoning_term_count=5,math_symbol_count=3,constraint_term_count=1.5

Стоимость (costs) влияет только на выбор порога и отчёт на /metrics. На каждом конкретном запросе решение остаётся детерминированным и бесплатным.

Тонкая настройка одного запроса

Глобальный конфиг задаёт поведение по умолчанию, но клиент может переопределить маршрут для одного вызова, не ломая OpenAI‑совместимый протокол.

Управление через поле `model`

model="auto" — отдать решение Wayfinder.
model="local" / model="cloud" — жёстко закрепить запрос за конкретным бэкендом.
model="prefer-local" / model="prefer-hosted" — закрепить за нижним или верхним уровнем роутера (есть алиас prefer-cloud → prefer-hosted).

Пример:

# Жёстко отправить в облако, независимо от score
client.chat.completions.create(
    model = "cloud",
    messages = [...]
)

Временный сдвиг порога заголовком

Для бинарного роутера можно двинуть порог только на один запрос, не меняя конфиг:

client.chat.completions.create(
    model = "auto",
    messages = [...],
    extra_headers = {
        "X-Wayfinder-Threshold": "0.8"
    }
)

Ответ добавит заголовок x-wayfinder-router-mode: threshold-override, чтобы было видно, что решение принял не базовый порог.

Интеграция с чат‑UI без форков

Wayfinder использует поле model как директиву маршрутизации. Любой OpenAI‑совместимый чат‑клиент может использовать это без изменений кода.

Шлюз на GET /v1/models отдаёт список доступных «моделей», включая:

auto;
prefer-local;
prefer-hosted;
имена закреплённых бэкендов (local, cloud, и т. п.).

Дальше стандартный UI превращает свой выпадающий список моделей в выбор стратегии маршрутизации для диалога.

Примеры:

LibreChat — скопировать examples/librechat.yaml и examples/docker-compose.override.yml в проект, запустить docker compose up и выбрать endpoint «Wayfinder».
Open WebUI — добавить OpenAI‑подключение, указывая шлюз Wayfinder как base_url. Клиент сам увидит все роутинговые опции по GET /v1/models.

Если нужен именно ползунок порога в UI на диалог, разработчики предлагают отдельный форк wayfinder-chat, но базовый сценарий работает с любым совместимым интерфейсом.

Наблюдение за маршрутизацией

Wayfinder не навязывает отдельную панель управления — он встраивается в уже существующие инструменты. Управление и наблюдение распределены по нескольким поверхностям:

Model dropdown в вашем клиенте — выбор режима (auto / prefer-local / prefer-hosted / pinned endpoint).
HTTP‑заголовки ответа — где оказался каждый запрос и почему (x-wayfinder-router-model, x-wayfinder-router-score, x-wayfinder-router-mode, x-wayfinder-router-request-id).
Debug‑поле в теле ответа — опционально включается заголовком X-Wayfinder-Debug: true.
Dashboard шлюза — GET /router (и GET /router/recent в JSON) показывает последние решения, счётчики по моделям, распределение score. В дашборде нет текста промптов, только метаданные.

Отдельно есть консольный UI wayfinder-router ui для калибровки и настройки — он не трогает продакшн‑трафик.

Обучение на обратной связи

Wayfinder предлагает замкнутый цикл «обучения на себе»: сначала вы вручную оцениваете, когда локальная модель «хватает», потом роутер начинает делать это сам, а вы периодически его переобучаете.

A/B‑онбординг

Для старта есть команда onboard, которая берёт список промптов, прогоняет их через два бэкенда и спрашивает, какой ответ был «достаточно хорошим».

wayfinder-router onboard prompts.jsonl --arms local,cloud --calibrate > wayfinder-router.toml

Сравнение ответов пишется в stderr.
С флагом --calibrate итоговая конфигурация маршрутизации выводится в stdout.
Каждое решение добавляет строку в лог обратной связи {"text", "label"} — это тот же формат, который потом читает calibrate.

Обратная связь в продакшене

Когда роутер уже работает автоматически, можно продолжать собирать обратную связь:

curl localhost:8088/v1/feedback -d '{"text": "...", "label": "cloud"}'

Дальше периодически запускать переобучение:

wayfinder-router recalibrate            # лог -> calibrate -> обновить конфиг
wayfinder-router recalibrate --min-labels 50  # не трогать конфиг, пока мало сигналов

Перекалибровка:

переписывает только секцию [routing] в конфиге;
сохраняет блоки [gateway] с описанием бэкендов;
подхватывается работающим шлюзом на лету, без рестарта.

Модели для сравнения в онбординге запускаются только в слое шлюза (там, где уже есть ключи). Скорер сложности и калибратор при этом остаются офлайн и не видят секреты.

Деплой и интеграция в продакшене

CLI, онбординг и UI — инструменты для операторов и настройки. В бою промпты должны идти через шлюз или библиотеку, рядом с кодом, который уже работает с LLM.

Шлюз как сервис или сайдкар

Пример через Docker:

docker build -t wayfinder-router . && \
  docker run -p 8088:8088 -v "$PWD/data:/data" wayfinder-router

# или docker compose:
# docker compose up gateway  (см. docker-compose.example.yml)

Дальше любой клиент, который умеет говорить с OpenAI API, может просто поменять base_url:

client = openai.OpenAI(
    base_url = "http://localhost:8088/v1",
    api_key = "unused"
)

Это касается:

LangChain, LlamaIndex, CrewAI, AutoGen, OpenAI Agents SDK, Vercel AI SDK;
CLI‑инструментов вроде aider или Copilot CLI;
редакторов и IDE‑плагинов (Cursor, Continue, Cline, Zed, JetBrains);
чат‑UI (Open WebUI, LibreChat, Jan);
прокси‑слоёв вроде LiteLLM (через OPENAI_BASE_URL / OPENAI_API_KEY).

Wayfinder не меняет протокол, он просто прозрачно решает, какой бэкенд должен отвечать на каждый конкретный запрос.