39 000 токенов на правку кнопки: как команда срезала контекст Cursor-агента на 64%

Мобильное приложение, команда из шести человек. За год проект оброс большим каталожным разделом, оффлайн-режимом, гостевым доступом, сложной формой с предзаполнением, iOS home widgets, OTA-обновлениями и вендорными Expo skills. Параллельно рос слой, который заставляет агентов писать код в стиле команды: CLAUDE.md, AGENTS.md, правила Cursor, доменные документы хрупких зон, hooks. Каждый новый кусок документации решал конкретную проблему, но грузился в контекст всегда.

Симптомы накапливались постепенно. При открытии нового чата с агентом и запросе «поправь отступ у кнопки на карточке» контекст оказывался заполнен наполовину ещё до вопроса. Проценты использования модели в Cursor заканчивались подозрительно быстро для объёма реально сделанной работы. Крупные задачи проходили через несколько циклов суммаризации, после которых агент забывал договорённости двадцатиминутной давности. Контекст заканчивался посреди обычной задачи.

Автор кейса долго считал это ценой качества: правила работают, агент пишет в нужном стиле, hooks не дают сломать нативку — значит, толстый контекст оправдан. Оказалось, что значительная часть оплаты уходила на дубли. Чтобы понять масштаб, он измерил проектный слой грубым методом: 1 токен ≈ 4 байта UTF-8. Это не замер настоящим токенизатором и не данные Cursor Usage, но метрика воспроизводима на одних и тех же артефактах и даёт корректное относительное изменение.

Always-on пакет, который грузится почти в каждый чат, до оптимизации выглядел так: CLAUDE.md — 70 287 байт, AGENTS.md — 9 352 байта, agent-workflow.mdc — 8 632 байта, theme-colors.mdc — 4 831 байт, integration-docs-sync.mdc — 5 452 байта, expo-vendor-skills.mdc — 3 354 байта. Итого 101 908 байт, примерно 25 500 токенов. Один CLAUDE.md занимал 69% пакета. Файл, начинавшийся как короткий контекст продукта для аналитиков, за год превратился в свалку: шаблоны постановки задач, длинный раздел «что ломает PR», карта «где что лежит», продублированная из правил и доменных документов.

На лёгкой правке.ts или.tsx к always-on добавлялся главный кодекс проекта app-core.mdc с glob на все TypeScript-файлы — 53 071 байт, около 13 300 токенов. Итого на лёгкой TS-задаче: 154 979 байт, примерно 38 700 токенов фиксированного слоя. В одном файле на 417 строк лежали правила про гостевой режим, промпты главной страницы, сложную форму, каталожный раздел, оффлайн, виджеты и OTA — всё сразу, независимо от того, что трогает разработчик.

Отдельная статья расходов — skills. Двадцать шесть записей в skills-lock.json, каталог.agents/skills/ на 1.1 МБ, 27 папок. Это вендорные Expo skills, полезный справочник по EAS и Expo API. Но их описания попадают в system prompt каталогом: чем больше skills, тем длиннее меню на каждом ходу. Самый тяжёлый — expo-skill-eval на 148 КБ, eval-харнесс, который в продуктовой разработке не нужен. Никто не выбирал «поставить 26 skills» — пакет поставили целиком, потому что так проще.

Из этого кейса следуют два вывода. Первый: много документации — не всегда хорошо. Каждый отдельный кусок защищаем, проблема не в содержании, а в том, что всё грузится независимо от задачи. Документация полезна, когда приходит в нужный момент; всегда — это не нужный момент, а все моменты сразу. Второй вывод специфичен для автоматизации мелких задач: она меняет экономику контекста. Когда агент решает две крупные фичи в день, фиксированный слой в 39 000 токенов амортизируется. Когда через агента идёт поток мелких правок, тот же слой становится основной статьёй расходов.

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