Оптимизация контекста в Cursor: как мы снизили расход токенов на 64% без потери качества

Материал посвящён теме «Оптимизация контекста в Cursor: как мы снизили расход токенов на 64% без потери качества». Ниже последовательно разберём главные вопросы, важные детали и практический контекст, чтобы легче ориентироваться в теме и понять логику дальнейшего изложения.

Как мы снизили расход токенов в Cursor на 64% без потери качества кода

Продолжаю тему внедрения ИИ-агентов в повседневную командную разработку. В прошлый раз я подробно разбирал, как мы выстраивали систему ограничений для Cursor: обкладывали репозиторий жесткими правилами, строгими хуками и детальной документацией. Однако за идеальный порядок пришлось заплатить внушительную цену — счет за токены вырос до астрономических значений. В этом материале я покажу, как мы проанализировали избыточный контекст и смогли сократить его объем на 64%, не повредив логику и качество генерируемого кода.

Симптомы раздутого контекста: почему легкие задачи жрали лимиты

Наш проект — мобильное приложение на базе React Native и Expo, над которым работает команда из шести человек. За последний год функционал существенно разросся: появился продвинутый каталог, полноценный оффлайн-режим, сценарии гостевого доступа, сложная форма с валидацией, виджеты для домашнего экрана iOS, механизмы OTA-обновлений и набор сторонних Expo skills.

Параллельно с ростом кодовой базы расширялся и вспомогательный слой, отвечающий за «обучение» AI-агентов нашему стилю разработки. В него входили файлы CLAUDE.md, AGENTS.md, правила из директории .cursor/rules/, доменная документация по хрупким узлам системы и контрольные hooks.

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

• Мгновенное переполнение стартового контекста: открываешь чистый диалог, просишь подвинуть кнопку на пару пикселей, а контекстное окно уже заполнено наполовину еще до первого ответа.
• Стремительный расход лимитов: подписка и выделенные токены таяли за считанные дни при скромном объеме реально выполненных фич.
• Потеря памяти из-за суммаризации: на крупных задачах модель быстро исчерпывала лимит и запускала процедуру суммаризации контекста. В этот момент агент «забывал» до половины ранее принятых договоренностей, что выяснялось только на этапе ревью.
• Обрыв контекста посреди диалога: даже на элементарных UI-правках сессия зависала из-за нехватки места под ответ.

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

Что и как мы измеряли: базовые метрики контекстного слоя

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

Для расчетов я использовал упрощенное соотношение: 1 токен ≈ 4 байтам в кодировке UTF-8. Это не точность токенизатора конкретной нейросети и не цифры из панели Cursor Usage. Настоящий системный промпт в IDE дополнительно включает спецификации инструментов, структуры MCP, историю беседы и сервисный оверхед. Мне была важна не абсолютная астрономическая точность, а гарантированная воспроизводимость измерений на одних и тех же файлах.

Размер файла на диске — это прозрачная метрика, которую любой разработчик может снять в терминале за секунду. Токенизатор показал бы другие абсолютные значения, но ровно ту же относительную пропорцию изменений. При этом я оценивал исключительно тот слой, которым управляю лично: CLAUDE.md, AGENTS.md, файлы из .cursor/rules/ и системные навыки из папки skills.

Разбор полетов: каков был фиксированный счет «до» оптимизации

Давайте взглянем на цифры, с которыми мы стартовали. Вся конфигурация делилась на всегда активный пакет (always-on) и контекст, подтягиваемый при редактировании TypeScript-файлов.

Always-on пакет (загружался абсолютно в любой чат)

Один только CLAUDE.md забирал 69% всего базового объема! Файл, начинавшийся как пятистрочная справка по продукту, за год превратился в гигантскую свалку из шаблонов задач, инструкций для аналитиков, подробных чек-листов для PR и дублей архитектурной карты.

Обычная UI-правка компонента (.ts / .tsx)

