Claude Code спорит и путает цифры к третьему часу работы: что происходит с контекстом сессии

Утром инструмент понимает проект с полуслова. К обеду он предлагает подключить библиотеку, которой в проекте нет, называет число эндпоинтов, не сходящееся с реальностью, и спорит, когда вы указываете на ошибку. Версия и задача те же, что утром, длиннее стал только сам разговор.

Предприниматель без опыта в разработке замечает это последним, потому что код выглядит правдоподобно, объяснения звучат уверенно, а проверить утверждение про «здесь 47 эндпоинтов» ему нечем. Автор годового разбора работы с Claude Code на Хабре описывает тот же эффект: после часа в одной сессии модель начинает забывать особенности проекта и тянуть библиотеки со стороны.

Как деградация Claude Code выглядит со стороны

Раньше всего сбивается счёт: модель уверенно называет количество файлов или строк, число оказывается близким к правде и всё-таки неверным — 47 вместо 42. Ошибка выглядит правдоподобно, поэтому её редко идут перепроверять, и следом за счётом начинаются подмены. В проекте используется одна библиотека, в новом коде появляется другая, похожая по назначению, и формально всё продолжает работать. Лишняя зависимость обнаруживается через неделю, когда что-нибудь на ней ломается.

Третий признак самый неприятный, потому что выглядит как аргументированная позиция. Вы говорите, что решение неверное, получаете возражение и вторую версию того же кода. Один и тот же диалог утром и вечером идёт совершенно по-разному, хотя ни модель, ни задача не менялись.

Ближе к концу длинной сессии добавляется сигнал, который легко списать на усталость: ответы становятся короче и осторожнее. Исследователи, разбиравшие поведение агентов на длинной дистанции, зафиксировали это как измеримый эффект — с ростом контекста модели начинают отказываться от ответа или преждевременно выдавать неуверенный вместо того, чтобы доработать задачу.

Что происходит с контекстным окном по ходу разговора

Контекстное окно работает как рабочий стол. На него помещается ограниченный объём материалов, и всё, что нужно модели для ответа, должно лежать там одновременно: системные инструкции, содержимое открытых файлов, история переписки, результаты выполненных команд.

Ещё до первого вопроса окно занято служебным. По документации Anthropic туда попадает системный промпт вместе с автоматической памятью, описанием окружения, списком подключённых инструментов и файлом проектных инструкций. На своих проектах автор разбора на Хабре оценил эту загрузку в 40–50 тысяч токенов, так что часть стола занята до начала работы.

Когда места перестаёт хватать, включается сжатие, устроенное в два шага. Сначала вычищаются старые результаты выполненных команд, и лишь когда этого недостаточно, переписывается сам разговор — длинная история заменяется кратким пересказом.

Пересказ и создаёт основную проблему. В документации Anthropic сказано, что запросы и куски кода, на которые опирались, сохраняются, а подробные инструкции из начала разговора могут потеряться. Договорённость «в этом проекте мы не используем такую-то библиотеку», произнесённая на десятой минуте, до второго часа доживает не всегда.

Качество падает раньше, чем кончается место

Интуиция подсказывает, что до заполнения окна всё работает одинаково хорошо, но замеры этого не подтверждают.

Исследование NoLiMa ввело понятие эффективной длины — той, на которой модель удерживает хотя бы 85% своего обычного результата. У моделей, заявляющих окно в 128 тысяч токенов и больше, она оказалась в диапазоне от одной до восьми тысяч, а из двенадцати проверенных моделей десять на 32 тысячах токенов показали половину базового результата или хуже.

Причину Anthropic объясняет через архитектуру: модель связывает каждый токен с каждым, число таких связей растёт квадратично, и внимание размазывается тонким слоем. Свою роль играет и обучение, где коротких текстов было заметно больше, поэтому опыта работы с длинными зависимостями у модели меньше.

Отдельно измерена слепота к середине. В работе Lost in the Middle нужный документ прятали среди двадцати-тридцати посторонних, и при размещении в середине набора точность падала ниже, чем если модели вообще не давали документов.

Что переживает автосжатие и что из него не возвращается

Часть материалов возвращается на рабочий стол автоматически, потому что читается с диска заново. Так устроены системный промпт, корневой файл проектных инструкций, безусловные правила и автоматическая память.

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

Отсюда правило, которое лучше принять до первой длинной сессии. Всё, что критично для проекта, должно лежать в файле, который перечитывается. Сказанное голосом в диалоге живёт до первого сжатия и после него превращается в строку пересказа.

Кейс из практики

Анастасия, помощник маркетолога и участница нашего клуба, вела в Claude Code несколько проектов одновременно и подгружала контекст под каждый вручную. Память при этом она не настраивала.

Перезагрузка редактора обнулила накопленное. По её словам, «много информации слетело», и восстанавливать пришлось с нуля — заново объяснять структуру проектов, заново задавать правила. Память проще настроить в первую же неделю, пока контекста накоплено мало.

Масштаб той же проблемы виден в публичном разборе Алексея Григорьева, основателя обучающей платформы DataTalks.Club. При переезде на новый ноутбук он не перенёс файл состояния инфраструктуры. Агент запустил проверку, увидел пустое состояние, заключил, что инфраструктуры не существует, и снёс продакшен вместе с базой.

