Devin Fusion против Cursor AI: экономит ли связка планировщик + подмастерье 46% на кодинге

Смотрю на новые агентные архитектуры с профессиональной паранойей: последние полгода то субагентов в Claude Code и Codex объявляют мёртвыми, то сессии учатся писать друг другу напрямую, то теперь Cognition выкатывает Devin Fusion - пару моделей вместо одной на весь прогон. У меня самого парк агентов на сервере уже год как раздаёт задачи по ролям, так что смотрю на анонс не как на новость, а как на внешний бенчмарк своим цифрам. Если ты гоняешь Cursor AI или Claude Code одним агентом на все задачи, разбираемся, что там реально нового и стоит ли тащить это в свой пайплайн.

Что такое Devin Fusion и зачем Cognition сажает рядом два агента?

Devin Fusion - архитектура агента Cognition, где одновременно работают две модели с разными ролями: дорогая frontier-модель держит план и принимает решения, а дешёвая модель-подмастерье выполняет рутинные шаги. Модели не сменяют друг друга по очереди - они работают параллельно, каждая со своим постоянным контекстом, и общаются напрямую по ходу задачи.

На выбор для роли планировщика или подмастерья Cognition даёт пять моделей: Fable 5, Opus 5, GPT-5.6, Kimi K3 и Grok 4.5 (по данным cognition.com, 29 июня 2026). У самой компании формулировка жёсткая: "основной агент должен делать минимум действий и читать только то, что абсолютно необходимо - по умолчанию он делегирует и присматривает, принимая значимые решения". То есть дорогая модель не трогает файлы руками - её работа - решать, что делать, а не делать самой. Схему в блоге называют Sidekick: подмастерье выполняет делегированное, пока лид-модель держит в голове план и не тратит токены на чтение того, что и так прочитает исполнитель.

Сколько реально экономит связка планировщик + подмастерье?

Цифры экономии у Cognition плавают в зависимости от бенчмарка и заявления: 39% дешевле по кодинг-бенчмаркам в анонсе в X, до 60% при сохранении уровня frontier-модели в блоге, и отдельно 41% конкретно с моделью Fable 5. Заголовок в 46%, который разошёлся по новостным агрегаторам вроде AlphaSignal (сентябрь 2026), - это цифра из ещё одного отдельного замера, где Fusion сравнивали по паритету качества с одиночной Fable 5.1, а не универсальный множитель на все случаи.

Конкретика есть на бенчмарке FrontierCode: Fusion набрал 63,1 балла и обошёлся в 1,35 доллара за прогон - против 64,9 балла и 10,53 доллара у одной Fable 5 без Fusion (cognition.com/blog/devin-fusion). Разница в качестве - 1,8 балла, разница в цене - почти в 8 раз. Отдельно Cognition говорит, что 88% объединённых PR на внутреннем тестировании Fusion закрыл полностью автоматически, без ручной доводки человеком. К 11 сентября 2026 архитектуру раскатали дальше - на Devin Desktop и в CLI, то есть это уже не экспериментальная фича под капотом, а рабочий режим по умолчанию для новых прогонов.

Чем Fusion отличается от моего ручного роутинга Haiku, Sonnet и Opus?

Fusion делает то же самое, что я делаю руками в своём парке агентов: дорогая модель думает, дешёвая пашет. Разница - в масштабе автоматизации и в том, что модели работают одновременно, а не последовательно друг за другом.

Когда я в статье про оркестратора и исполнителей раздавал задачи по ролям - Haiku ищет файлы и читает, Sonnet вносит правки по чёткой инструкции, Opus принимает архитектурные решения и делает финальную проверку, - экономия по моим прикидкам вышла около 40%, а у автора фреймворка pilotfish, на которого я там ссылался, - почти 70%. После этой перестройки недельный лимит Claude Code стал уходить у меня примерно в 4 раза медленнее. Цифры Fusion (39-60%) укладываются в тот же диапазон - Cognition не открыла новый закон экономики агентов, а просто зашила его в продукт по умолчанию, без ручной настройки каждого шага.

Ключевая разница в другом: у меня роутинг статический и решается на этапе написания промпта (эта задача - для Haiku, эта - для Opus), а у Fusion лид-модель по ходу прогона сама решает, что делегировать подмастерью прямо сейчас, и может перехватить управление, если результат не устроил. Это гибче, но и менее предсказуемо по цене - отсюда и разброс в заявленных 39-60% в зависимости от задачи.

Fusion - это возрождение субагентов или что-то другое?

Нет. Субагенты в Claude Code и Codex - это иерархия "родитель делегирует, потомок отчитывается сжатым summary", и я писал в заметке про смерть субагентов, что такая схема сжирает до 15 раз больше токенов на холодном старте (префикс около 30 тысяч токенов на каждый вызов) и режет до 84% полезного вывода при сжатии в summary. Fusion устроен иначе: два равноправных процесса с отдельными постоянными контекстами работают бок о бок, а не сериями запрос-ответ с обрезкой результата.

