С последними апдейтами Claude Code и Codex CLI классические сабагенты потеряли смысл. Сессии научились общаться между собой напрямую.

В сообществе всё чаще отключают автоматический спавн и отказываются от тяжелых ролевых конфигов: на Hacker News разработчики делятся воркэраундами, закрывают права через deny: [Agent(Explore)] или запускают CLI с флагом --disallowedTools Task, возвращая управление в свои руки.

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

Ниже => разбор того, почему классические сабагенты стали оверхедом, и как устроен нативный пиринг живых сессий.

1. Сабагент это пустой контекст и перерасход токенов

Сабагент не является легким фоновым потоком текущей сессии. Архитектурно сабагент (включая кастомные именованные профили вроде code-reviewer) == холодный старт нового изолированного процесса.

Семь системных промптов, семь списков тулов, семь повторных вычиток репозитория. Назад -> короткий summary. Пока дети думают, родитель оплачивает ожидание.

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

С точки зрения процессов:

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

Настоящий пиринг устроен иначе: короткая реплика коллеге, который уже находится в контексте проекта, без перезапуска онбординга.

2. Codex CLI: спавн внутри треда и налог на ожидание

В OpenAI Codex CLI два открытых окна терминала изолированы: прямого межпроцессного сокета между ними нет. Сабагенты живут внутри одного корневого треда.

Команда /agent переключает дочерние треды внутри текущей сессии, а не между отдельными процессами.

Здесь возникают две статьи скрытых расходов:

Налог на опрос через wait_agent

По умолчанию таймаут wait_agent составляет 30 секунд. Если дочерний агент пишет код две минуты, родитель каждые 30 секунд просыпается и делает новый model turn по распухшему контексту.

Хотя архитектуры v1 и v2 поддерживают пробуждение по событиям, 30-секундный поллинг перезапускает модель и сжигает токены.

Налог на историю (FullHistory)

В MultiAgent V2 параметр fork_turns по умолчанию выставлен в all (режим FullHistory). Каждый потомок полностью копирует историю родителя. Глобального переключателя в конфиге нет => приходится задавать правила через developer_instructions.

В тестах ночного координатора на OpenAI Community сабагенты с гидратацией истории родителя сожгли в 2.6 раза больше квоты, чем чистые сессии. Дополнительно без явного вызова close_agent завершенный потомок продолжает занимать слоты max_threads.

3. Claude Code: потеря вывода и блокировки

В Claude Code сабагенты запускаются через инструмент Agent (ранее Task). С версии 2.1.198 они по умолчанию уходят в фон. Родитель получает только финальный summary. Лимиты: глубина до 3, параллельно до 20 воркеров.

Изоляция родительского контекста сохраняется, но токены перераспределяются по соседним процессам.

Основной риск здесь связан с доставкой данных.

Обрезка данных

При анализе поведения вывода: когда ответ сабагента упирается в лимит output-токенов, движок делит его на два сообщения ассистента, но родителю возвращается только последнее. Статус при этом отмечается как completed, без признаков обрезки.

В одном зафиксированном кейсе сабагент сгенерировал 151 652 символа (~75k токенов). Вызывающий процесс получил 24 353 символа => 127 215 символов (84% вывода) было потеряно.

Agent Teams и файловая синхронизация

В экспериментальных Agent Teams координация построена на JSON-файлах в ~/.claude/teams/{team}/inboxes/ и файловых блокировках:

• Ведущий агент выполнил 42 226 вызовов readMailbox, встретил 4 296 ошибок отсутствия файлов и блокировок.

• Через 2 часа 24 минуты ведущий процесс отключил команду и закончил задачу в одиночку за 18 минут.

Это классический пример из Теории ограничений (TOC): координация и handoff создали узкое горлышко, заблокировав всю работу.

4. Структура расхода токенов и кэш

Сравнение базовых множителей расхода:

По данным Anthropic, жесткое разделение ролей (планировщик / исполнитель / тестировщик / ревьюер) часто тратит больше ресурсов на координацию, чем на написание кода.

Три ключевых фактора удорожания:

1. Тяжелый префикс: каждый сабагент подгружает системный промпт и схемы тулов (~30k токенов).

2. Скрытая память: в замерах первый ход чекера на Haiku занял 20 993 токена, из которых 7 133 токена (34%) ушло на скрытую загрузку MEMORY.md.

3. Сброс кэша: в телеметрии на 95 сессиях и 1 777 сабагентах зафиксировано 96% сбросов кэша из-за того, что медиана простоя (~9 минут) превышает дефолтный TTL кэша в 5 минут.

5. Межсессионный пиринг

Альтернатива спавну сабагентов == прямое взаимодействие между прогретыми сессиями без промежуточных файлов и поллинга.

OpenAI Codex: чтение тредов и инъекция в поток

Вместо вызова spawn_agent используется фоновый демон codex app-server (JSON-RPC) и протоколы оркестрации тредов (см. архитектуру в репозитории OpenAI Codex и руководство OpenAI по Orchestrating Multi-Agent Systems with Handoffs):

Связь сессий через шину демона. Старый codex mcp-server устарел.