В сумме он потерял 1 943 200 строк, за которыми стояло два с половиной года домашних работ и рейтингов учеников. Автоматические снапшоты удалились вместе с базой, а восстановление заняло почти сутки — обнаружил в одиннадцать вечера, поднял в десять вечера следующего дня, и то благодаря скрытому снапшоту, который нашла поддержка.

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

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

Приёмы, которые удерживают качество длинной сессии

Самый дешёвый приём состоит в том, чтобы вынести состояние проекта из головы модели в файлы. Anthropic описывает его как базовый и ссылается на собственный опыт с агентом, который играл в Pokémon: он удерживал стратегию через тысячи шагов и несколько полных обнулений контекста, потому что вёл заметки за пределами окна.

Из этого вырастает цикл, который практики называют передачей смены. Перед завершением работы модель записывает в файл текущее состояние — что сделано, какие решения приняты, что осталось. Новая сессия начинается с чтения этого файла, и модели не приходится восстанавливать логику проекта по коду.

Файл проектных инструкций при этом лучше держать коротким. Разбор годового опыта рекомендует укладываться в 200–300 строк и выносить детали в отдельные документы, оставляя в основном файле указатели. Объёмный файл, который меняется каждый день, сбрасывает кэш и удорожает каждый запрос, потому что Claude Code пересчитывает токены заново.

Момент вмешательства влияет на результат сильнее, чем выбор конкретного приёма. Разборы практики советуют сжимать контекст примерно на 60% заполнения, пока качество ещё в норме; если дождаться симптомов, в пересказ попадут уже и путаные выводы, а вместе с ними деградация переедет в новую сессию.

Разгрузить основное окно помогают субагенты — они работают в собственном контексте и возвращают короткую сводку. Мы разбирали механизм подробно в материале о том, где параллельные агенты экономят время, а где только усложняют работу. Работает это только при коротком ответе, потому что субагент, вываливающий стену текста обратно, не разгружает ничего.

А может, дело в постановке задачи

Против всей этой картины есть сильное возражение, и опирается оно на замеры.

Академическая работа апреля 2026 года разложила отказы агентов на длинной дистанции по причинам. Из всех сбоев 72,5% пришлось на процессные — ошибки среды, нечёткие инструкции, плохое планирование, накопление собственных ошибок. На память и катастрофическое забывание осталось 27,5%. Anthropic в собственном разборе описывает два типичных механизма провала, и оба растут из постановки задачи. Агент либо пытается сделать всё за один заход, либо видит чужой прогресс и объявляет работу законченной.

Есть и неудобное наблюдение про само лекарство. Исследование ETH Zurich показало, что сгенерированные моделью файлы инструкций снижают долю успешных решений примерно на 3% относительно варианта вообще без файла и поднимают стоимость запросов больше чем на 20%, а написанные людьми давали плюс 4%, так что раздутый файл обходится дороже проблемы, которую он должен решать.

У обеих сторон спора есть коммерческий интерес. Термин «context rot» ввела компания, продающая векторный поиск, то есть прямой бенефициар вывода «длинный контекст не работает». Anthropic симметрично заинтересована в объяснении «дело в вашей обвязке», так что незаинтересованной стороны в этом споре не видно.

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

FAQ

Почему Claude Code забывает, о чём мы договорились в начале сессии? При нехватке места история разговора заменяется кратким пересказом. Запросы и куски кода, которые обсуждались, сохраняются, подробные инструкции из начала могут пропасть. Договорённости надёжнее держать в файле проектных инструкций, который перечитывается заново.

Что выбрать: сжатие или очистку сессии? Сжатие сохраняет накопленный кэш и потому дешевле по деньгам, хотя само по себе является крупным запросом — модель перечитывает то, что суммирует. Очистка не стоит ничего, зато обнуляет кэш и требует заново дать контекст. При смене задачи логичнее очистка, при продолжении той же работы — сжатие.

Помогает ли контекстное окно на миллион токенов? Не так, как ожидается. Заявленный объём и рабочий объём различаются заметно: в публичных замерах на миллионе токенов результаты моделей расходятся в разы, тогда как на 128–256 тысячах те же модели идут почти вровень. Часть практиков сознательно возвращается на меньшее окно, потому что узкие рамки заставляют держать дисциплину.

Как понять, что пора начинать новую сессию? Ориентируйтесь на смену задачи. Закончили один блок работы — начните заново, записав состояние в файл. Если симптомы вроде спора и неверных чисел уже появились, сессию поздно сжимать: сначала проверьте последние результаты, потом открывайте чистую.

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

Что с этим делать

Деградация в длинной сессии следует из того, как устроено внимание модели, и усиливается привычкой работать одной бесконечной сессией, где договорённости остаются в переписке и нигде не записаны.

Сильнее всего картину меняет привычка держать проектные правила в файле, который перечитывается заново. К ней добавляется разбиение работы по границам задач и выборочная проверка чисел и названий зависимостей во второй половине разговора.

Такие настройки предприниматели разбирают на живых проектах и рассказывают, что кладут в файл инструкций и где обожглись. Если хотите посмотреть на чужие грабли до того, как наступите на свои, заглядывайте в AI Practiq Club.