Dynamic Workflows: 4 задачи, где он жрёт токены впустую

Anthropic выкатил Dynamic Workflows 28 мая. За неделю я прогнал на 12 проектах: 4 из них - выжженный токен-бюджет без результата. Разбираю где не запускать.

Я начал с простого: «попробую новую фичу на всём подряд, посмотрю где попадёт». Через шесть дней посчитал расход - 30% дневного лимита Max ушло на четыре прогона, которые я мог сделать одним обычным промптом за полторы минуты.

Dynamic Workflows отлично работают на правильных задачах: из моих двенадцати прогонов на двух фича сэкономила часа три-четыре чистой работы. Только эти задачи занимают 15% обычного рабочего дня, а остальные 85% - нет.

Ниже разбираю где Dynamic Workflows реально окупаются, какие четыре типа задач я после недели прогонов вычеркнул из списка кандидатов, и как за минуту понять что не стоит дёргать оркестратор на конкретный запрос.

Если ты не успел поиграться с фичей - короткий контекст.

Раньше Claude Code работал линейно: один чат, один план, одно контекстное окно. Можно было спавнить субагентов через Task, но решение «что запустить дальше» оставалось за моделью в основном диалоге. Каждый промежуточный результат проедал тот же контекст.

Dynamic Workflows переводят план в исполняемый код. Claude формулирует задачу как JavaScript-скрипт-оркестратор, runtime крутит его в изолированном окружении, до 16 субагентов работают одновременно (максимум 1000 на весь прогон), их выводы лежат в переменных скрипта, а не в твоём окне. Параллельные агенты перепроверяют друг друга, и наружу выходит только то, что пережило перекрёстную проверку.

Включается тремя способами:

Требует свежей версии Claude Code и доступа на Pro, Max, Team или Enterprise. Первый запуск блокируется явным подтверждением - чтобы случайно не отдать модели карт-бланш на сто параллельных сессий.

Документация Anthropic честно предупреждает: «tokens are consumed significantly more than usual». В переводе: «токенов сожжётся существенно больше, чем при обычной работе». Это базовая физика - 16 параллельных контекстных окон вместо одного.

За две недели я нащупал два типа задач где фича оправдывает каждый сожжённый токен. Сначала артефакт - копируй и применяй сразу на следующей задаче. Пятиминутный фильтр перед тем как набрать workflow в промпте:

Это критерии откуда они взялись.

Кейс 1: миграция 80+ файлов с одной структуры на другую. Старый API превратился в новый, нужно заменить вызовы во всём проекте плюс адаптировать форматы данных. Шестнадцать субагентов разбирают по 5-6 файлов каждый, у каждого свой контекст без шума от соседей, отдельный валидатор-агент пересматривает изменения по контракту. Раньше я делал это за день в три-четыре сессии Claude, постоянно теряя контекст. Workflow закрыл миграцию за час с небольшим. Расход токенов - около 8 моих обычных прогонов. Время по часам - 1/6 от прежнего, а ошибок в финальном коде я нашёл меньше.

Кейс 2: deep-research по новому инструменту. Встроенная команда /deep-research веерно открывает 20-40 источников: документация, обсуждения, чужие гайды, репозитории с примерами. Один агент сверяет факты между источниками, другой выписывает противоречия, третий собирает финальную сводку. Раньше я открывал двадцать вкладок руками и проводил два-три часа в режиме «прочитал, забыл, вернулся». Workflow выдаёт мне готовое резюме с ссылками за 25-30 минут. Кстати, по теме параллельных запусков у меня есть отдельный материал - как запустить несколько Claude Code параллельно. Там разбираю три варианта - worktree, subagents и Dynamic Workflows - когда какой брать.

Общая закономерность по обоим кейсам: workflow окупается, когда я заранее знаю, что задача займёт у меня больше часа в обычном режиме, и могу разбить её на независимые куски. Условный порог окупаемости - 60 минут моего времени или 50 файлов в проекте. Меньше - не нужен оркестратор.

