Почему автор вернулся на окно 200K в Claude
Автор пет-проекта сначала спокойно укладывался в подписку за $100, потом перешёл на $200, но и этого стало не хватать из-за длинных сессий и дорогого чтения большого контекста. В итоге он решил не наращивать расходы, а перестроить работу с Claude так, чтобы тратить токены заметно экономнее.
Почему лимитов стало не хватать
Весной подписки за $100 хватало почти на все задачи по пет-проекту, и даже полная выработка дневного лимита выглядела как интересный вызов. Но уже к лету сценарий изменился: сначала удавалось закрывать полный лимит, потом — только прорабатывать технический дизайн, а реализацию приходилось откладывать до следующей недели.
К сентябрю автор уже использовал подписку за $200, однако и её потолок оказался вполне достижимым. Он заметил, что знакомые и коллеги тоже быстро упираются в ограничения, а идея просто докупать ещё мощности выглядит всё менее разумной.
Что оказалось самым удобным и самым дорогим
Главный расход токенов был связан не с какой-то сверхсложной логикой, а с рабочим стилем. Автор любил собирать сразу пачку из 5–15 хорошо проработанных задач и отправлять их в разработку одним заходом, а верхнеуровневый агент мог потом часами их переваривать без участия человека.
Это было удобно: вечером он формулировал задачи, ночью агент работал сам, а утром оставалось только проверить результат, иногда с помощью GPT. Но у схемы быстро проявились слабые места. Если сессия была очень длинной, кэш начинал протухать, а повторные обращения к старому контексту на сотни тысяч токенов становились заметно дороже.
Дополнительную боль создавали субагенты. Их кэш живёт недолго, а если задача затягивалась больше чем на час, верхнеуровневый агент будился заново. В итоге приходилось снова платить за чтение большого контекста, а при сессиях на 800K токенов это ощущалось особенно сильно.
Как он перестроил работу с Claude
Автор пришёл к выводу, что длинные сессии лучше не растягивать бесконечно, а объёмные задачи делить на части. Для разных ролей он и раньше использовал отдельные промпты: аналитик разбирает задачу, разработчик пишет код, ревьювер и QA проверяют результат. Такой подход помогает ловить больше ошибок, потому что у каждого агента свой узкий фокус.
Теперь он советует не гонять дорогих моделей на всё подряд. Для мелких кросс-репозиторных исправлений и разработки можно брать более дешёвые варианты вроде Sonnet, для поиска — даже Haiku, а тяжёлую аналитику и ревью отдавать Opus или Fable. Ещё один важный совет — просить аналитического субагента заранее дробить большие задачи, чтобы контекст исполнителей не разрастался без необходимости.
Отдельно автор подчёркивает, что не стоит будить спящих субагентов ради мелких правок: в таком случае вы фактически платите заново за их контекст. В его практике именно бытовая организация процесса, а не сама сложность задач, сильнее всего влияет на итоговые расходы.