Как сделать Fable дешевле, чем Opus: перенастройка структуры затрат агента с помощью делегирования

Fable — это менеджер с опытом старшего инженера: рано сдаёт задачи, чётко прописывает спецификации и делает меньше работы своими руками; Opus — это микроменеджер, который опекает стажёра. В этой статье, основанной на материале Joon Lee X, разбором через 3 000 прогоночных тестов вскрывается структура затрат, стоящая за этим.
(Краткое резюме: Anthropic запустила «Claude for Small Business»: ставка на автоматизацию ИИ для малого и среднего бизнеса — чтобы вы быстрее выставляли счета, считали зарплаты.. )
(Дополнение по контексту: Anthropic требует верификацию KYC по реальным именам! Часть функций Claude потребует загрузки удостоверений личности — из‑за этого растёт регуляторная нагрузка)

Оглавление

Toggle

• Введение
• Экспериментальная настройка
• Стоимость одного agent
• Микроменеджер со стажёром vs менеджер с опытным инженером
• После передачи
• Когда делегирование не помогает
• Заключение

Мы заменили Opus 4.8 на Fable 5, а счёт Devin при этом, наоборот, снизился.

Стоимость Fable 5 на токен в 2 раза выше, чем у Opus 4.8. Но когда мы прогнали оба этих модели одновременно на FrontierCode 1.1 в новом Fusion‑подходе, Fable при этом вышел дешевле. И, что неудивительно, его результаты тоже оказались лучше. В статье объясняется почему, а также что это означает для «ценообразования на агентные работы».

Введение

Каждый, кто запускал программный agent, знает: более сильная модель даёт лучшие результаты, но за это приходится платить.

Когда мы запускали Devin Fusion, мы показали путь: поставить дорогую «передовую» модель во главе, заставить её делегировать работу более дешёвому и быстрому помощнику — и тем самым получить результат уровня frontier по цене на 35% ниже.

Но если ведущая модель делегирует большую часть работы, будет ли её цена за токен всё ещё доминировать над всем счётом? Стоимость Fable 5 на токен в 2 раза выше, чем у Opus 4.8, так что agent, где в роли ведущей выступает Fable, по идее должен стоить дороже. Чтобы найти ответ, мы прогнали на FrontierCode 1.1 3 000 прогонов‑тестов для этапов работы, охватив четыре конфигурации: Fable и Opus по очереди в роли ведущего, плюс каждый вариант выполнялся как «с» так и «без» одного и того же дешёвого помощника.

Показатели «чистого выполнения» (pure runs) полностью совпали с интуицией: у Fable результат лучше, чем у Opus (60,8 против 55,4), и при этом дороже по стоимости. Лучшее — больше счёт.

Интересным всё становится только там, где есть помощник.

При фиксированном помощнике порядок снова меняется: Fable + помощник выходит дешевле, чем Opus + помощник ($1,86 против $2,04), но при этом результат выше (60,7 против 54,6). По сравнению с чистым Fable, Fable + помощник режет стоимость на 54%, а результат почти не меняется.

| Конфигурация | | --- | Результат | Средняя стоимость одного прогона | | --- | --- | | Fable 5(low)+ помощник | 60,7 | $1,86 | | Opus 4.8(medium)+ помощник | 54,6 | $2,04 | | Fable 5(low) | 60,8 | $4,03 | | Opus 4.8(medium) | 55,4 | $3,06 |

Итог доказывает: «цена на токен в 2 раза выше» — это цифра, которую легко неверно считать. Стоимость одного agent в основном зависит от того, сколько раундов проходит ведущая модель, сколько контекста она тянет вместе с собой и, самое важное, — какие вещи она решает «не делать» сама. Разница сводится к стилю управления: Opus ведёт себя как микроменеджер со стажёром; Fable — как менеджер с сильным инженером.

Экспериментальная настройка

Быстро напомним, как работает структура помощника в Fusion. Ведущий agent имеет весь рабочий этап: он общается с пользователем, планирует, проверяет выполненное и отправляет результат (commit). Также у ведущей модели есть постоянно присутствующий sub‑agent помощника, который делегирует задачи. Ведущая модель пишет простым языком сводку передачи, а суб‑agent, управляемый значительно более дешёвой моделью, в своём собственном контексте выполняет задачу и возвращает результат. Затем ведущая модель проверяет итог и решает, что делать дальше.

Чтобы понять, куда уходят деньги, мы сделали две вещи. Во‑первых, мы разобрали все 3 000 этапов: каждую LLM‑вызовку — какая модель говорит, какие инструменты вызывает, сколько токенов читает/пишет и сколько стоит каждый вызов. Во‑вторых, мы взяли 40 задач и посмотрели «вблизи»: те, где Fable явно дешевле, те, где Opus явно дешевле, а также ещё одну группу случайных примеров из «середины». Для каждой пары мы сравнили бок‑о‑бок исполнения с ведущим Fable и с ведущим Opus, проверили траектории и увидели, куда именно уходят расходы.

Стоимость одного agent

Ниже показано, как в нашем эксперименте стоимость распределялась между ведущей моделью и помощником:

