Context Length Exceeded
Три маскировки — последнюю сложнее всего поймать
Превышение контекстного окна проявляется по-разному: явная ошибка 400, тихое обрезание входа, или внешний код 200 с пустым потоком — третий вариант чаще всего принимают за что-то другое.
Четыре ключевых факта
Явная ошибка (проще всего поймать)
В теле ошибки прямо указано context_length_exceeded или maximum context length — причина очевидна.
Часть входа незаметно отрезается
Некоторые клиенты/шлюзы при приближении к лимиту автоматически отбрасывают самые старые сообщения без ошибки — модель видит меньше контекста, чем вы думаете, и ответы начинают выглядеть так, будто модель «забыла» что-то.
Сложнее всего поймать
HTTP-статус чистый 200, но потоковое соединение обрывается сразу после открытия без единого токена — легко принять за сетевой сбой или баг клиента.
Настоящее решение
Разбиение длинного контекста на части, суммаризация или retrieval-augmented generation (RAG), либо переход на модель с большим контекстным окном — это решает все три маскировки в корне.
Как выглядит каждая из трёх маскировок
Первая, явная ошибка 400: в теле ответа прямо указано context_length_exceeded или maximum context length, весь запрос отклонён — проще всего локализовать. Вторая, тихое обрезание: некоторые SDK, прокси-слои или логика управления историей при приближении к лимиту автоматически отбрасывают самые старые сообщения вместо ошибки — модель по-прежнему отвечает нормально, но, не видя отброшенного контекста, ответ начинает выглядеть так, будто модель «забыла» предыдущие реплики или противоречит сама себе. Третья, внешний 200 с пустым потоком: на уровне HTTP всё выглядит нормально, статус 200, но потоковое соединение обрывается сразу после открытия без единого токена — чаще всего это принимают за сетевые помехи, таймаут или баг парсинга на клиенте, тогда как реальная причина обычно в том, что запрос уже превысил контекстное окно и провалился на стороне сервера ещё до начала стриминга, просто без передачи стандартного тела ошибки 400 в потоковый протокол.
Почему это стало встречаться чаще
С распространением агентных/суб-агентных workflow всё чаще в один запрос запихивают целую кодовую базу, полную историю диалога и результаты нескольких раундов вызовов инструментов, что резко повышает вероятность превышения контекстного окна. Разные клиенты и шлюзы по-разному обрабатывают переполнение (одни выдают ошибку, другие тихо обрезают, третьи дают пустой поток), из-за чего диагностика усложняется.
Хронология
context_length_exceeded — давно существующий стандартный тип ошибки в основных API моделей, ровесник самого понятия контекстного окна.
Агентные/суб-агентные workflow значительно увеличивают объём контекста в одном запросе, повышая частоту превышения лимита.
Самая сложная для диагностики маскировка «внешний 200, пустой поток» встречается всё чаще в полностью агентных workflow и чаще всего диагностируется неверно.
Подтверждено vs частое заблуждение
Подтверждено
Все три маскировки (явная 400, тихое обрезание, внешний 200 с пустым потоком) задокументированы в публичных обсуждениях разработчиков и реализациях различных SDK/шлюзов; первопричина всегда одна — содержимое запроса (история, результаты вызовов инструментов, системный промпт) превышает контекстное окно модели.
Частое заблуждение
Первая реакция многих на пустой поток — заподозрить сеть или клиент и раз за разом повторять запрос или менять сеть. Если реальная причина — переполнение контекста, ничего из этого не поможет, только потратит время на диагностику.
Как быстро понять, что причина именно в этом
Сначала проверьте размер запроса
Посчитайте фактическое число токенов в запросе (системный промпт + история + результаты вызовов инструментов + новый ввод) и сравните с заявленным контекстным окном модели — приближение к лимиту или превышение — сильный сигнал.
Затем посмотрите на форму ответа
Явная 400 подтверждает это напрямую; тихое обрезание проявляется как «забывчивость» модели; внешний 200 с пустым потоком проявляется как обрыв соединения почти сразу без токенов, а не как таймаут.
Шаги по диагностике и решению
Шаг 1: оцените общее число токенов в запросе (официальным токенизатором или сторонним инструментом оценки) и сравните с контекстным окном модели. Шаг 2: если оно близко к лимиту или превышает его, приоритет — не повтор запроса, а сокращение входа: сжать историю через суммаризацию, оставить только последние несколько раундов, или использовать retrieval-augmented generation (RAG), забирая только релевантные фрагменты вместо всей истории. Шаг 3: если задаче действительно нужен длинный контекст, рассмотрите переход на модель с большим контекстным окном. Шаг 4: для случая «внешний 200, пустой поток» добавьте отдельную проверку — если после открытия потокового соединения токены не приходят в течение короткого времени, считайте это переполнением, а не обычным сетевым таймаутом для повтора.
Что делать в QCode
В линейке моделей QCode разные семейства имеют разный размер контекстного окна; один и тот же ключ позволяет переключаться на модель с большим контекстным окном в зависимости от объёма задачи, без отдельной заявки или настройки под длинный контекст.
Частые вопросы
Как понять, что я столкнулся именно с этой проблемой?
Сначала посчитайте общее число токенов запроса и сравните с заявленным контекстным окном модели; если оно близко к лимиту или превышает его, а ответ — явная 400, противоречивый (предположительно обрезанный) вывод или потоковый ответ без токенов — это подтверждает диагноз.
Почему тихое обрезание не выдаёт ошибку?
Это логика отказоустойчивости, реализованная самими клиентами/шлюзами — при обнаружении переполнения они предпочитают отбросить самые старые сообщения вместо провала всего запроса, чтобы диалог «выглядел» продолжающимся, ценой того, что модель теряет отброшенный контекст.
Внешний 200 с пустым потоком — это сетевая проблема?
Обычно нет. Частая первопричина — запрос уже провалился на стороне сервера из-за переполнения, но нижележащая система не передала стандартное тело ошибки 400 в потоковый протокол, поэтому клиент видит «соединение успешно, но без содержимого». Повтор того же слишком длинного запроса, скорее всего, снова даст пустой поток.
Как оценить, сколько токенов реально использовал запрос?
Считайте вместе системный промпт, полную историю сообщений, результаты вызовов инструментов и новый ввод — официальным токенизатором или сторонним инструментом оценки; в агентных/суб-агентных сценариях это особенно легко недооценить, так как результаты каждого раунда вызова инструмента снова попадают в следующий запрос.
Решит ли переход на модель с большим контекстным окном проблему раз и навсегда?
Это облегчает ситуацию, но не бесконечно — чем больше контекстное окно, тем обычно выше стоимость запроса, и даже у самого большого окна есть предел. Более надёжный подход — одновременно сокращать вход (суммаризация, RAG), рассматривая размер окна как запас, а не единственную опору.
Это то же самое, что ошибки 429/529?
Нет. 429/529 — это проблемы скорости или мощности, не связанные с размером содержимого запроса; context_length_exceeded означает, что само содержимое запроса превышает то, что модель способна обработать — замедление или backoff здесь не помогут.
Источники
Три маскировки собраны на основе публичных обсуждений разработчиков и описаний стандартных типов ошибок в API различных моделей; эта страница не утверждает ничего о приватной реализации какого-либо конкретного поставщика, только описывает общие для всех паттерны и способы их различения. Составлено 27.08.2026.
Переполнение контекста не должно тормозить работу
Один ключ QCode переключает на модель с большим контекстным окном в зависимости от объёма задачи.
Читайте также
Четыре причины обрыва потока до завершения
Ещё один часто неверно диагностируемый сбой стриминга — полезно для сравнения.
Полный гид по программированию с длинным контекстом
Как системно управлять задачами с длинным контекстом.
Claude 529 vs 429 vs Weekly Limit
Ещё один набор легко путаемых ошибок, разобранный по полочкам.
Эта страница — общее техническое объяснение для разных поставщиков и не содержит утверждений о приватной реализации какого-либо конкретного из них. Фактическое поведение определяется используемой моделью и документацией клиента.