В этом материале
Пустой visible content не доказывает отсутствие генерации. Лимит ответа и причина length проверяются вместе с семантикой модели и usage.
Короткий лимит ответа иногда даёт неожиданное сочетание: успешный HTTP-ответ, пустой content и finish_reason со значением length. Обработчик, который требует непустой текст для любого корректного ответа, назовёт это сбоем транспорта. Но у reasoning-модели бюджет может расходоваться иначе, чем ожидает клиент. Для провайдера важно проверить смысл лимита, форму завершения и счётчики как связанные, но отдельные свойства.
Уточните область ограничения
Документация параметров OpenRouter отмечает, что у большинства соответствующих провайдеров max_tokens для reasoning-моделей охватывает reasoning и видимый выход вместе. Она также описывает возможность length с пустым content при малом бюджете. Это описание конкретного внешнего интерфейса, а не основание объявить одинаковую поддержку любой модели.
В контракте своего сервиса укажите используемое имя параметра, его единицу и область действия. Не считайте max_tokens и максимальную длину контекста одним ограничением. Первое касается допустимого выхода, второе затрагивает общий модельный ресурс и подготовленный вход.
Разделите текст и выполненную работу
Поля usage в обзоре API содержат общий completion count и необязательные детали. Видимый текст представляет только наблюдаемую часть результата. Поэтому повторная токенизация content не всегда восстанавливает счётчик работы, которую выполнил движок.
Не складывайте детализацию с общим значением без определения включения. В отчёте нужно явно показать, является ли reasoning count частью общего output либо отдельной величиной конкретной реализации. Отсутствующее поле не подтверждает нулевой расход, особенно когда сравниваются разные версии ответа.
Постройте лестницу бюджета
Выберите один короткий синтетический вход и несколько ограниченных значений выхода. Сохраните модель, ревизию, остальные параметры и условия прогрева. На каждой ступени записывайте HTTP-исход, finish_reason, наличие текста и usage. Не подбирайте значения по впечатлению от одного красивого ответа.
Числа лестницы являются параметрами эксперимента, а не рекомендуемыми коммерческими лимитами. Остановите тест, если суммарный бюджет достигнут или результат стал достаточно ясным. Здесь нужна проверка контракта на малом наборе, а не нагрузочное исследование всей модели.
Разберите разные исходы
Пустой content вместе с length оценивается по объявленной семантике модели. Ошибка валидации до генерации относится к другой ветви. Обрыв SSE без итогового завершения нельзя объяснять тем же правилом только потому, что клиент тоже не увидел текста.
Добавьте fixture обычного stop и fixture отказа из-за недопустимого параметра. Они помогают убедиться, что классификатор не принимает любой пустой результат за корректное исчерпание бюджета. Сохраняйте первоначальный envelope: его поля важнее удобного сообщения, составленного клиентской библиотекой.
Проверьте пользовательскую интерпретацию
Приложение должно различать исчерпанный бюджет, неполную доставку и отсутствие поддержанной функции. Автоматическое повторение того же запроса с тем же малым лимитом может лишь повторить прежний исход. Увеличение бюджета тоже требует отдельного решения, а не скрытого обхода заданного ограничения.
Связанные материалы — учёт usage и max-model-len. Они объясняют разные границы: счётчики работы и ёмкость контекста. Совпадение технического теста с документацией не подтверждает доступность интеграции или будущий поток запросов.