Автор поста под ником OleCuvee запустил агента Francis в Discord на стеке OpenClaw → Ollama Cloud → GLM 5.3 Flash. Заявленное окно контекста: 1 048 576 токенов. Агент вёл рабочую сессию с вызовами инструментов, чтением файлов, кодом и общением с шестью людьми в нескольких каналах. Всё это продолжалось примерно 23 часа и покрыло около 800 событий транскрипта.
Первый сигнал появился около 683k токенов: агенту сказали, что несвязанная задача закончена, и он в ответ выдал инструкции по работе, которую обсуждали девятнадцатью часами ранее. Через две минуты пошёл внутренний монолог про ту же старую задачу, потом сотни повторов слова «дизайн», чекмарки, повтор слова «инструмент», метки «инструмент»Result, куски оркестрационного конверта. Агент не вернулся в норму. Команды /new, /reset, /stop не помогли. Пришлось убивать сессию OpenClaw.
Финальные нормальные ответы были около 683k токенов, сломанные ушли за 688k, то есть примерно 65% от заявленного миллиона. Автоматическое сжатие контекста (сжатие) ожидалось ближе к моменту, когда свободной останется четверть окна. Агент сломался примерно за 100k токенов до того, как подушка безопасности должна была сработать.
Самое неприятное: провайдер ни разу не вернул ошибку. Ни переполнения, ни тайм-аута, ни сбоя. Для обвязки (обвязка) поток повторов «дизайн» был валидным ответом модели. Сломанные ходы приходили как успешные ответы, без отличия от нормальных.
Кэша не было в телеметрии
В кэш-статистике каждого затронутого Ollama/GLM-хода нулевые чтение и запись кэша. Телеметрия либо отсутствовала, либо была нулевой. За десять ходов последних 25 минут через маршрут прошло около 6,1 миллиона входных токенов (input tokens), по ~680k за ход. В отдельной инструмент-тяжёлой сессии чуть раньше зафиксировано 6 912 253 входных и 28 956 выходных токенов, ноль чтений кэша, ноль сжатий, без тайм-аута и без ошибки провайдера.
Автор замечает: «Это не доказывает, что Ollama Cloud не делает внутренний переиспользование KV-кэша. Он может кэшировать скрыто или адаптер OpenClaw под Ollama не запрашивает нужную телеметрию». Операционно обвязка вела себя так, будто кэша нет, и спокойно скармливала огромный смешанный транскрипт, пока модель не вернула кашу.
Сравнение с тем же агентом на GPT-5.5 через OpenAI за два предыдущих дня: 132 прогона, 14,9 миллиона кэш-прочитанных токенов против 1,33 миллиона некэшированных входных, около 91,8% доли кэша в промпте. На маршруте Ollama/GLM OpenClaw видел нули.
Агент сам уверил, что всё дёшево
За несколько минут до коллапса автор спросил Франсиса, не построить ли слой кэширования, было видно, что через систему идёт много повторяющегося текста. Агент уверенно ответил, что делать ничего не надо: повторяющийся контекст и так дёшев благодаря кэшу промптов и KV-кэшу у провайдера. Ответ разумный для OpenAI или Anthropic, где стабильные префиксы реально кэшируются и телеметрия это подтверждает. Для фактического маршрута это было неправдой: чтение кэша = 0 и запись кэша = 0 в каждом затронутом прогоне.
Что починили после инцидента
- Два самых пострадавших канала выведены из работы, сырые повреждённые сессии заблокированы от повторного чтения.
- Добавлен ограничитель (ограничитель) против утечки черновиков рассуждений (черновиков) и против повторяющихся токенов в ответе.
- Тяжёлая обработка логов вынесена из живых диалогов.
- Введены регулярные сбросы сессии — временно, пока не появится лучший механизм.
Отдельный симптом: утечка рассуждений
После чистого сброса, при всего ~20k токенов в промпте, агент начал публиковать служебные заметки до самого ответа: пересказ запроса, решение «отвечать или нет», фразу «теперь выдай финальный ответ», обсуждение тона и только потом сам ответ. В одном случае агент рассудил, что лучше промолчать, и опубликовал всё это рассуждение с финальным «НЕ ОТВЕЧАТЬ». Огромный контекст объясняет устаревшие данные и коллапс повторов, но не объясняет утечку внутренних заметок на выходе. Это уже проблема границы ответа.
Как повторить
- Залогируйте заполнение окна в каждом ходе: текущие входные токены и долю от лимита. Не полагайтесь на ошибки провайдера как сигнал деградации.
- Заранее задайте порог принудительного сброса или сжатия сильно ниже заявленного лимита. В этом кейсе деградация пришла на 65%, а не на 100%.
- Проверяйте телеметрию кэша провайдера (чтение кэша, запись кэша). Если провайдер не отдаёт метрики кэша или возвращает нули, считайте, что кэша для обвязки нет, и планируйте промпт от этого.
- Отделяйте длинный контекст от живого диалога: тяжёлые логи и обработку файлов выносите из основной сессии, чтобы не раздувать префикс.
- Добавьте ограничители на выход: детектор повторяющихся токенов и фильтр утечки черновиков рассуждений перед отправкой пользователю.
- Сравните тот же сценарий на провайдере, который отдаёт телеметрию кэша (например, OpenAI). Большая доля чтение кэша — сигнал, что префикс переиспользуется; нулевая — что нет.
- Запланируйте регулярные сбросы сессии, пока не появится надёжный механизм сжатия по факту, а не по расписанию.