| | | --- | Ведущий $ | Помощник $ | Итого за один прогон $ | Раундов у ведущего | Входные токены (суммарно) | | --- | --- | --- | --- | --- | | Fable + помощник | $1,28 | $0,58 | $1,86 | 11,5 | 545 тыс. tok | | Opus + помощник | $1,73 | $0,31 | $2,04 | 26,5 | 1 679 тыс. tok |

Fable тратит на помощника больше, чем Opus — на $0,27 больше за один прогон. Но на себя Fable тратит на $0,45 меньше. У Fable ведущая часть проходит 11,5 раундов, тогда как у Opus — 26,5; выходных output токенов у Fable примерно треть (6,1 тыс. против 19,0 тыс.), и input токенов тоже примерно треть. Хотя у Fable цена за токен заметно выше, она побеждает за счёт управления контекстом и сокращения числа раундов.

Экономия токенов у Fable происходит потому, что оно аккуратно избегает лишней работы. Интересно, что в 81% прогонов, где ведущим был Fable, ведущая модель ни разу с начала до конца не делала правки кода. У Opus так только в 24% случаев. В 13% прогонов с ведущим Fable ведущая модель даже ни разу не прочитала напрямую ни одного файла repo.

Микроменеджер со стажёром vs менеджер с опытным инженером

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

Opus же часто делегирует слишком поздно — после длинного периода самостоятельного исследования и реализации; к тому времени проектные решения уже приняты, важные файлы уже лежат в её контексте, и дорогая работа уже выполнена.

Типичный прогон, где ведущим является Fable, начинается с нескольких разведывательных шагов по repo, затем записывается сводка‑спецификация уровня «сделать так». После этого весь цикл «реализация + тестирование + lint» делегируется целиком. Затем следует git show для проверки diff, после чего выполняется коммит.

Типичный прогон, где ведущим является Opus, проходит через 20–45 раундов самостоятельного исследования, проектирования и реализации, а затем уже поздно происходит ещё одна передача — но только механическое «дозакрытие», которое почти нечего делать заранее.

Иногда первый же шаг Fable в рамках одного этапа — это делегирование. На одном и том же задании старт у двух ведущих моделей выглядит так:

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

Управленческий стиль каждой модели виден уже в самой сводке‑передаче. Когда Opus делегирует реализацию, он отдаёт инструкции; а Fable — пишет документ по дизайну:

Делегирование — это не только перенос затрат. Оно меняет качество работы. Пример хэширования (hashing) очень показателен. В спецификации задания требовалось, чтобы функция хэширования имела O(1) по длине указателя (pointer). Opus реализовал это сам, но ни разу не записал требование явно. На одном из шагов оно было забыто, и он передал реализацию с линейным временем, в результате — 25 баллов. В противоположность этому Fable делегировал, задавая ограничение на высоком уровне: в его сводке было написано: «operator() должен быть O(1) по длине указателя: не выполнять полный скан токенов». Помощник успешно реализовал это и получил 94 балла.

Мы обнаружили, что этот паттерн обобщается на разные задачи. Сводки‑передачи у Fable перечисляют ограничения, крайние случаи и определение «что считается сделанным» — и этим они экономят силы Fable и позволяют помощнику выполнить реализацию дёшево и правильно.

После передачи

Вторая половина — что именно ведущий agent делает с результатом, возвращённым помощником. Обе ведущие модели часто запускают одинаковые дешёвые проверки: два‑три вызова git diff / git show. Но на этом Opus не останавливается. Он извлекает файлы из контекста помощника в свой контекст примерно в 2 раза чаще и делает до 4 раз больше корректирующих правок, используя ценник ведущей модели. В самом крайнем случае он отменяет результаты помощника полностью, переписывая всё сам:

И недоверие Opus не повышает корректность. В некоторых прогонных заданиях одна единственная проверка diff у Fable находит реальный баг помощника — и Fable выбирает сделать ещё одну более дешёвую передачу вместо того, чтобы так часто прибегать к переписыванию на уровне ведущей модели.

Когда делегирование не помогает

Стратегия делегирования Fable не универсальна; когда в задаче нет компонент, которые можно делегировать, она перестаёт работать. Следующие типы задач, похоже, трудно разложить на части:

• Короткие задания, где есть всего несколько раундов ведущей модели, и между «решением» и «передачей» нечего делегировать.
• Последовательные задачи отладки, где корневая причина — это длинная цепочка последовательных суждений. Здесь накопленный контекст сам по себе и есть работа.

Важно отметить: в таких задачах Fable почти не делегирует. То суждение, которое умеет писать хорошие сводки, также понимает, когда делегировать не стоит. Но если в задаче нет ничего, что стоит передавать, у делегирования просто нет «точек приложения» по затратам.

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

Заключение

В начале этого эксперимента мы ожидали измерить, насколько «двукратная надбавка» у Fable увеличит стоимость. Но мы были удивлены: эффективное делегирование Fable на практике снижает общие затраты. Оно указывает ограничения и результат, а не расписывает реализацию шаг за шагом; оно даёт обратную связь, а не чинит всё руками; и в большинстве случаев оно вообще не трогает код. Это — привычки хорошего менеджера.

По мере того как модели‑помощники становятся дешевле и лучше, им можно делегировать больше работы. А платить «цену frontier» в будущем будет стоить именно суждение: что делать, какие ограничения задавать и кому именно писать.