Скиллы Claude Code съедали недельный лимит за 4 дня: как я стал тратить в 4 раза меньше

Короткая версия: недельный лимит подписки таял за 4 дня не потому, что я дохрена работал, а потому что каждый ход таскал в контекст жирнющий скилл целиком. Перебрал всю архитектуру работы с Claude Code - правила, скиллы, скрипты - и тот же объём задач стал стоить около 5% недельного лимита вместо 20%. Разбираю, что именно жрало и что я поменял.

Началось всё буднично. Запустил большую задачу с кучей подзадач, пошёл пить чай, вернулся - а Claude упёрся в 5-часовой лимит, задачи не доделал, и при этом схавал 20% недельного лимита. За один заход. То есть при таком раскладе моя подписка кончалась к четвергу, а неделя - нет.

Почему Claude Code быстро съедает недельный лимит

Claude Code считает расход в двух окнах одновременно: скользящее 5-часовое окно сессии и недельный лимит поверх него. В каждый ход модель получает на вход всю беседу с начала, ваш CLAUDE.md, все файлы, которые она уже прочитала, и новый запрос. Чем толще этот вход, тем дороже каждый ход. Лимит жрут не задачи, а контекст, который вы возите с собой.

Это не мои догадки, это прямо написано в справке Anthropic: расход считается и в сессионное, и в недельное окно одновременно, а недельный лимит сбрасывается в фиксированное время, привязанное к аккаунту (то есть "подожду часок, отпустит" тут не работает).

Второй множитель - модель. По той же справке Opus стоит в несколько раз дороже за ход, чем Sonnet, а Sonnet дороже Haiku. Anthropic прямым текстом советует: Sonnet для большинства кодинга, Opus когда реально застрял, Haiku на быструю механическую работу. Я же, как приличный человек, сидел на Opus и удивлялся, чего это лимиты тают.

Но модель - это множитель. А база, которую этот множитель умножает, это входной контекст. И вот с базой у меня был кал гавна.

Что такое progressive disclosure в скиллах Claude Code

Progressive disclosure - это принцип, по которому скилл грузится в контекст не целиком, а слоями, по мере надобности. В официальной документации Anthropic это разложено по трём уровням с ценником в токенах, и именно этот ценник объясняет, почему один скилл может стоить копейки, а другой - выжирать окно.

Уровень 1, метаданные: name и description из YAML-фронтматтера. Грузятся всегда, при старте, и стоят около 100 токенов на скилл. Это тот текст, по которому Claude решает, брать скилл в работу или нет.

Уровень 2, инструкции: тело SKILL.md. Грузится только когда скилл сработал, и должно укладываться меньше чем в 5к токенов.

Уровень 3, ресурсы: остальные файлы рядом со скиллом (референсы, схемы, скрипты). Стоят ноль, пока их не прочитали.

Формулировка из доков, которую стоит повесить над столом: "Files don't consume context until accessed". Пока файл лежит на диске и его не открыли - он бесплатный. Можно навалить в скилл хоть всю документацию, и она не будет стоить ничего, если под задачу нужен один файл.

Вот тут до меня и дошло, где я лоханулся.

Почему я ушёл с чужого скилла

Я сидел на скилле Паши Молянова. Скилл крутой, вопросов нет, но жрал он неимоверно. Причина ровно та, что выше: он был устроен как один толстый монолит, который заезжает в контекст целиком и висит там весь диалог. И висит он не один раз, а в каждом ходу - потому что весь предыдущий диалог едет на вход снова и снова.

Пак у меня до сих пор лежит в архиве (~/.claude/molyanov-archive-2026-07-13/), так что цифры не по памяти - сходил и померил. Восемь скиллов, суммарно ~106 КБ markdown. Чемпионы: test-master - 35 КБ одним куском, tech-spec-planning - 17.7 КБ. И главное: references-файлов у этих скиллов нет вообще, вся масса - в телах, то есть на уровне 2, который грузится целиком при срабатывании. Порезать нечего - оно так спроектировано. А рабочий процесс пака гонял скиллы цепочкой: спека, декомпозиция, код, тесты, ревью - несколько таких тел могли оказаться в одном диалоге разом.

Дальше простая арифметика. Жирное тело скилла умножается на количество ходов, а потом ещё на коэффициент Opus. Один запуск большой задачи - и 20% недели нет.

Прости, Паша. Скилл правда был хороший, просто не под мой режим долбёжки.

Как я перестроил пак

Переписывал я три вещи: правила, скиллы и скрипты. Заточено всё под мой DnD-проект, но принципы переносимые.

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

Как это выглядит на живом примере - мой скилл blog (пайплайн статей этого блога):

~/.claude/skills/blog/
├── SKILL.md                              13.4 КБ  ← грузится при срабатывании
└── references/                           35.8 КБ  ← бесплатно, пока не открыто
    ├── voice-research-2026-07.md         17.4 КБ  (голос автора, с цитатами)
    ├── research-interview-factcheck.md    4.9 КБ  (методика фактчека)
    ├── target-profile-protocol.md         3.7 КБ  (профили площадок)
    ├── seo-module.md                      3.7 КБ  (семантика, перелинковка)
    ├── data-privacy.md                    3.2 КБ  (что нельзя в текст)
    └── aeo.md                             2.8 КБ  (цитируемость в AI-поиске)