В интерфейсах ChatGPT и Codex Desktop эта механика выглядит как нативный межзадачный пиринг:

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

Примитивы:

• Чтение контекста: thread/read с параметром includeTurns (или list_threads / read_thread в Desktop).

• Отправка в поток: thread/queue/* и turn/steer (дописывание указаний в текущий шаг), либо CLI-команда: codex queue --thread <id> --message <текст>.

• Добавление данных без генерации: thread/inject_items вносит факты в историю без запуска платного model turn.

Claude Code: локальные сокеты и хуки

Инструменты ListAgents и SendMessage работают через локальный Unix-сокет или Named Pipe. Согласно документации Claude Code по межсессионному обмену и Agent Teams (а также исследованию Anthropic Building Effective Agents), этот механизм связывает не только сабагентов, но и независимые живые сессии (peers):

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

Особенности:

1. Безопасная доставка: SendMessage не прерывает запущенную команду (pytest), а встает в очередь (до 50 сообщений) до завершения текущего шага.

2. Бесплатное ожидание: параметр notify_when_idle будит вызывающий процесс по завершении работы партнера (без циклического опроса).

3. Инъекция через хуки (additionalContext): передача системного контекста без генерации токенов через событие UserPromptSubmit:

{
  "hookSpecificOutput": {
    "hookEventName": "UserPromptSubmit",
    "additionalContext": "Current branch: release-42. Deploy freeze until Friday."
  }
}

Изоляция воркспейсов через Git Worktree

Прямая передача сообщений исключает необходимость поддерживать файлы состояния (facts.md, state.json), из-за которых процессы нередко зависают часами в очередях на диске.

Git Worktree изолирует файлы, а нативная шина IPC передает сообщения.

Сессии запускаются в изолированных директориях или worktree:

• Окно 1: бенчмарки и профилирование.

• Окно 2: рефакторинг сервиса.

Сессии не создают файловых конфликтов и обмениваются короткими сообщениями вместо тяжелых дампов истории.

6. А когда сабагенты оправданы?

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

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

2. Независимое код-ревью: Проверка готового диффа агентом без предыстории обсуждения и промежуточных правок.

3. Широкий параллельный поиск: Одновременная проверка нескольких независимых гипотез в разных источниках, когда скорость ресерча важнее расхода токенов.

Кстати по 3 сценарию реализовано большинство дипресерчей, как пример в том же грок билде:

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

7. Практические сценарии работы

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

1. Руководитель + Исполнитель

• Как устроено: Первая сессия думает (держит верхнеуровневый контекст: собирает требования, проводит ресерч, декомпозирует задачу на шаги и контролирует прогресс). Вторая сессия работает чистым исполнителем — берет конкретный шаг, пишет код, гоняет тесты и рапортует о готовности. Так можно реализовать паттерны: Delegator/Dispatcher/Orchestrator/Planner.

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

2. Независимый критик на другой модели

• Как устроено: Код пишется в первой сессии (например, на Claude Sonnet), а готовый дифф отправляется на ревью во вторую сессию, запущенную на другой модели (например, GPT-4o/o3) или со специальным системным промптом строгого аудитора / security-ревьюера. Паттерны Reviewer/Adversarial/Critic.

• Профит: Устраняется когнитивная слепота генератора кода (модели сложно найти собственную логическую ошибку в том же контексте). Критик получает чистый дифф без предыстории правок и оценивает решение объективно.

3. Изоляция окружений: Git Worktree, субмодули и подпапки

• Как устроено: Сессии запускаются в параллельных рабочих директориях:

  • В независимых ветках через git worktree (одна сессия профилирует main, вторая вносит оптимизации в ветке фичи).

  • В изолированных git submodule или сервисных папках монорепозитория.

  • В изолированных сендбоксе или вообще просто подпапке.

• Профит: Исключаются конфликты блокировки файлов и нет необходимости бесконечно делать git stash / checkout. Сессии работают в своих файловых деревьях с независимыми кэшами сборки, обмениваясь только фактами через шину сообщений.

4. Кросс-проектная координация (Shared-библиотека + Бэкенд / Клиент)

• Как устроено: Сессии открыты в физически разных репозиториях (например, company/shared-proto или общие схемы типов и company/backend-api / мобильный клиент).

• Профит: Скоординированная разработка контрактов и интеграций без ручного переноса файлов. Первая сессия обновляет proto-схему или библиотеку, а вторая тут же синхронно подхватывает новые сигнатуры в коде бэкенда или фронтенда.

Ну и какой итог?

Основная задача управления разработкой => снижать неопределенность и удерживать процесс в предсказуемом состоянии.

Автоматический спавн сабагентов увеличивает число точек отказа, раздувает handoff и приводит к неконтролируемому расходу квоты. Межсессионный пиринг решает проблему изоляции и параллелизма без холодного старта и финансового оверхеда.

Практичный подход:

1. Одиночная сессия для 80% повседневных задач (багфикс, локальные фичи, тесты).

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

3. Точечный изолированный сабагент с лимитом шагов только как «мусорка для контекста» при разборе гигантских сырых дампов данных.