Как только диалог касался файлов кода, к базовому пакету автоматически примешивался главный кодекс проекта — app-core.mdc, снабженный маской **/*.{ts,tsx}:

• Базовый Always-on слой: ~101 908 байт (~25 500 токенов).
• Файл app-core.mdc: 53 071 байт (~13 300 токенов).
• Суммарный оверхед перед первым словом пользователя: ~154 979 байт (около 38 700 токенов).

Вот она, главная проблема: почти 39 тысяч токенов фиксированного контекста выгорало просто ради того, чтобы поправить отступ кнопки! В монолитном файле на 417 строк одновременно находились требования к оффлайн-режиму, правила логики виджетов, инструкции к формам, гайды по авторизации и OTA-обновлениям. Модель получала всё и сразу.

Набор сторонних навыков (Skills)

В проекте числилось 26 навыков в skills-lock.json и директория .agents/skills/ объемом 1,1 МБ (27 папок). Это вендорные справочники по Expo и EAS API. Их краткие описания попадали в системный промпт в виде длинного списка. При этом один только неиспользуемый модуль expo-skill-eval занимал 148 КБ. Мы подключали этот набор скопом, не задумываясь о цене хранения.

Две не очевидные вещи, которые я осознал не сразу

В процессе анализа я сделал два вывода, которые кардинально изменили наш подход к настройке ИИ-инструментов:

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

2. Автоматизация мелких задач меняет экономику контекста.
Если нейросеть пишет большую фичу в течение дня, оверхед в 39k токенов легко амортизируется длинной сессией. Но когда у вас настроен авто-пайплайн, закрывающий десяток мелких багов за день в отдельных чатах, вы платите этот фиксированный налог 39 000 токенов каждый раз заново. В итоге мелкие правки становятся самой дорогой статьей расходов.

Четыре фазы очистки: как мы резали гигабайты правил

В этом разделе рассматривается «Четыре фазы очистки: как мы резали гигабайты правил». Это помогает связать предыдущую часть материала со следующим вопросом и последовательно раскрыть тему без потери важного контекста.

Фаза 1. Превращение CLAUDE.md в компактный оглавление-индекс

Мы кардинально пересмотрели роль файла CLAUDE.md. Он должен работать как краткий навигатор, а не учебник. Внутри остались только технологический стек, ключевые сущности, ссылки на доменные доки, 5 критических запретов и команды сборки.

Все шаблоны задач для аналитиков мы перенесли в отдельный docs/for-analysts.md, который читают люди, а не нейросеть при каждом запросе. Дублирующиеся блоки о проверке PR и структуре каталогов были удалены.

Результат: размер CLAUDE.md сократился с 70 287 до 16 049 байт (−77%), а количество строк упало с 409 до 114.

Фаза 2. Разделение монолитного кодекса по файловым маскам (globs)

Раздутый app-core.mdc на 417 строк был безжалостно разделен:

• В базом core (для **/*.{ts,tsx}) остались лишь универсальные вещи: структура компонентов, правила импортов, работа с базовой темой, правила навигации и глобальные запреты.
• Всю узкоспециализированную логику вынесли в доменные модули domain-*.mdc с четкими path-globs: правила для оффлайна применяются только при редактировании файлов оффлайн-хранилища, правила виджетов — при работе с кодом виджетов и так далее.

Дополнительно мы создали карту docs/agent-rules-map.md, чтобы разработчики четко понимали, какому файлу соответствует то или иное правило.

Результат: файл core уменьшился с 53 071 до 15 328 байт (−71%). Доменные правила суммарно занимают около 24 КБ, но они больше никогда не загружаются в контекст одновременно.

Фаза 3. Ревизия всегда активных правил и зачистка пакета skills

Я проверил каждое правило с параметром alwaysApply: true и задал вопрос: «Действительно ли это нужно при изменении абсолютно любого файла?»

• Инструкцию integration-docs-sync.mdc перевели на срабатывание по маскам конфигурационных файлов (app.config.js, eas.json, package.json). При редактировании обычных кнопок оно больше не подгружается.
• Правило expo-vendor-skills.mdc оставили всегда активным, но сократили его с 3354 до 1423 байт, вычистив лишние пояснения.
• Правила оформления цветов (theme-colors.mdc) и рабочего процесса (agent-workflow.mdc) сохранили статус always-on из-за их высокой практической ценности.
• Из набора skills вычистили все ненужные модули (eval, hosting, brownfield, DOM-компоненты). Список записей сократился с 26 до 18, а размер папки — с 1,1 МБ до 716 КБ (−35%).

