Смерть сабагентов в Claude и Codex

Для параллельной работы больше не обязательно каждый раз поднимать команду сабагентов. Уже открытые сессии принимают задания, отдают результаты и передают друг другу нужный контекст.

В Claude Code это межсессионные сообщения. В Codex CLI с 0.149.0 появилась codex queue, в Desktop есть отдельные инструменты для соседних задач. Через app-server данные можно класть прямо в историю треда.

Если один чат уже разобрался в бэкенде, а второй пилит клиент, их можно связать. Повторно объяснять проект новому исполнителю на каждое уточнение необязательно.

1. Что такое сабагент и за что мы платим

Сабагент — это исполнитель с отдельным контекстным окном. Основной агент дает кусок работы, нужные данные и забирает результат.

Полезная штука: главный чат чинит баг, сабагент читает логи, в основной контекст возвращается вывод, не вся простыня. Изоляция работает.

Платим за другое: каждый ребенок читает репозиторий заново, а пока он работает — родитель ждет. Поручение надо сформулировать, дать исполнителю контекст, проверить результат и использовать его в основной работе. Если задача маленькая, эти действия могут обойтись дороже, чем само исправление.

Масштаб виден в публикациях Anthropic:

Это разные базы. И весь множитель нельзя записывать в бесполезную координацию: несколько агентов могут пройти больше веток и выдать более качественный результат.

В том же разборе система с Opus 4 во главе и Sonnet 4 в детях обошла одиночный Opus 4 на 90,2% на внутреннем research eval. Anthropic отдельно пишет: в программировании меньше действительно независимых задач, чем в широком поиске. Этот результат на багфикс не переносится.

2. Как устроен spawn в Codex

Основной чат поднимает ребенка через spawn_agent, шлет уточнения и ждет результат. Все крутится вокруг родителя, spawn никуда не делся.

Налог сидит в двух местах. Если нужен один файл, а ребенок получает длинное обсуждение всего проекта, вход несоразмерен поручению. Если родитель многократно вызывает короткое ожидание и после каждого возврата снова идет в модель, он жжет токены на промежуточные проверки. Важен фактический цикл координатора: дефолтный таймаут ожидания сам по себе еще не доказывает, что модель неизбежно просыпается каждые 30 секунд.

Сабагенты Codex и раньше умели наследовать контекст: в интерфейсе V1 для этого был fork_context. Не любой старый ребенок стартовал с пустой историей. Сопоставление механизмов V1 и V2.

3. Где ломается Claude Code

Обычный сабагент Claude Code получает отдельное задание, инструкции и инструменты. Основной чат забирает результат. Профили вроде Explore или code-reviewer специализируют исполнителя.

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

В HTTP-замере для Claude Code 2.1.234 небольшой проверяющий сабагент на Haiku получил 20 993 входных токена на первом ходе. Из них 7 133, или 34%, составляла автоматически добавленная память MEMORY.md. Для короткой проверки это счет еще до полезной работы.

В другой телеметрии на 95 сессиях и 1 777 сабагентах автор нашел около 30 тысяч токенов статического контекста на старте: инструкции, схемы инструментов, правила проекта и окружение.

Там же разобраны потери кэша при ожидании вложенного агента: медианный простой около девяти минут при TTL пять минут. Число 96% относится к подтвержденным потерям кэша в рассмотренной группе таких эпизодов, а не ко всем запускам. Между часто запускаемыми однотипными агентами переиспользование кэша, наоборот, работало.

Есть и потери при возврате. В issue #81838 длинный ответ резался на сообщения, а вызывающей стороне отдавали только последнее. Из 151 652 символов она получила 24 353, около 16%. Примерно 84% текста не дошло.

Отдельный случай: экспериментальные Agent Teams. В отчете для версии 2.1.39:

• 42 226 вызовов readMailbox

• 4 296 ответов file not found

• 23 запуска участников, из них продуктивных восемь

• примерно 2 часа 24 минуты с командой, после чего ведущий добил оставшуюся работу один за 18 минут

Это баг-репорты конкретных конфигураций и версий, не закон продукта. Эти случаи объясняют, почему стоит ограничивать лишнюю координацию. Сами по себе они не показывают, насколько обмен между постоянными сессиями дешевле.

4. Что изменилось: MultiAgent V2 и форки

В Codex MultiAgent V2 можно выбрать, сколько истории отдать новому исполнителю:

В описанном интерфейсе V2 дефолт "all". Полный форк наследует тип агента, модель и reasoning effort родителя. Это удобно, когда ему правда нужны уже принятые решения. Для маленького поручения полная история может оказаться лишней. Разбор поведения V2.

В Claude Code есть форк текущей беседы. Он наследует историю, системный промпт и инструменты, а первый запрос может использовать кэш родителя. Новому исполнителю уже не обязательно заново объяснять проект. Документация форков Claude Code.

Форк тоже создает нового исполнителя. Если нужная рабочая сессия уже жива, пиши ей.

5. Как теперь общаются чаты

Три разные операции: прочитать соседний разговор, отправить ему сообщение, положить готовые данные в его историю.

Codex: сообщения существующим сессиям