Эти два кейса - 15% моих задач за неделю. Остальные 85% - четыре типа, на которых workflow либо не давал выигрыша, либо проигрывал обычному промпту.

Самая частая моя ошибка первых дней. Открываю проект, вижу баг в одной функции, набираю в промпте «workflow, почини отвалившуюся валидацию формы».

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

Расход токенов на одном таком прогоне у меня вышел в 4 раза больше обычного. Времени сэкономлено - ноль, потому что я всё равно сижу и смотрю на индикатор прогресса.

Правило для себя: если задача укладывается в один файл и в одну функцию, я больше не пишу workflow. Один subagent или просто Task в обычном чате решают это в десять раз дешевле.

Знаешь паттерн: видишь стектрейс, понимаешь о чём он, идёшь чинить руками или коротким промптом. Я попробовал отдать такие баги Dynamic Workflows - получил тот же эффект, что и в первом кейсе, только хуже.

Оркестратор пытается разложить задачу на гипотезы. Спавнит агента который проверяет код, агента который ищет похожие исправления в истории git, агента который читает логи. Каждый из них прорабатывает свою гипотезу, потом они согласовывают финальное решение между собой. По дороге они часто заходят на пути, которые я и так знаю что не приведут к багу.

На баге, который я диагностировал за 2 минуты глазами, workflow потратил 18 минут и сжёг токенов как 6 обычных промптов. Финальная правка совпала с тем, что я сам бы написал.

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

Я попробовал отдать Dynamic Workflows подготовку лонгрид-материала: «собери три референса в этой нише, проверь факты, напиши черновик». Звучит как идеальная задача для оркестрации - параллельные поиски, перекрёстная проверка, агрегация в один документ.

На деле получилось плохо. Тексты - это не код. Критерия «правильно или нет» нет, любой агент-валидатор подтверждает любой черновик, потому что разногласия между агентами выражаются в стилистических нюансах, а не в фактах. Они согласовывают между собой текст, который мне всё равно нужно переписать вручную с нуля - тон не мой, абзацы дрейфуют, нет интонации.

То же самое было на задаче «придумай 10 заголовков для статьи». Workflow спавнит трёх агентов с разными подходами, потом четвёртый агент выбирает «лучшие». Я получаю 10 заголовков, из которых ни один не цепляет так, как первый же черновик от обычного промпта где я даю Claude свой голос примером.

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

Это контр-интуитивный пункт. По интуиции маленький проект = быстрый workflow. По факту получается наоборот.

Маленький проект Claude и так держит целиком в контекстном окне. У него весь код перед глазами, он видит связи, понимает где что лежит. Когда я запускаю workflow на таком проекте, каждый из 16 агентов открывает СВОЁ окно и читает СВОЙ кусок без общего обзора. Результат - они пересекаются, делают одно и то же дважды, иногда конфликтуют по решениям.

На проекте в 1200 строк (Next.js-сайт со страницей, формой и API-роутом) я попросил workflow «найди дубли логики и предложи рефакторинг». Получил отчёт где трое агентов нашли одну и ту же дублированную функцию, описали её разными словами и предложили три разных решения. Никто из них не видел весь файл целиком, и каждый решал задачу под свой кусок.

Обычный промпт с Plan Mode на этом же проекте дал мне один связный план рефакторинга за две минуты. Workflow дал три несогласованных за двадцать.

Условный порог по моему опыту: 50 файлов или 5000 строк кода. Меньше - workflow проиграет обычному промпту. Больше - начинает выигрывать.

Вот честная физика, которую я почувствовал руками после первой недели.

Параллельность даёт выигрыш только когда задача делится на независимые куски. Если шаг 2 зависит от результата шага 1 - параллельность не работает, агенты будут ждать друг друга или решать с неполной информацией. На сложных кодовых миграциях независимых кусков много (каждый файл сам по себе), на дебаге знакомого бага - кусок один (правка в одной точке).

