Недельный лимит на 20x-подписках Claude и Codex раньше не заканчивался у автора разбора на Towards Data Science: одна подписка Claude и одна Codex закрывали рабочую неделю с запасом. Сейчас лимит Codex он расходует примерно за 10-12 часов, а подписку Claude получается исчерпать в течение одного дня. Это не гипотетический сценарий, а описанный им опыт в материале How to Maximize Your Coding Agent Subscriptions.
Причина не в одной переменной. Кодовая база растёт, вместе с ней растёт объём контекста, который агент читает на каждой задаче. Доступ к более дорогим моделям расширяется, а планы подписок становятся менее щедрыми. Агенты всё чаще запускаются параллельно, и каждый из них тащит свой контекст. Автор перечисляет эти факторы вместе: репозиторий, модели, политика компаний и одновременные запуски.
Ответ на главный вопрос укладывается в три шага. Сильную модель стоит держать в роли оркестратора, рутину отдавать субагентам на дешёвых моделях, а саму кодовую базу и markdown-инструкции регулярно чистить. Ниже разобраны все три направления плюс арифметика дополнительных подписок и подводные камни, из-за которых оптимизация может не сработать.
Почему лимиты подписок на кодинг-агенты стали расходоваться быстрее
Пользовательские привычки не изменились радикально: те же задачи в том же репозитории. Изменился объём работы, который агент выполняет ради одной задачи. Claude Code и Codex в режиме активного использования читают больше файлов, дольше исследуют зависимости и чаще перезапускаются после ошибок.
Как рост кодовой базы и параллельные агенты съедают токены
Агенту нужен контекст: он открывает файлы, читает зависимости, тесты, логи сборки, вывод команд. Чем крупнее репозиторий, тем больше материала попадает в окно контекста ещё до того, как модель напишет первую строку кода. Существенная часть расхода приходится именно на входные токены, а не на ответы: об этом косвенно говорит и разбор Deep Agents v0.7, где сокращение входных токенов с ~6k до ~2k подаётся как главный источник экономии.
Параллельные агенты умножают этот расход. Простая арифметика: если один агент тратит на задачу X токенов, три одновременных агента с похожими циклами израсходуют лимит примерно втрое быстрее. Автор источника называет этот пункт прямо: "We simply code more, and more agents in parallel".
Влияние дорогих моделей на расход подписки
Второй фактор, цена модели в токенах. В источнике как примеры дорогих и умных моделей названы Claude Fable и GPT-6-Astra: чем больше задач проходит через них, тем быстрее тает лимит подписки.
Линейка при этом обновляется в сторону удешевления. Anthropic представила Claude Opus 5.5: по данным источника, модель на 40% дешевле Opus 5 и более чем на 30% быстрее. OpenAI запустила GPT-6 Sol и GPT-6 Luna: более быстрые и дешёвые модели на базе Astra. Оба запуска упоминаются в публикации об обновлениях Anthropic и OpenAI.
Вывод практический: выбор модели работает как основной рычаг экономии. Перевод рутины с дорогой модели на дешёвую уменьшает число токенов, которые оплачиваются по высокой ставке, и это заметнее любых правок формулировок в промптах.
Оркестрация моделей: как распределять задачи между сильными и дешёвыми моделями
Главная рекомендация автора разбора: самые сильные модели работают оркестратором, а простые задачи уходят меньшим моделям. Оркестратор держит общую картину, разбивает задачу на подзадачи и проверяет результат. Субагенты исследуют код, пишут конкретные фрагменты, гоняют тесты.
Практическая схема: оркестратор и субагенты
- Формулируете задачу для оркестратора: цель, границы изменений, критерии готовности. В примерах источника эту роль играют Claude Fable и GPT-6-Astra.
- Оркестратор декомпозирует работу: какие файлы нужно найти, что изменить, что проверить тестами.
- Подзадачи уходят субагентам на меньших моделях вроде GPT-5.6 SOL или Claude Opus. Они ищут нужные места в коде, читают зависимости, пишут код по понятному техническому заданию.
- Оркестратор получает результат, сверяет его с критериями и собирает изменения в одно целое.
Экономия возникает из-за распределения ролей: дорогая модель не перечитывает репозиторий на каждом шаге, она работает с короткими отчётами субагентов. Плата за это тоже есть, схему нужно настроить, а качество результата зависит от того, насколько точно сформулированы подзадачи. Если субагент понял задание неверно, оркестратор ловит это на этапе проверки, но время уже потрачено. Общий принцип выбора модели под задачу подробнее разобран в материале о дешёвых и дорогих моделях.
Какие модели выбирать для оркестрации и для рутины
| Роль | Примеры из источника | Зачем |
|---|---|---|
| Оркестратор | Claude Fable, GPT-6-Astra | Декомпозиция задачи, проверка результата, работа с общей картиной |
| Субагенты | GPT-5.6 SOL, Claude Opus | Исследование кода, написание конкретных фрагментов, прогон тестов |
| Альтернативы для рутины | Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna | Дешевле и быстрее предшественников по данным источника |
Оговорка: список моделей в источнике обрывается на фразе про самые умные модели, поэтому полного перечня рекомендаций там нет. Все названия выше, примеры автора, а не результат независимого сравнения. Классификация Claude Opus как меньшей модели тоже авторская формулировка, она отражает разницу с флагманами в его наборе подписок. Названия моделей, которые исследовательские обзоры относят к среднему ценовому уровню, могут вести себя иначе на сложных архитектурных задачах.
Оптимизация кодовой базы: рефакторинг, чистка markdown и удаление лишних расширений
Второй контур экономии, сам репозиторий. Агент платит токенами за всё, что читает. Один и тот же баг в аккуратном проекте стоит меньше, чем в свалке файлов на тысячи строк.
Как избавиться от «god files» и уменьшить контекст
«God files» это файлы, которые разрослись до состояния, когда агент загружает их целиком, хотя нужна одна функция из середины. Дробление на модули даёт агенту выбор: прочитать небольшой файл вместо простыни. Иллюстрация: файл на 2000 строк и десять файлов по 200 строк содержат тот же код, но во втором случае в контекст попадает только релевантная часть, а не весь монолит.
Дополнительный эффект, точность навигации. В модульном проекте по именам файлов и импортам агенту проще понять, где искать логику, и он реже открывает лишнее. Рефакторинг ради агента совпадает с рефакторингом ради людей, платить дважды не приходится.
Чистка CLAUDE.md и AGENTS.md: что удалять и почему
Markdown-файлы с инструкциями подгружаются в контекст регулярно, поэтому всё лишнее в них жгут токены на каждой задаче. Лайфхак, который разошёлся в публикации с упоминанием разработчика из Anthropic: попросить агента проверить ваши скиллы и промпты, а затем убрать устаревшие инструкции и антипаттерны, которые только мешают и расходуют токены. Тот же приём тестировался на связке с Opus 5.5.
На практике ревизия сводится к нескольким категориям. Удалять: правила для модулей, которых уже нет в репозитории; дублирующиеся указания, сформулированные дважды разными словами; противоречащие друг другу команды, из-за которых агент мечется между вариантами; устаревшие команды сборки и тестов. Полезно оставить критерии готовности, границы прав и короткие примеры желаемого стиля кода. Чем меньше в файле шума, тем меньше токенов уходит на его чтение и тем меньше шансов, что модель выберет устаревшую инструкцию.
Удаление неиспользуемых skills и hooks
Skills и hooks, оставшиеся от прошлых задач, продолжают подключаться к сессиям и попадать в контекст. Ревизия выглядит так: выписать активные расширения, сверить их со списком реально выполняемых задач, отключить или удалить те, что не применялись ни разу за последние недели. Это часть регулярного обслуживания, как обновление зависимостей: раз в несколько недель дешевле, чем разовая генеральная уборка.
Стоит ли покупать дополнительные подписки вместо оптимизации
Арифметика из источника настраивает на скепсис. Каждая подписка стоит $200 в месяц. Если расходовать лимит за один рабочий день, для непрерывной работы понадобилось бы семь подписок, и содержание такого набора обойдётся дорого. Именно этот расчёт автор приводит как аргумент против простого наращивания числа аккаунтов.
Дополнительные подписки увеличивают запас лимитов, но не меняют привычку тратить токены неэффективно. Если оркестрация не выстроена, а кодовая база захламлена, вторая и третья подписки сгорят с той же скоростью. Оптимизация стоит времени, зато снижает зависимость от количества аккаунтов. Подходы к масштабной работе с лимитами и подписками разобраны отдельно в материале о подписках и скрытых лимитах.
Разумный порядок действий: сначала распределить модели по ролям, почистить репозиторий и инструкции, замерить фактический расход на типовой задаче. Дополнительная подписка уместна, когда узкое место осталось, а расход уже приведён в порядок. Категоричной рекомендации здесь быть не может: у команд разная интенсивность работы и разные требования к приватности кода.
Как использовать кредиты и новые модели для экономии
Anthropic раздаёт бесплатные кредиты для Claude Code: подписчики Pro получают $100, пользователи Max $250. Кредит выдают один раз на аккаунт, и потратить его можно только для облачных сессий, о чём говорится в той же публикации о лайфхаке для Claude Code. Кредит не отменяет лимиты подписки, но позволяет часть работы прогнать мимо основного счётчика.
Новые модели дают второй источник экономии. Claude Opus 5.5 дешевле и быстрее Opus 5, GPT-6 Sol и GPT-6 Luna заявлены как более быстрые и дешёвые варианты на базе Astra. Их логично ставить на подзадачи, которые раньше выполняла дорогая модель: поиск по коду, написание тестов, рефакторинг небольших функций. Про обновления инфраструктуры вокруг таких моделей, включая контекст на 1 млн токенов для GPT-5.6 Sol, Terra и Luna и инструменты контроля расходов, есть отдельный разбор обновлений Amazon Bedrock и AgentCore.
Ограничения здесь стоит держать в голове. Кредиты одноразовые и временные, облачные сессии подходят не для каждого рабочего процесса. Для новых моделей в источниках нет подробных технических характеристик, поэтому на сложных задачах их поведение придётся проверять самому, прежде чем переводить на них ответственную работу.
Ограничения и подводные камни оптимизации
- Оркестрация требует времени на настройку: нужно описать роли, критерии готовности и порядок проверки результатов субагентов.
- Часть задач не стоит делегировать дешёвым моделям. Архитектурные решения и работа с неочевидными багами требуют сильной модели, экономия на них оборачивается переделками.
- Рефакторинг и чистка markdown занимают часы, а эффект проявляется позже. Это инвестиция, а не мгновенная экономия.
- Кредиты Anthropic одноразовые и только для облачных сессий, рассчитывать на них как на постоянный источник лимитов нельзя.
- Для новых моделей, включая GPT-6 Sol и GPT-6 Luna, в источниках нет данных о точности на сложных задачах. Точность придётся оценивать на своих сценариях.
- Параллельные агенты повышают продуктивность, но усложняют слияние изменений и повышают расход на общий контекст.
Итог: как сохранить продуктивность при меньшем расходе токенов
Рабочий порядок действий для той же подписки выглядит так.
- Распределить роли: сильная модель оркестратором, рутина субагентам на дешёвых моделях.
- Провести ревизию репозитория, раздробить «god files», вынести модули с понятными границами.
- Почистить CLAUDE.md и AGENTS.md: убрать устаревшие инструкции, дубли, противоречия и антипаттерны. Для этого можно поручить проверку самому агенту.
- Отключить неиспользуемые skills и hooks, которые попадают в контекст без пользы для текущих задач.
- Следить за новыми моделями и кредитами провайдеров, перенося рутину на более дешёвые варианты.
- Оценивать дополнительные подписки только после того, как расход на типовой задаче приведён в порядок.
Начните с одного шага, который даёт самый быстрый эффект: переведите одну массовую операцию, например поиск по коду или написание тестов, на меньшую модель и посмотрите, как меняется расход за день. Дальше станет видно, чего не хватает больше: чистки кодовой базы или второй подписки.