В Codex CLI 0.149.0 появилась codex queue: сообщение уходит в уже существующую локальную или удаленную сессию. Рядом codex agents для поиска, запуска и управления задачами. Это функции самого CLI. Официальный changelog.

В Desktop для работы с соседними задачами используются отдельные инструменты: list_threads, read_thread и send_message_to_thread. Они позволяют найти соседнюю задачу, прочитать ее историю и передать сообщение. Операции видны в отчете о регрессии Desktop; доступность зависит от среды и версии приложения.

Сессия слева находит соседний тред (Listed chats), отправляет инструкцию (Sent message to chat) и забирает результат (Read chat). Справа служебная плашка Sent by ChatGPT from another task.

Сценарий такой:

Найди чат, где мы согласовали авторизацию. Прочитай принятые решения, передай их в задачу реализации и попроси проверить обработку истечения токена.

Контекст берется из уже сделанной работы. Поднимать сабагента, чтобы он заново исследовал тот же вопрос, незачем.

Codex: прямое добавление в контекст

На уровне codex app-server это программный контроль над историей и текущим ходом:

Сессии ходят через демон, не друг в друга напрямую. inject кладет данные в историю без нового хода.

Через thread/inject_items можно положить результат вычисления или уже добытые данные прямо в историю, которую увидит модель. Элементы сохраняются и входят в следующие запросы. Справочник app-server.

Это не то же самое, что обычное сообщение. Добавление без немедленной генерации не делает последующую обработку бесплатной.

Claude Code: сообщения между живыми сессиями

ListAgents и SendMessage находят другую сессию и пишут ей. На одной машине доставка идет через локальный сокет или Named Pipe.

Если принимающая сессия занята, сообщение ждет паузы между вызовами тулов. Если простаивает, стартует новый ход.

Например:

Сообщи сессии клиента: поле expires_at теперь обязательное, контракт обновлен. Попроси проверить десериализацию.

Как это выглядит целиком. Сессия бэкенда отправляет этот текст. Сессия клиента в этот момент гоняет pytest: сообщение не прерывает тест и ждет паузы между вызовами инструментов. После шага клиент читает факт про expires_at, правит десериализацию, снова гоняет тесты и отвечает: обработка истечения на месте. Если сессия простаивает, сообщение стартует новый ход.

Уходит только текст. История и файлы отправителя сами не копируются: нужное решение, кусок контекста или путь к артефакту надо вложить в сообщение, иначе получатель его не увидит.

Для ожидания есть notify_when_idle. Основная сессия может запросить однократное уведомление, когда другая локальная сессия перейдет в idle или завершится. Циклический опрос не нужен. Сабагент или участник Agent Teams такую подписку оформить не может. Idle здесь значит конец хода с пустой очередью, а не то, что задание обязательно выполнено. Документация межсессионного обмена.

6. Что это дает в работе

Для обмена используются codex queue или SendMessage; при параллельных правках одного репозитория можно развести сессии по worktree. Это изолирует файлы на уровне рабочей копии Git, а связь между сессиями идет прямыми сообщениями, без поллинга общего файла состояния.

Четыре рабочих сценария.

Worktree дает отдельную рабочую копию, но при объединении изменений возможны конфликты. Сообщение о новой версии библиотеки ее не устанавливает: принимающая сессия должна обновить зависимость и прогнать интеграцию.

Главная экономия там, где нужная сессия уже разобралась в своей части проекта. Ей хватает короткого уточнения. Нового исполнителя и повторный сбор контекста можно не затевать.

Если вторую сессию все равно создаешь с нуля, считай и стоимость ее подготовки. Иначе это тот же онбординг, только в соседнем окне.

7. Когда достаточно чатов, а когда нужен сабагент

Для багфикса, локальной фичи или последовательного рефакторинга я бы оставлял один рабочий чат. Для независимой длительной задачи я бы добавлял второй чат и связывал их сообщениями.

Так остаются понятные точки управления: видно, какая сессия чем занята, можно прочитать историю, уточнить задание и вернуться позже. Отдельный оркестратор на этот набор задач не нужен.

Сабагенты остаются полезны в трех случаях:

• Изоляция тяжелого вывода. Прочитать большие логи или документацию и вернуть компактный результат.

• Разовая независимая проверка. Проверить дифф без предыстории обсуждения.

• Широкий параллельный поиск. Несколько независимых направлений, когда доп. расход оправдан полнотой или сроком.

Мой дефолт: одна сессия, потом несколько устойчивых рабочих чатов по мере необходимости. Сабагент появляется под конкретную подзадачу, не как штат.

Именно поэтому на практике я сам перехожу на workflow-herdr — из-за возможности как раз наглядной работы через закрепленные долгоживущие сессии, общающиеся между собой.

Мультиплексирование сессий в workflow-herdr: сплиты терминалов, закрепленные долгоживущие сессии под разные задачи и модели (Codex, Grok), очереди и контроль шагов без потери контекста.

Вместо роя невидимых одноразовых сабагентов, которые сжигают кэш и требуют заново скармливать им контекст проекта, перед глазами единое прозрачное рабочее пространство. Каждый агент закреплен за своей сессией, держит локальную историю и общается с соседями через сообщения и очереди ожидания (herdr agent wait), а вы в любой момент видите реальное состояние системы.

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