Флот агентов для Claude Code собирает один HTML-файл

Мастер fleet-generator, который появился на Show HN 3 сентября, собирает для Claude Code или Codex флот из трёх ролей вместо одного агента. Весь флот построен вокруг одного правила: оркестратор не пишет код сам. Автор формулирует это жёстко: оркестратор, который печатает код своими руками, проваливает собственную работу, и срезанным путём это не считается.

Сам продукт - один файл web/fleet-generator.html, его не нужно ставить или собирать. Вы открываете его в браузере, отвечаете на вопросы и скачиваете zip. Всё работает локально, ничего не загружается на сервер, как сказано в описании репозитория на GitHub. В архиве лежит каталог .claude/ с определениями агентов, навыками, хуками, слэш-командами под выбранные сценарии, settings.json, к которому подключены хуки, и скриптом установки. Каталог кладётся в репозиторий, и в следующей сессии агенты уже на месте.

Зачем делить работу на роли

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

Одиночный агент, по словам автора, работает по умолчанию и обходится дороже всего: держит всю задачу в одном контексте, рассуждает о ней целиком на старшей модели и сам набирает каждую строку. Флот опирается на устройство субагентов в Claude Code. Каждый субагент работает в собственном окне контекста со своим системным промптом и набором инструментов и возвращает основному диалогу только сводку. Экономия при этом не бесплатная: документация Claude Code предупреждает, что запросы субагента расходуют те же лимиты, что и основной разговор.

Цифры автор приводит по живым прогонам. Оркестраторы, которые раздавали реализацию, прогоняли через субагентов около 64% токенов. Те, что писали код сами, держались в пределах 0-32% и на сопоставимой работе стоили в три-четыре раза дороже. Что именно считалось сопоставимой работой и сколько было прогонов, в описании не уточняется.

Какая модель на какой роли

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

Уровни по умолчанию задаются константой MODEL_TIERS в начале блока скриптов мастера. На практике вся экономия держится на том, что исполнитель действительно работает на средней модели, а в Claude Code пин модели в frontmatter субагента может молча уступить модели сессии, и тогда разница видна только в счёте.

Два файла для одного оркестратора

Самое неочевидное в проекте - связь между классом модели и формой файла агента. Автор советует держать два варианта оркестратора: полный процедурный файл для модели поменьше и облегчённый для мощной. На одной и той же задаче в восьми конфигурациях облегчённый файл вдвое снизил стоимость мощной модели и прошёл проверку. Для всех моделей поменьше тот же облегчённый файл оказался дороже и не дал никакого выигрыша в качестве.

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

Claude Code, Codex или оба

Claude Code читает каталог .claude/, Codex - файл AGENTS.md в корне репозитория. Доктрина в обоих случаях одна, так что выбор касается упаковки, а флот остаётся тем же. Вариант «оба» выдаёт обе точки входа из одного источника, и в AGENTS.md прямо записано, что главными считаются файлы навыков. Логика автора: два описания одного флота расходятся, как только правят любое из них, и заранее назначить главное дешевле, чем потом их сверять.

Навыки - это доктрина каждой роли, которую агент подгружает по требованию, а не носит в контексте постоянно. Хуки на shell следят за границами задачи, не пускают push без проверки и ведут лог. По отдельной галочке добавляется ритуал для MOOTx01 из трёх команд: /prepare-for-compact, /start-clean и /recover-from-compact. Агент сам пишет передаточную записку до того, как кончится контекст, и следующая сессия её читает. Навыки передачи дел и фиксации плана входят в бандл в любом случае. Они написаны под «вашу систему памяти», поэтому работают с любым хранилищем, но лучше, когда за ними стоит настоящее.

Править мастер нужно прямо в HTML: роли лежат в константе ROLES, тексты навыков в CLI_SKILLS и OPTIONAL_CLI_SKILLS, хуки в OPTIONAL_HOOKS. Отдельного дерева исходников нет, константы и есть исходник, а web/SPEC.md описывает, что с чем должно совпадать при добавлении навыка или хука. Пошаговое руководство с тремя вариантами установки лежит в web/GUIDE.html, а полный пример бандла в sample_out/. Это снимок, а не свежий результат генерации, поэтому после изменений в мастере его приходится обновлять вручную. Каталог src/fleet_generator/ под будущий каркас на Python пока пуст.

16 августа из репозитория убрали Anvil - CLI на Swift, который разбирал, проверял линтером, правил и разворачивал уже готовые библиотеки .claude/. Общего кода с мастером у него не было, и четыре месяца его никто не трогал. Автор объясняет удаление тем, что второй, устаревший инструмент в том же репозитории выглядит частью мастера, хотя ею не является.