Три четверти массы скилла лежат на уровне 3 и не стоят ни токена, пока конкретная фаза до них не дошла: пишем не-SEO заметку - seo-module.md так и остаётся на диске. В монолитной компоновке все эти 49 КБ ехали бы в контекст каждый раз одним куском - как у test-master выше.

Второе: описания. Раз description висит в системном промпте всегда, он должен быть коротким, но точным: что скилл делает и когда его брать. Расплывчатое описание - это двойной проигрыш: и токены на старте платишь, и скилл срабатывает не там, где надо, или не срабатывает там, где надо.

Как выглядит уровень 1 вживую - фронтматтер моего скилла humanizer-ru (он вычищает машинные паттерны из русских текстов), ровно то, что висит в системном промпте постоянно:

---
name: humanizer-ru
description: "Use when: нужно очеловечить (humanize) сгенерированный ИИ
  текст на русском. Убирает 25 машинных паттернов, делает язык живым
  и естественным."
---

Две строки, есть триггер ("нужно очеловечить") и есть суть (25 паттернов). Всё остальное - таблица паттернов, примеры до/после - лежит в теле и references и не стоит ничего, пока скилл не сработал. Сравните с описанием в духе "скилл для улучшения текстов" - оно и длиннее не станет, и срабатывать будет через раз.

Третье: скрипты вместо генерации. Это, пожалуй, самая недооценённая штука во всей истории.

Скрипты дешевле, чем генерация кода

Когда Claude запускает скрипт через bash, код скрипта не попадает в контекст - в контекст приезжает только вывод. В доках это сказано буквально: "the script code itself never enters context", и поэтому скрипты сильно эффективнее, чем заставлять модель каждый раз генерировать эквивалентный код на лету.

Разница на пальцах. Вариант первый: модель пишет питоновский скрипт на 80 строк, вы его гоняете, он падает, она правит - и весь этот код лежит в контексте до конца сессии, переезжая из хода в ход. Вариант второй: скрипт лежит в скилле готовый, модель делает python3 scripts/thing.py, получает три строчки вывода. Эти три строчки и есть вся цена.

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

Ещё один рычаг - субагенты. Идея в том, что тяжёлое копание (поиск по репе, чтение десятка файлов) уезжает в отдельный контекст, а в основной возвращается только выжимка. В разборе на Хабре про изоляцию контекста автор пишет, что так основной контекст держится в районе 10-15к токенов вместо 50к+. Свои цифры я не мерил, так что беру это как чужое наблюдение, а не как свой факт. Но направление верное: не тащить в главный диалог то, что можно посмотреть и выбросить. У субагентов, правда, свои грабли с лимитами - неограниченный фан-аут выжирает недельное окно быстрее любого толстого скилла, про это у меня отдельный разбор.

Что вышло в цифрах

Тут по-хорошему должна быть табличка бенчмарка, но скажу честно: строгого замера у меня нет. Есть две точки с показометра лимитов. Точка первая, с которой всё началось: один запуск большой задачи на старом паке съел 20% недельного лимита - такое число на экране запоминаешь без блокнота. Точка вторая: после перестройки тот же режим работы (те же проекты, та же долбёжка) укладывается в районе 5% недели. Это оценка по показометру, не эксперимент с контрольной группой - соотношение "примерно вчетверо" беру из неё.

А вот что можно проверить строго - размер того, что едет в контекст. Старый пак: ~106 КБ телами, references нет, режется только целиком. Новый: у того же blog в контекст при срабатывании едет 13.4 КБ из 49, у code-writing - 5.9 КБ из 17. Доля обязательной массы упала с 100% до 25-35%, и ровно эта масса умножается на каждый ход диалога. Откуда берётся кратная экономия - видно из этой арифметики даже без бенчмарка.

И тут нужна честная оговорка, без неё цифры врут. Мерил я 4 мая 2026 года. А 6 мая, то есть через два дня, Anthropic удвоил 5-часовые лимиты Claude Code для Pro, Max, Team и seat-based Enterprise и убрал урезание лимитов в пиковые часы для Pro и Max. Так что мои 20% и 5% - это замер по старому режиму. Если вы повторите сегодня, абсолютные проценты будут другими, а вот соотношение между толстым и тонким паком никуда не денется: оно про архитектуру контекста, а не про щедрость тарифа.

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

Чек-лист: как не жечь лимит впустую

Что бы я сделал сразу, если бы начинал заново:

1. Порезать толстые скиллы по уровням. В теле SKILL.md - процедура, всё остальное в соседние файлы. Они бесплатные, пока не открыты.
2. Вылизать description у каждого скилла. Он в системном промпте всегда, около 100 токенов за штуку, и он же решает, сработает скилл или нет.
3. Всё детерминированное - в скрипты. Код скрипта не едет в контекст, едет только вывод.
4. Не сидеть на Opus по умолчанию. Sonnet на большинство кодинга, Opus когда застрял.
5. Держать CLAUDE.md тощим. Он приезжает на вход каждый ход, а не один раз на старте.

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

А я пойду работать дальше.