Вайб-кодинг без слитого лимита: как раздать работу Haiku и Sonnet и не жечь Opus

Короткий ответ сразу: если ты вайб-кодишь через агентов и недельный лимит Opus тает на глазах, перестань гонять дорогую модель на поиск по файлам. Пусть сильная модель работает оркестратором - понимает задачу, режет её на куски, проверяет результат. А всю механику раздай дешёвым: Haiku ищет и читает, Sonnet вносит правки. Автор фреймворка pilotfish так срезал стоимость работы почти на 70%. Ниже разложу, кому что отдавать, сколько это реально экономит и где дешёвая модель облажается, если ей дать не ту задачу.

Я про это думаю не первый месяц. У меня целый парк агентов на сервере пишет статьи, тестит ботов и чинит сам себя, и однажды одна неудачная команда сожгла 20% недельного лимита за раз. После этого вопрос "кто на какой модели крутится" перестал быть теоретическим.

Почему оркестратор должен думать, а не искать файлы

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

Логика тут как в нормальной команде. Тимлид не сидит и не грепает кодовую базу руками восемь часов - он раздаёт куски джунам и мидлам, а сам держит в голове картину целиком и ревьюит результат. Если посадить сеньора читать логи весь день, ты платишь сеньорские деньги за джуновую работу. С моделями ровно то же самое, только "деньги" - это либо токены по API, либо твой недельный лимит в подписке Claude Code, который тоже конечен и тоже жалко.

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

Как раздать роли по моделям: кто ищет, кто правит, кто проверяет

Роли раскидывают по тирам моделей. Haiku ищет и читает файлы, Sonnet вносит понятные правки, Opus берёт сложные места и финальную проверку. Во фреймворке pilotfish ролей вообще пять: скаут-поисковик, механический исполнитель, обычный исполнитель, отдельный ревьюер и безопасник. Каждый сидит на своей модели по цене задачи, а оркестратор дирижирует.

Разложу по-человечески, кому что:

• Haiku - разведка. Найти все места, где используется метод, вычитать структуру папки, собрать список файлов под задачу. Тупая механика без творчества.
• Sonnet - руки. Внести понятную правку по чёткому ТЗ, обновить тесты по шаблону, переписать функцию, когда уже ясно как. Он умнее Haiku, но всё ещё сильно дешевле топа.
• Opus - голова и приёмка. Архитектурные развилки, хитрые баги, безопасность и финальная проверка того, что наисполняли младшие.

Прелесть в том, что модель под каждую роль выбираешь по цене задачи, а не "везде самое дорогое, чтобы наверняка". "Чтобы наверняка" - это как раз то, что жрёт лимит.

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

Сколько это экономит на самом деле

Экономия не выдуманная. Создатель pilotfish пишет про минус 70% к стоимости работы. По ценам Anthropic на июль 2026 Haiku 4.5 стоит $1/$5 за миллион токенов вход/выход, Sonnet 4.6 - $3/$15, Opus 4.8 - $5/$25. То есть Haiku примерно в 15 раз дешевле Opus за токен. А флот из одного Opus, трёх Sonnet и одного Haiku обходится в $48.75 в день против $81.25 за пять Opus - на 40% дешевле при том же объёме работы.

Если ты, как я, сидишь не на поштучной оплате API, а на подписке с недельным лимитом - арифметика та же, просто валюта другая. Ты платишь не долларами, а квотой. И когда оркестратор перестаёт лично читать каждый файл, эта квота растягивается в разы. У меня после переезда части работы со скиллов на более дешёвые схемы недельный лимит стал уходить в 4 раза медленнее - тот же принцип, просто с другой стороны.

Плюс поверх этого есть чисто технические скидки, которые грех не включить: prompt caching режет стоимость кэшированного входа на 90%, а батч-обработка - на 50%. Если у тебя агенты гоняют один и тот же большой контекст по кругу, кэш экономит не хуже, чем смена модели.

Где экономия на дешёвой модели выходит боком

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

Это, кстати, главный контринтуитивный момент. Люди думают, что дешёвая модель "тупая и справится только с ерундой". На деле она справляется и с серьёзными кусками - но только если ей дать прямую инструкцию, а не абстрактную. Разница не в сложности задачи, а в том, насколько чётко она поставлена. Абстракцию и неопределённость держит оркестратор, конкретику раздаёт вниз уже разжёванной.

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

Как раздать модели в Claude Code руками

В Claude Code модель субагента задаётся полем model прямо в его определении - алиас haiku, sonnet, opus или inherit, чтобы наследовать модель родителя. А для общего потолка на весь флот есть переменная окружения CLAUDE_CODE_SUBAGENT_MODEL: она перекрывает всё остальное в порядке разрешения. То есть можно и точечно раздать роли, и одной строкой прижать всех субагентов к дешёвой модели, когда лимит на исходе.

Моя рабочая схема простая. Оркестратор - на сильной модели, он у меня один и он думает. Исполнителей опускаю на тир-два ниже: поиск и чтение - на самую дешёвую, правки по готовому ТЗ - на среднюю. И держу в голове аварийный рубильник через переменную окружения на случай, когда до конца недели далеко, а квота уже подмигивает красным.

Такой подход, к слову, честнее старой идеи "просто нафигачить побольше агентов". Больше агентов на топовой модели - это быстрее и дороже одновременно, а тут ты платишь ровно за тот интеллект, который нужен каждому конкретному куску. Дёшево там, где можно, дорого там, где правда надо.

Коротко, что унести с собой

Держи сильную модель оркестратором и не давай ей лично грепать репозиторий. Механику - поиск, чтение, правки по шаблону - раздавай Haiku и Sonnet прямыми инструкциями. Архитектуру и финальную проверку не отпускай с топовой модели никогда. И помни главную ловушку: дешёвая модель заваливает не сложное, а размытое. Ставь задачу чётко - и минус 70% к счёту не сказка, а просто нормально розданная работа.

А я пойду перекину ещё пару своих агентов на Haiku, пока лимит смотрит на меня с укором. Такие дела.