Как правильно обрабатывать streaming SSE в OpenRouter API

Этот сценарий полезен разработчику backend, владельцу чат-бота или команде автоматизации, которой нужен наблюдаемый результат. Ключевой принцип: проверять не только текст модели, но и метаданные маршрутизации, структуру ответа, учет токенов и негативный путь. HTTP 200 означает, что транспорт сработал; он не доказывает, что модель соблюла бизнес-формат.

Подтвержденные факты

• Поток включается параметром stream:true.
• Текст приходит в choices[0].delta.content.
• Строки, начинающиеся с двоеточия, являются SSE-комментариями и не должны декодироваться как JSON.
• Финальный chunk содержит usage, а data: [DONE] завершает поток.

Параметры OpenRouter задаются на двух разных уровнях. model, messages, response_format относятся к запросу генерации. Объект provider управляет выбором upstream-endpoint. Плагины маршрутизаторов передаются в plugins. Не переносите поле из одного уровня в другой: JSON останется синтаксически корректным, но настройка может не дать ожидаемого эффекта.

Пошаговая настройка

1. Сформулируйте проверяемый результат. Для запроса «как включить streaming OpenRouter API» не принимайте субъективное «вроде работает»: заранее запишите ожидаемый формат и признаки ошибки.
2. Создайте отдельный API-ключ для тестового приложения и передавайте его через переменную окружения OPENROUTER_API_KEY. Не вставляйте секрет в клиентский JavaScript, мобильный APK, скриншот или репозиторий.
3. Соберите минимальный запрос из примера ниже. Он изолирует именно механизм статьи; дополнительные фреймворки, ретраи и бизнес-логику добавляйте после первого успешного ответа.
4. Отправьте запрос на https://openrouter.ai/api/v1/chat/completions. При ошибке сначала сохраните HTTP-код, тело ответа и request id, а уже затем решайте, допустим ли повтор.
5. Сравните результат с контрольным ожиданием: Интерфейс постепенно получает связный текст, комментарии не вызывают JSONDecodeError, а после финального события сохранены usage и полный собранный ответ.
6. Прогоните положительный и отрицательный тест. Отрицательный тест должен доказать, что приложение не принимает невалидный формат, запрещенную модель или ослабленную политику после fallback.
7. Только после этого добавьте таймаут, ограниченный retry с jitter, метрики и безопасное логирование. Повторяйте лишь идемпотентные операции или используйте собственный ключ идемпотентности.

Минимальный рабочий пример

buffer = ""
for chunk in response.iter_content(1024, decode_unicode=True):
    buffer += chunk
    while "\n" in buffer:
        line, buffer = buffer.split("\n", 1)
        line = line.strip()
        if not line or line.startswith(":"): continue
        if not line.startswith("data: "): continue
        payload = line[6:]
        if payload == "[DONE]": break
        event = json.loads(payload)
        text += event.get("choices", [{}])[0].get("delta", {}).get("content", "")
        if event.get("usage"): usage = event["usage"]

Значения в угловых скобках — не реальные идентификаторы. Их нужно заменить slug из актуальной страницы модели OpenRouter. Такой шаблон безопаснее статьи с быстро устаревающим списком моделей или провайдеров. Токен доступа в пример намеренно не включен.

Готовый тестовый промпт

Задача: проверь конфигурацию «как включить streaming OpenRouter API».
Верни только результат в указанном формате, без вступления.
Если входных данных недостаточно, верни явную ошибку INPUT_MISSING и перечисли недостающие поля.
Не придумывай факты и не изменяй ограничения запроса.

Промпт нужен для проверки дисциплины ответа, но он не заменяет параметры API. Например, просьба «верни JSON» не дает тех же гарантий, что response_format; фраза «не сохраняй данные» не заменяет ZDR-фильтр; просьба «выбери быструю модель» не заменяет настройки маршрутизации. Управляющие ограничения следует задавать структурированными полями запроса, а затем повторно проверять в приложении.

Контрольный вход и ожидаемый результат

Контрольный вход уже встроен в пример. Не меняйте одновременно prompt, модель и маршрутизацию: иначе невозможно понять причину различий. Сначала выполните запрос пять раз с одной конфигурацией, сохраните HTTP-код, id, model, finish_reason, usage и длительность. Затем измените ровно один параметр и повторите серию.

Ожидаемый результат: Интерфейс постепенно получает связный текст, комментарии не вызывают JSONDecodeError, а после финального события сохранены usage и полный собранный ответ.

Если текст формально правильный, но отсутствует model или usage, не подменяйте их нулями без отдельного статуса. Различайте «ноль», «поле не поддерживается» и «финальное событие не было прочитано». Для JSON-ответов применяйте декодер и схему. Для обычного текста проверяйте длину, обязательные маркеры и отсутствие служебных фрагментов.

Критерии приемки

• буфер сохраняет неполные строки
• keep-alive пропускаются
• DONE завершает цикл
• частичный ответ помечается при обрыве
• usage записан после финала