Вы открываете новую сессию, не написав ещё ни одного символа, и окно уже занято. Семь процентов. Ни один из этих токенов не относится к задаче, которую вы собираетесь решать: это системный промпт, схемы инструментов и файлы памяти, которые агент читает при каждом старте. Дальше вы работаете час, упираетесь в лимит и идёте искать команды экономии токенов.
Команды вы найдёте. Только лечить они будут не то. Контекст в рабочем проекте раздувается не от длинных промптов, а оттого, что документация разошлась с кодом, а история задач копится в файле, который агент читает первым. Пока это так, любая экономия на выводе команд возвращается через неделю.
Посмотрите, что лежит в окне, прежде чем что-то резать
В Claude Code есть команда /context all. Она показывает разбивку по категориям, и разбивка почти всегда удивляет.
Вот снимок моей рабочей сессии на модели Opus с окном в миллион токенов: занято 68,8 тысячи, то есть 7%. Системный промпт — 5,6k. Схемы инструментов — 13k. Пользовательские агенты — 425 токенов. Файлы памяти — 24,1k. Skills — 5k. Сама переписка — 20,7k.
Через несколько реплик я снял второй снимок, не очищая сессию. Переписка выросла до 25,1k. Все остальные категории не изменились ни на токен.
Из этого следуют вещи, которые меняют приоритеты. История диалога растёт быстрее любой статичной категории: за несколько реплик она прибавила больше, чем весит целиком весь блок Skills. Сам блок Skills при этом занимает полпроцента окна вместе с полным встроенным набором, так что спор о том, сколько токенов ест отдельный скилл, экономит примерно ничего. А реальный вес лежит в двух местах: схемы подключённых инструментов и файлы памяти, где два больших документа моего проекта дают почти половину категории.
Полпроцента против двадцати четырёх тысяч. Резать надо там, где тяжело, а не там, где привычно.
Приёмы, которые останавливают трату сразу
Самый дешёвый из них — Esc. Если агент пошёл не туда, останавливайте его на первой же неверной реплике, не дожидаясь конца рассуждения. Каждый абзац, который он допишет, вы потом протащите через весь остаток сессии.
Если неверный ход уже случился, не спорьте в чате. Спор добавляет в контекст и ошибку, и объяснение ошибки, и исправление. Команда /rewind откатывает разговор к точке до неудачного поворота, и в окне не остаётся следа.
Перед дорогими изменениями включайте Plan Mode через Shift+Tab. Агент разбирается в задаче и показывает план, ничего не трогая. Дешевле прочитать план на двадцать строк и сказать «нет», чем читать диф на четыреста.
Держите одну логическую задачу в одной сессии. При смене темы — /clear. Это звучит как дисциплина ради дисциплины, но снимок выше объясняет, почему это работает: переписка единственная категория, которая растёт, и она тащит за собой всю предысторию в каждый следующий запрос.
Для побочного вопроса есть /btw. Он отвечает, не запуская инструменты, и видит только текущий контекст, поэтому не притаскивает в окно ещё десяток прочитанных файлов.
Разведку по коду отдавайте субагентам. Субагент читает двадцать файлов у себя и возвращает вам десять строк вывода. Разница между «прочитать двадцать файлов в основной сессии» и «получить их конспект» измеряется десятками тысяч токенов.
Модель выбирайте по сложности задачи, но не переключайте её после каждого сообщения. У каждой модели свой кеш промпта, и переключение туда-обратно означает, что общий префикс контекста считается заново.
Всё перечисленное работает. И всё перечисленное перестаёт помогать, когда в проекте заводится то, о чём ниже.
Файл статуса, который незаметно стал журналом
У меня в проекте есть файл состояния: очередь задач, открытые решения, статус публикаций. В нём же стояла инструкция для агента, с которой я начинал каждую сессию: прочитай состояние и журнал изменений, продолжаем работу.
Файл весил 139 килобайт. Правился ежедневно.
Оба факта по отдельности выглядят безобидно, вместе они дают худший из возможных вариантов. Ежедневная правка означает, что от кеша префикса пользы нет: содержимое каждый раз новое. А инструкция означает, что эти 139 килобайт заходят в окно при старте каждой сессии, до первого вопроса.
Разбор по разделам показал состав. Журнальные записи «что сделано» за шесть дат плюс блок про уже прошедший вебинар занимали 100 килобайт из 139. Семьдесят два процента файла статуса были историей.
Дальше стало интереснее. При переносе выяснилось, что журнал десять дней вёлся в двух местах сразу: девять записей за одну дату в файле статуса и восемь абзацев про те же события в журнале изменений. Из ста килобайт переносимого содержимого уникальным оказалось около двадцати пяти. Остальное дублировало то, что уже лежало в правильном файле.
Никто этого не замечал, потому что дублирование не ломает ничего. Оно просто стоит денег на каждом запуске.
После разбора файл статуса стал весить 31,7 килобайта, минус семьдесят семь процентов. История ушла в журнал, выводы по трафику — в отдельную заметку, справочная таблица файлов проекта — в постоянную часть контекста, которая меняется редко и потому кешируется.
Правило простое. Файл статуса отвечает на вопрос «что делать дальше». Журнал отвечает на вопрос «что было». Смешивать их значит платить контекстом за историю при каждом старте сессии, а платить контекстом за историю вы не хотите даже один раз.
Три формы, которые неделю не считали заявки
Второй разбор начинался как уборка в инженерных правилах. В документе описывалось правило про служебную метку в теме письма от форм сайта. Метку из кода убрали двадцать первого августа, потому что она занимала начало строки и мешала. Правило осталось.
Смотрите, что бы произошло дальше. Агент, взявшийся править формы, честно читает инструкцию проекта и возвращает то, что человек удалил осознанно неделю назад. И будет прав по документации.
Там же лежала фраза про лимит счётчика аналитики: двести целей, а в коде уже двести десять. Формулировка смешивала два разных числа, и я потратил время на поиск превышения, которого не существовало. Целей в интерфейсе было заведено шестьдесят две из двухсот, а двести десять относилось к количеству вызовов в коде.
Инвентарь вызовов дал находку крупнее. Цель в моём коде отправляется шестью разными способами: атрибут на ссылке, прямой вызов, две разные обёртки в скриптах страниц, атрибут для срабатывания при попадании блока в область просмотра и ещё одна обёртка на двух старых страницах. Поиск по самому очевидному шаблону находит четыре вызова из четырёхсот пятидесяти шести. Первый прогон инвентаря дал 225 идентификаторов, второй 268, третий 293. Каждый раз обнаруживался ещё один способ вызова, который предыдущий шаблон пропускал.
В осадке — три формы, которые не считались вообще. Вызов в коде стоял и выглядел рабочим, письма с заявками приходили, а цель в интерфейсе аналитики заведена не была. Такой вызов не падает и ничего не сообщает. Среди потерянного была заявка на корпоративную программу от ста тысяч рублей и клик по цене материала за полмиллиона, и задним числом эти данные не восстанавливаются.
Восемь дней тишины стоили дороже, чем весь перерасход токенов за месяц.
Мёртвый слой с заряженным мигратором
Шестнадцатого августа при переводе тридцати четырёх страниц на общую систему стилей старый слой оформления перестал подключаться. Решение было осознанным и правильным. Нигде не записанным.
Через двенадцать дней в репозитории лежало четыре предмета: мёртвый CSS, мёртвый JS, документ дизайн-системы, описывающий их как работающий механизм, и проверка в сборке, требовавшая «один из трёх каркасов», где третья ветка не срабатывала ни разу с середины месяца.
Опаснее всего был четвёртый предмет — скрипт-мигратор. Он обходит все страницы и вставляет подключение слоя перед закрывающим тегом заголовка. Одна команда вернула бы мёртвый слой на шестьдесят с лишним страниц вместе с правилом overflow-x: hidden, которое делает элемент контейнером прокрутки и убивает липкие шапки у всех потомков, и с сорока пятью объявлениями !important.
Ни один агент не отличил бы этот скрипт от рабочего инструмента. Я сам не отличил бы через месяц.
Решение, которое нигде не записано, через две недели неотличимо от аварии.
Что из этого следует делать в своём проекте
Не грузите файлы состояния целиком. Если агенту нужен статус задачи, пусть прочитает нужный раздел, а не весь файл. Инструкция «прочитай всё и продолжаем» удобна ровно один раз, а платите вы за неё каждый день.
Держите короткий постоянный контекст и подключайте к нему только то, что меняется редко. Один правленый абзац в подключённом документе обнуляет кеш на весь префикс, поэтому ежедневно меняющемуся файлу там не место. Всё остальное агент прочитает по требованию, когда задача этого потребует.
Разводите статус и историю по разным файлам с первого дня. Разбирать сросшийся файл на 139 килобайт заметно дороже, чем не давать ему срастись.
И главное: когда вы удаляете механизм, удаляйте вместе с ним описание в документации, проверку в сборке и скрипт, который умеет его вернуть. Документация, которая врёт, дороже любого перерасхода токенов, потому что перерасход вы видите в счётчике, а враньё увидите только в тот день, когда агент по нему что-нибудь сделает.
Кстати, о методологии. У меня в проекте живут агенты с именами вроде «исследуй сначала» и «точечный патч». Это правила работы — сначала разведка, потом узкая правка, потом проверка, — и к сжатию текста они отношения не имеют. Их часто путают с режимом телеграфных ответов, о котором ниже.
Мифы
RTK и подобные прокси экономят 90%. Заявленная экономия относится к выводу отдельных команд: сокращённый git status, свёрнутый вывод тестов. Замер JetBrains в июле 2026 на реальных задачах показал другое: при низком уровне рассуждений работа оказалась на 7,6% дороже (p=0,004), при высоком разницы не было вовсе. Инструмент режет то, что и так не было главной статьёй расхода.
Сжатие ответов в телеграфный стиль экономит лимит. Экономит оно выходные токены, которых в диалоге меньшинство. Входной контекст, который вы оплачиваете при каждом запросе, от стиля ответов не меняется.
После ста тысяч токенов модель тупеет, и есть порог, за которым надо чистить. Деградация на длинном контексте измерена и реальна, но никакого универсального порога у неё нет: качество падает от мусора в окне, а не от круглого числа. Тот же замер JetBrains на длинных траекториях показал, что простое замещение старых наблюдений заглушками работает не хуже пересказа истории отдельной моделью и при этом дешевле.
Утренний фиктивный запрос закрепляет лимит на выгодное окно. Лимит считается по потреблению, а не по времени первого обращения. Фиктивный запрос тратит токены и не даёт ничего.
Много инструментов и скиллов — вот что съело контекст. Проверьте по снимку. У меня схемы всех подключённых инструментов заняли 13k, а весь набор скиллов — 5k, при 24,1k в файлах памяти.
Откройте /context all в своей рабочей сессии и посмотрите на строку с файлами памяти. Потом откройте самый большой из них и посчитайте, сколько абзацев там описывает то, чего в коде уже нет.