В этом материале
HTTP 200 подтверждает начало ответа, но не завершённую генерацию. Клиент должен читать события до конца и отдельно обрабатывать ошибку, частичный результат и учёт выполнения.
OpenRouter может начать ответ с HTTP 200, а затем передать ошибку внутри потока. После отправки заголовков HTTP-статус уже нельзя заменить. Поэтому приложение, которое считает любой 200 завершённым успехом, способно показать пользователю обрезанный результат и записать неверную статистику работы.
Разбор касается поведения API и клиента по официальным материалам на 1 ноября 2026 года. Конкретный формат события зависит от выбранного протокола.
Разделите начало и завершение
Errors and Debugging описывает ошибки до и после начала передачи. До старта клиент может получить обычный неуспешный статус. Позднее отказ приходит в теле ответа или SSE-событии, и его нужно прочитать.
Для приложения полезны отдельные состояния: ожидание, поток начался, получен полезный фрагмент, завершено, ошибка, отменено. Такой автомат состояний понятнее одного логического поля success, выставленного после получения заголовков.
Обрабатывайте формат выбранного API
Streaming OpenRouter описывает служебные события и завершение. Для Chat Completions, Responses и других протоколов структура отличается. Парсер SSE решает вопрос границ событий, но прикладная логика всё равно должна распознавать их смысл.
Не пропускайте неизвестные события без следа в тестовом окружении. Их можно безопасно классифицировать и сохранить тип для анализа, не записывая весь пользовательский текст. Иначе обновление формата способно незаметно сломать определение завершения.
Решите судьбу частичного текста
| Результат операции | Возможное состояние интерфейса |
|---|---|
| Штатное завершение | Полный ответ готов |
| Ошибка после нескольких фрагментов | Частичный ответ с понятным сообщением |
| Отмена пользователем | Сохранённое или удалённое содержимое по правилам приложения |
| Неизвестное окончание соединения | Требуется проверка, успех не подтверждён |
Условная система формирует отчёт с выводом в конце. Обрезанное начало нельзя автоматически сохранить как завершённый документ. Для последующей обработки должен оставаться признак неполноты, даже если текст выглядит грамотно.
Повторяйте с новой границей результата
Не приклеивайте ответ второй генерации к первой незаметно для пользователя. Модель может выбрать другую формулировку, план или данные. При повторе сохраняйте связь попыток, но различайте их содержимое и завершение.
Для tool calling это особенно важно: частично полученный вызов инструмента не разрешает выполнение. Дождитесь целой структуры, проверьте аргументы и примените ограничения приложения. Если внешнее действие уже могло произойти, повтор требует собственной проверки состояния.
Проверьте сценарий без нагрузки на модель
Создайте локальную запись тестовых SSE-событий: несколько частей текста, затем отказ; обычное завершение; закрытие без итогового события. Передайте её клиентскому обработчику и проверьте состояния. Так можно проверить парсер и интерфейс без многократных реальных модельных вызовов.
После этого выполните небольшой согласованный интеграционный тест. Сохраните идентификатор, время до первого полезного текста и итоговое состояние. В эксплуатационном отчёте отдельно считайте полные ответы, ошибки до начала и частичные результаты.
Далее пригодятся streaming-клиент и tool calling. Готовность узла оценивается по завершённым задачам и поведению при сбое, а не только по числу успешных HTTP-соединений.