# Лимит ответа и reasoning tokens: контракт завершения по длине

Как проверять length-завершение при лимите ответа: reasoning tokens, пустой content, разные счётчики и fixtures для контракта API.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-output-limit-reasoning-contract/
Language: ru

Короткий лимит ответа иногда даёт неожиданное сочетание: успешный HTTP-ответ, пустой content и finish_reason со значением length. Обработчик, который требует непустой текст для любого корректного ответа, назовёт это сбоем транспорта. Но у reasoning-модели бюджет может расходоваться иначе, чем ожидает клиент. Для провайдера важно проверить смысл лимита, форму завершения и счётчики как связанные, но отдельные свойства.

## Уточните область ограничения

[Документация параметров OpenRouter](https://openrouter.ai/docs/api_reference/parameters) отмечает, что у большинства соответствующих провайдеров max_tokens для reasoning-моделей охватывает reasoning и видимый выход вместе. Она также описывает возможность length с пустым content при малом бюджете. Это описание конкретного внешнего интерфейса, а не основание объявить одинаковую поддержку любой модели.

В контракте своего сервиса укажите используемое имя параметра, его единицу и область действия. Не считайте max_tokens и максимальную длину контекста одним ограничением. Первое касается допустимого выхода, второе затрагивает общий модельный ресурс и подготовленный вход.

## Разделите текст и выполненную работу

[Поля usage в обзоре API](https://openrouter.ai/docs/api_reference/overview) содержат общий completion count и необязательные детали. Видимый текст представляет только наблюдаемую часть результата. Поэтому повторная токенизация content не всегда восстанавливает счётчик работы, которую выполнил движок.

Не складывайте детализацию с общим значением без определения включения. В отчёте нужно явно показать, является ли reasoning count частью общего output либо отдельной величиной конкретной реализации. Отсутствующее поле не подтверждает нулевой расход, особенно когда сравниваются разные версии ответа.

## Постройте лестницу бюджета

Выберите один короткий синтетический вход и несколько ограниченных значений выхода. Сохраните модель, ревизию, остальные параметры и условия прогрева. На каждой ступени записывайте HTTP-исход, finish_reason, наличие текста и usage. Не подбирайте значения по впечатлению от одного красивого ответа.

Числа лестницы являются параметрами эксперимента, а не рекомендуемыми коммерческими лимитами. Остановите тест, если суммарный бюджет достигнут или результат стал достаточно ясным. Здесь нужна проверка контракта на малом наборе, а не нагрузочное исследование всей модели.

## Разберите разные исходы

Пустой content вместе с length оценивается по объявленной семантике модели. Ошибка валидации до генерации относится к другой ветви. Обрыв SSE без итогового завершения нельзя объяснять тем же правилом только потому, что клиент тоже не увидел текста.

Добавьте fixture обычного stop и fixture отказа из-за недопустимого параметра. Они помогают убедиться, что классификатор не принимает любой пустой результат за корректное исчерпание бюджета. Сохраняйте первоначальный envelope: его поля важнее удобного сообщения, составленного клиентской библиотекой.

## Проверьте пользовательскую интерпретацию

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

Связанные материалы — [учёт usage](/ru/journal/openrouter-usage-accounting/) и [max-model-len](/ru/journal/vllm-max-model-len/). Они объясняют разные границы: счётчики работы и ёмкость контекста. Совпадение технического теста с документацией не подтверждает доступность интеграции или будущий поток запросов.