Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

Спасибо за глубокий комментарий. Согласен, окружение тестирования (harness) сильно влияет на результат. Независимый black-box набор - правильный путь, особенно для threshold crypto, где «прошло демо» не гарантирует корректность при сбоях. В статье эта тема не раскрыта, вы правы

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

Верно, на скрине видно, что models параметр именно для автоматической замены при сбое, а не для параллельных вызовов. В статье описан кастомный fallback поверх API, не встроенный механизм

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

Вы правы, я смешал два разных сценария. Fallback - это последовательная подмена недоступной модели, а не параллельный опрос с агрегацией. Для параллельного опроса и суммаризации нужна отдельная логика, OpenRouter в базовом API этого не даёт, только через надстройку. Цена и выбор конкретной модели тоже важные ограничения, согласен.

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

Верно, fallback - это последовательный перебор, одна модель не ответила, пробуем следующую. Гарантия не абсолютная, если весь пул моделей недоступен, пользователь всё равно получит ошибку. В текущей реализации цикл проходит по списку один раз. Можно улучшить, либо использовать встроенный fallback OpenRouter (он пробует внутри себя), либо сделать цикл с повторным проходом и задержкой, либо добавить параллельный запрос к двум моделям и брать первый успешный ответ. Но это уже усложнение под конкретные сценарии

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

Спасибо, все ок ✌️

У меня напротив эмодеформация, когда желательно разбавить лаконичность субъектными штучками)

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

В проекте используется OpenRouter, он сам по себе уже является агрегатором моделей и поддерживает fallback между ними на уровне API. То есть описанная в статье логика - надстройка поверх его возможностей, а не замена. Но согласен, OpenAI Agents SDK тоже рабочий вариант для более сложной маршрутизации

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

Да, из статьи это следует прямо. Backend уже пробует разные модели при сбое, ничего не мешает расширить логику, отправлять запрос параллельно в несколько моделей, сравнивать результаты, выбирать лучший или агрегировать. Вопрос только в цене и времени ответа. OpenRouter, кстати, даёт такую возможность через routing и fallback на уровне платформы

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

Верно, что заметили. Должно быть «не дать доступ». У OpenRouter особенность - модели, которые числятся в /api/v1/models с фильтром free, не всегда реально доступны в момент запроса. Некоторые отдают ошибку при попытке вызова. Отсюда и логика с fallback - пробуем одну, не дало доступ, идём к следующей

Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера

У меня стиль мышления близок к ИИ-шному, не первый раз сталкиваюсь с таким вопросом. А так - да, кто ж сейчас не оптимизирует свои ресурсы через умных помощников? Статья написана на основе собственной кодовой базы и продовых сценариев, форма подачи какая есть

URL как источник правды в Next.js App Router

Да, справедливо. В статье я разбирал сценарий, где searchParams сознательно участвует в серверном fetch, поэтому изменение q действительно приводит к новой серверной навигации для затронутого сегмента. Но это не полный reload документа, в App Router навигация остаётся client-side transition, shared layouts сохраняются, а обновляется только нужная часть маршрута. Если реакция нужна полностью локальная и без нового серверного прохода, такое состояние лучше не поднимать в URL. Или разделять черновой ввод и подтверждённый фильтр. Про эту развилку тоже планирую написать позже.

Как собрать платный AI-микро-SaaS (Next.js + Django + ЮKassa + Web Stories) и не застрять в пет-проекте

Спасибо) ✌️
Сейчас сфокусирован на своих учебных и продуктовых проектах вокруг AI-чатов, микросервисов и платёжных решений. Готов обсудить формат сотрудничества, если есть конкретная концепция под мой стек (Next.js + Django) и понятная модель взаимодействия.

Мой Telegram: @Lemon1964 — пиши, если актуально