12 суток я платил $44 в день за гейт, который сам же выключил
На одном домашнем сервере у меня сейчас открыто 107 tmux-сессий. В большинстве живёт Claude Code, у каждой свой проект и свой каталог. Одна пишет статьи, другая чинит сайт, третья следит, чтобы остальные не висели брошенными.
Со стороны это выглядит как «запустил сто нейросетей и пошёл пить чай». На деле почти вся работа ушла не в промпты, а в экономику: кто за что платит, кто кому передаёт результат и что происходит, когда правило живёт дольше, чем ты думаешь.
Расскажу, как это устроено, и где я ошибся дороже всего.
Главное открытие: платишь не за ответ, а за память
Каждый вызов модели заново читает весь накопленный разговор. Кэш удешевляет это чтение, но не отменяет. Я посчитал по своим логам за 30 дней, с 8 августа по 8 сентября: 237 тысяч вызовов старшей модели, кэш прочитал 23,75 млрд токенов, а записал 0,96 млрд. Чтения в 25 раз больше, чем записи.
Если разложить всю стоимость вызовов на токены контекста, выходит $67 за миллион. Средний вызов обходится в $0,33.
Отсюда первое правило: длинная сессия дорожает квадратично. Разговор на 150 тысяч токенов при каждом следующем шаге снова оплачивает все 150 тысяч. Поэтому пять коротких сессий дешевле двух длинных. У меня сессия сжимается на 78% окна, а при смене темы закрывается целиком: пишет записку-хендофф и перезапускает себя сама.
Три слоя исполнителей
Старшая модель (Opus) у меня только дирижёр. Архитектура, спорные решения, ревью, итоговый вывод. Всё, что можно отдать, она отдаёт.
Первый слой вниз называю пулом A: субагенты той же подписки. По умолчанию младшая модель Haiku, потому что с 1 августа по 8 сентября средний субагент на Sonnet стоил $1,76, а на Haiku $0,25. Разница в 7 раз, при этом шагов у Sonnet всего в 1,4 раза больше. Sonnet беру, только когда могу назвать причину: большой рефакторинг или отладка с гипотезами.
Второй слой, пул B, вообще не трогает лимит Claude. Это внешние CLI-агенты по другим подпискам и API: Codex, Gemini и ещё пара запасных. Задание уходит в очередь скриптом, ответ приходит файлом. Самодостаточную работу вроде «исследуй тему» или «напиши модуль по спецификации» стараюсь отдавать сюда.
Как сессии говорят друг с другом
Сто сессий бесполезны, если результат одной надо руками копировать в другую. Раньше так и было: я был шиной данных между собственными агентами.
Теперь есть почтовая шина на файлах. Сессия пишет сообщение в папку адресата, живому получателю оно сразу врезается в разговор, спящему приходит при первом же промпте. Если отправитель требует подтверждения, получатель обязан ответить ACK с итогом одной строкой.
На сегодня в шине 185 почтовых ящиков и 6 123 сообщения, 1 701 из них за последнюю неделю. Подтверждения требовали 2 236, без ответа висят 54.
И тут же пример, почему ACK ещё не значит «сделано». Сегодня сессия-публикатор подтвердила задание, перезапустилась по контексту, и в её записку для следующей сессии задание не попало. Координатору пришлось отправить повтор с пометкой «ты это приняла, но потеряла». Подтверждение доказывает только доставку, а не память получателя.
Теперь про ошибку за $300 в неделю
Летом я сделал гейт: хук, который отбивал вызовы старшей модели, если та пыталась сама делать то, что положено делегировать. Идея здравая: машина сама принуждает к экономии, без абзацев в инструкции.
19 августа я решил, что гейт больше мешает, чем помогает, и выключил принуждение. Переменную убрал из обоих файлов настроек.
31 августа я поднял журнал решений гейта за неделю и увидел, что принуждение работает. 16 433 записи из 24 321 (68%) были помечены как принудительные, в 186 сессиях, каждый день.
Причина оказалась третьей копией той же переменной в .bashrc. Когда-то я продублировал её «для сессий из интерактивного шелла». А все мои сессии стартуют как раз из шелла, через tmux. Две видимые копии я убрал, третья тихо работала ещё 12 суток.
Цена такая. Настоящих отказов за неделю было 1 183. Каждый отказ съедает один лишний вызов старшей модели: она читает отказ, думает, переделывает. По тогдашней цене это около $0,26, то есть $44 в сутки или $308 в неделю. 911 отказов из 1 183 выдала именно та ветка, которую я считал выключенной.
Выгоды я не нашёл. Работа не стала переезжать во внешний пул чаще. Сессии просто тратили лишний ход на спор с хуком.
Что я из этого вынес. Теперь любое число в правилах держится на скрипте, который его перемеряет, а тест падает, если число в коде разошлось с замером. Для переменной в трёх местах есть отдельная проверка по факту, а не по тексту файлов. Гейт остался включён только как измеритель: журнал пишет, но ничего не запрещает.
Вторая ошибка: «держать всех занятыми»
Была инструкция «держи три субагента в работе». На одной сессии она разумна. Эту инструкцию подхватили 103 сессии сразу.
За 30 минут в 217 разговорах появился ответ 429 «сервер временно ограничивает запросы». Это был лимит на одновременность, а не на объём. Агенты начали повторять запросы, и повторы сами стали штормом. Оборванный агент при этом ничего не списывал: получили и простой, и нулевую работу.
Правило теперь обратное: один субагент за раз, на 429 не повторять, задачу сразу во внешний пул.
Что в итоге
Сто сессий оказались не про мощность, а про учёт. Работает то, что измерено прибором и проверено по факту. Правила, записанные текстом, живут своей жизнью и иногда дольше, чем ты думаешь.
Открытым остаётся главный вопрос: окупается ли вообще такая конструкция по сравнению с одним человеком и одним чатом? Я считаю стоимость на одно своё сообщение, а не токены в сутки. Но честного сравнения с «одним человеком и одним чатом» у меня нет, и уверен, что у кого-то из вас есть контрпример.
Кто гонял несколько агентов параллельно, на чём у вас всё развалилось первым?