Перекрёстная проверка между агентами работает только когда есть объективный критерий правильности. Тест прошёл/не прошёл, файл компилируется/нет, факт совпадает с источником/нет. На тексте критерия нет, на маленьком проекте Claude и так всё видит без перекрёстной проверки.

Каждый параллельный агент - отдельное контекстное окно. Стоимость токенов растёт линейно с числом агентов. На большой задаче эта стоимость окупается выигрышем по времени и качеству. На маленькой - это просто сжигание лимита.

Чувствуется как будто получаешь в руки 16-цилиндровый двигатель и пытаешься завести его, чтобы съездить за хлебом в магазин через дорогу. Двигатель работает идеально, но затраты идут не в дело.

Считал руками после недели прогонов. Один workflow-прогон на «лёгкой» задаче (точечная правка, маленький проект) стоил у меня в 3-6 раз больше токенов, чем обычный промпт на ту же задачу.

Я держу Max-подписку. Дневной лимит ощущается живым: один workflow на ненужной задаче забирает примерно столько же, сколько 4-5 нормальных рабочих сессий. Если запустил три таких прогона за день - вечером можешь упереться в лимит на реально важной задаче.

Я завёл себе простой рефлекс: перед workflow пробежаться глазами по 5 вопросам выше. Это занимает 15 секунд. Сэкономило мне за неделю примерно треть дневного лимита, который я раньше сжигал на бесполезных оркестрациях.

Если ты сидишь на Pro а не на Max - подумай вдвойне. На Pro дневной запас меньше, одна ошибка с запуском workflow на «лёгкой» задаче может отгрузить тебя в режим ожидания до завтра. По работе с лимитами я отдельно собирал 8 правил экономии токенов в Claude Code - там я разбираю где обычно течёт лимит и как закрыть утечки.

И ещё один незаметный пункт. Workflow не получает твоё подтверждение в середине прогона. Если он стартанул на ложной гипотезе или ошибся в плане - увидишь это только когда получишь финальный отчёт через 15-25 минут. Обычный промпт с Plan Mode даёт возможность сказать «стоп, не туда» через 30 секунд. На простых задачах эта стоимость прерывания тоже играет против workflow.

У меня был кейс на третий день, когда workflow на исследовательской задаче ушёл в сторону. Я попросил собрать сравнение пяти инструментов для одной задачи. Скрипт-оркестратор решил, что один из них точно лучше остальных, и спавнил агентов перепроверять эту гипотезу с разных углов. Через 20 минут вернул мне обстоятельный отчёт о том, что выбранный инструмент действительно лучший. Только моя задача была противоположная - я хотел увидеть, в каких ситуациях каждый из пяти выигрывает. Я узнал о промахе только когда читал финальный отчёт. В обычной сессии я бы поправил направление после первого же абзаца.

Если ты на Max и активно работаешь с Claude Code каждый день, попробуй фичу - это не страшно, первый запуск Anthropic блокирует подтверждением. Возьми задачу из реальной работы, на которой ты раньше тратил 1-3 часа из-за объёма (миграция, рефакторинг по всему проекту, исследование чужого кода). На таких workflow реально окупается.

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

Что бы я сделал в любом случае:

Главное что я понял за две недели: Dynamic Workflows - это инструмент для задач определённого класса, не универсальный апгрейд Claude Code. Удобство «запустил и забыл на 25 минут» работает ровно до момента, когда вечером смотришь на дневной расход и считаешь сколько прогонов из них реально были оправданы. У меня по итогам недели вышло двое из двенадцати. Остальные десять - выжженный токен-бюджет, на котором я в обычном режиме закрыл бы те же задачи быстрее.

А ты на каких задачах в Claude Code запускаешь workflow и где обычный промпт справляется быстрее? Особенно интересен опыт тех, кто на Pro - там цена ошибки выше.