В этом разборе
Batch является единицей выбора провайдера, а запросы — единицами результата; повторная отправка создаёт отдельные задание и решение.
Batch API OpenRouter определяет одного провайдера заданию после применения клиентских ограничений. Это делает batch единицей маршрутизации, хотя результаты возвращаются отдельным запросам. Многопровайдерный шлюз не означает независимого переключения каждой строки принятой асинхронной работы. Для приложения нужно сохранить различие между выбором исполнителя всего задания и получением исхода его отдельных элементов после обработки.
Объявленная единица маршрутизации — batch
Запуск 22 сентября 2026 года устанавливает одного провайдера для каждого batch. По умолчанию выбирается самый дешёвый допустимый batch-endpoint после настроек провайдеров, политики данных и BYOK. Выбор относится к опубликованному продукту асинхронной обработки, а не автоматически к каждому синхронному адресу, связанному с тем же названием модели.
Это два решения: ограничения определяют кандидатов, выбор назначает одного заданию. Глобальное имя модели не доказывает одинаковую поддержку batch каждым маршрутом или его допустимость клиентской политике. Поэтому полезный анализ сохраняет и применённое множество, и окончательный объект исполнения вместо одного общего утверждения о наличии модели в каталоге шлюза.
Отдельный результат не меняет выбор провайдера
Анонс описывает результаты запросов: проблемным строкам не обязательно аннулировать остальные. Такая гранулярность полезна приложению с большим набором работы. Оно может учитывать завершённые элементы отдельно от ошибок, сохраняя соответствие исходной задаче и не предполагая, что вся коллекция обязана иметь одинаковый прикладной исход после исполнения у одного оператора.
Её нельзя смешивать с маршрутизацией строк. Клиент изучает результаты отдельно при едином провайдере принятого batch. Отождествление единиц создаёт неверные ожидания отказа и повтора. Приложению нужно понимать, какой уровень результата оно получает и на каком уровне принималось решение, задающее фактический путь обработки всех элементов соответствующего задания.
Ранние контроли дали контекст политики
Workspaces 22 апреля 2026 года установили ограниченные доступ и политику. Response caching 30 апреля ввёл другую оптимизацию повторных запросов. Ни одна ранняя функция не определяет единицу позднего batch. Они дают окружающую историю шлюза, сохраняющую самостоятельность нового временного и организационного способа отправки работы на исполнение.
Наша причинная гипотеза — асинхронному планированию полезен понятный владелец исполнения уровня задания. Привязка к допустимому провайдеру даёт устойчивый предмет окну и результатам. Это интерпретация проекта, а не раскрытый внутренний замысел разработчиков. Источники устанавливают свойства и последовательность, позволяя предложить объяснение без выдумывания закрытого алгоритма или инженерных обсуждений компании.
Сохраняем реестр единиц исполнения
Иллюстративный реестр предотвращает переход предположений между уровнями:
| Единица | Связанное решение или подтверждение |
|---|---|
| Отправка | Клиентские ограничения и выбранная модель |
| Принятый batch | Исполняющий задание провайдер |
| Отдельный запрос | Его результат или ошибка |
| Последующая отправка | Новое решение с её применимыми настройками |
Последняя строка существенна при повторной отправке незавершённой работы. Позднее задание является другим решением, а не доказательством незаметной смены провайдера первоначального batch. Клиенту следует сохранять связь рабочих элементов с пытавшимися их исполнить заданиями. Это позволяет объяснить исход без смешения первоначального выбора и последующего прикладного решения о новом запуске.
Оцениваем условия задания в их масштабе
Историческое дополнение — асинхронная многозапросная работа внутри многопровайдерной платформы. Гибкость выбора действует до принятия, а результаты строк помогают последующей обработке. Маршрутизация провайдеров объясняет допустимость и выбор. Маршрутизация и fallback раскрывают границы ролей. Точность Batch API требует отдельных связанных объектов: задания, провайдера и результата, без подмены единицы маршрутизации единицей прикладного учёта.