Фаза 4. Закрепление привычек и защита от регрессий

Чтобы оптимизация не откатилась назад через пару недель, мы зафиксировали регламенты:

• Создали документ docs/agent-chat-habits.md с правилами работы: один чат — одна задача, обращение к файлам через @path, использование режима Ask вместо Agent там, где не требуется изменение кода.
• Вдрили правило context-sync.mdc и хуки проверки, которые требуют синхронного обновления доменного правила и соответствующего доменного документа при изменении архитектуры.

Счет «после»: итоговые цифры и сравнение затрат

Результаты проведенной работы превзошли первоначальные ожидания.

Сравнение объема Always-on пакета

• До: 101 908 байт (~25 500 токенов).
• После: 40 823 байт (~10 200 токенов).
• Экономия: −59,9% (~15 300 токенов выигрыша на старте каждого чата).

Сравнение при выполнении обычной UI-задачи

• До: 154 979 байт (~38 700 токенов).
• После: 56 151 байт (~14 000 токенов).
• Экономия: −63,8% (~24 700 токенов сэкономлено на одной правке).

Самый показательный момент: работа в наиболее сложной и хрупкой зоне проекта (с учетом всех специфических доменных правил) теперь забирает около 58 286 байт (~14 600 токенов). То есть решение самой тяжелой задачи сейчас обходится по контексту в 2,5 раза дешевле, чем раньше стоила банальная замена текста на кнопке!

Что мы сознательно отказались сокращать и почему

Слепая минимизация текста без оглядки на результат быстро превращается в вредительство. Мы полностью сохранили следующие элементы:

1. Рантайм-хуки (Hooks): жесткие блокировки записи в нативные директории и обязательные проверки типами/линтерами. Они исполняются в среде, стоят ровно **0 токенов** и работают надежнее любых текстовых промптов.
2. Правило работы с цветами: короткая инструкция, предохраняющая от использования произвольных HEX-кодов в обход темы Figma. Высокая отдача на каждый байт текста.
3. Правило оформления ответа и сдачи задач: структурирует финальный отчет агента и задает формат проведения тестов.
4. Детализированные доменные доки: они остались в полном объеме, просто подтягиваются строго по требованию.

Практические результаты: что изменилось в ежедневной разработке

Качество кода осталось на прежнем высоком уровне — PR проходят ревью без задержек, а хуки исправно отлавливают потенциальные ошибки. Но рабочий процесс стал несоизмеримо комфортнее:

• Контекст больше не исчерпывается на полпути: окно диалога остается практически чистым в момент постановки задачи, модели больше не требуется регулярная суммаризация.
• Лимиты расходуются рационально: подписка закрывает существенно больший объем реально сделанной работы.
• Автоматика стала в разы дешевле: запуск автономных агентов на мелкие багфиксы больше не разоряет бюджет.
• Инструкции стали точнее: нейросеть больше не «тонет» в 400 строках чужих правил, а получает емкое руководство под конкретный модуль.

Чек-лист для вашего репозитория: как оптимизировать контекст самостоятельно

Если в вашем проекте используются файлы CLAUDE.md, AGENTS.md или папка .cursor/rules, выполните простую ревизию:

1. Оцените общий объем постоянно подгружаемых файлов через командную строку (например, командой wc -c CLAUDE.md AGENTS.md .cursor/rules/*.mdc). Разделите результат на 4 — вы получите примерный объем расхода токенов на старте.
2. Задайте три вопроса к каждому документу:
   • Нужно ли это правило абсолютно в каждой сессии? (Если нет — переводите на globs).
   • Дублируется ли эта информация в других файлах? (Удаляйте повторы).
   • Для кого написан этот текст — для человека или для AI? (Человеческие гайды и регламенты выносите в отдельную документацию).
3. Помните главную формулу: правила — самый дорогой инструмент управления ИИ-агентом. Инструменты вроде Hooks, ограничений по globs и продуманной структуры каталогов стоят 0 токенов. Платить стоит только за ту информацию, без которой конкретная задача не может быть решена.

Размышления о трансформации IT-рынка и собственных продуктах

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

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

Источник: habr.com