Это ближе к тому, о чём я писал в заметке про cross-session messaging между агентами Claude Code: сессии с версии 2.1.224 (август 2026) умеют слать друг другу текстовые сообщения через ListAgents и SendMessage вместо того, чтобы я руками копипастил находки между параллельными терминалами. Там очередь - 50 сообщений на сессию, до 100 отложенных. Fusion делает нечто похожее по духу, но не текстовыми сообщениями, а через общий рабочий цикл: планировщик видит, что делает подмастерье, и вмешивается без ручного вызова.

Стоит ли переносить архитектуру Fusion в headless-пайплайн на cron?

Для моего пайплайна - нет, и вот почему. Весь blog-pipeline работает не долгой сессией с параллельными агентами внутри, а короткоживущими cron-процессами, которые по очереди дёргают claude -p на каждую стадию и передают эстафету через SQLite, а не через общий контекст.

Вот что реально запускает генерацию черновика (cron/run-generate.sh):

claude -p "/blog-draft $TOPIC_ID" --permission-mode acceptEdits >"$OUT" 2>&1

А дальше, если черновик собрался, тот же скрипт синхронно зовёт проверку:

bash "cron/run-check.sh" "$did" --no-sync

которая внутри опять поднимает отдельный холодный процесс - claude -p "/blog-check $DID" --permission-mode acceptEdits - без какой-либо общей памяти с генерацией: всё, что нужно проверке, она читает из БД и файла черновика заново. Грепом по всем cron-скриптам и python-обвязке на opus/sonnet/haiku - пусто. Ни одна стадия не выбирает модель по цене, весь конвейер работает на модели по умолчанию для процесса claude -p, и никакого Fusion-style роутинга внутри стадии нет вообще.

Fusion в этой картине решает проблему, которой у меня нет - параллельный расход токенов внутри одной долгой сессии на одну задачу. У меня стадии и так разнесены по разным процессам с холодным стартом, и это осознанная плата: черновик можно запарковать в waiting_facts, вернуть тему в candidate при падении (bpdb topic-release) или перезапустить проверку отдельно от генерации - то есть терять контекст между стадиями мне выгоднее, чем держать одну долгую сессию, которая упадёт целиком.

Ещё один нюанс из той же обвязки: генерация не стартует по расписанию день в день секунда в секунду, а сначала спит случайные 0-40 минут (jitter 40 в cron/run-generate.sh) - это не про экономию, а про то, чтобы ровный ритм запусков не был отпечатком конвейера. Fusion такой проблемой вообще не заморачивается - у неё другая история, продуктовая, не про то, чтобы не спалиться перед поисковиком.

Какие риски и ограничения у двухмодельной архитектуры?

Разброс цифр в анонсах - маркетинговый, а не технический: 39%, 41%, 46% и "до 60%" - это разные замеры на разных бенчмарках и парах моделей, а не гарантия для твоей задачи. Единственная цифра с прозрачной методикой - FrontierCode (63,1 балла за 1,35 доллара против 64,9 за 10,53 у одиночной Fable 5) - и даже там просадка качества в 1,8 балла есть, просто не вынесена в заголовок пресс-релиза.

С привязкой к рантайму тоже не всё гладко. Пара планировщик + подмастерье с параллельным запуском и общим циклом - это фича конкретного продукта Cognition (Devin CLI и Desktop), а не переключатель, который можно включить в Claude Code или Codex CLI на своей стороне. Взять готовую архитектуру нельзя - можно взять только идею и допилить её руками, как я в своё время допиливал роутинг по Haiku/Sonnet/Opus.

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

Так когда стоит копировать Fusion, а когда нет?

Граница простая. Если твой инструмент - монолитный чат-агент без ручного контроля модели (условно, голый Cursor AI на одной модели на все правки без потоков), двухмодельная схема даст реальный выигрыш - бери готовое там, где инструмент это уже поддерживает. Если у тебя headless-пайплайн с явным разделением по стадиям через БД, как у меня, - из Fusion стоит забрать только одну идею: подмастерье получает узкую, дословную инструкцию, а не общую задачу. Это чинит главный риск дешёвых моделей - размытые формулировки, из-за которых Haiku и подобные заваливают задачу не потому, что слабые, а потому что не поняли, что от них хотели. Сам параллелизм с общим постоянным контекстом тут не нужен - у меня стадии изолированы намеренно, и это работает не хуже.

Короче, Fusion - не революция, а витрина того, что часть из нас уже собирала руками из cron-обёрток и промптов. Приятно, когда индустрия подтверждает твои цифры сторонним бенчмарком, а не только пруфом в виде "лимит стал уходить в 4 раза медленнее".