Як зробити Fable дешевшим за Opus: змініть структуру витрат агентів за допомогою делегування

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

Зміст

Toggle

• Вступ
• Налаштування експерименту
• Вартість одного agent-а
• Мікроменеджер із практикантом vs менеджер із досвідченим інженером
• Після передачі
• Коли делегування не допомагає
• Висновки

Ми замінили Opus 4.8 на Fable 5, а рахунок Devin натомість знизився.

Вартість Fable 5 за токен у два рази вища, ніж в Opus 4.8. Але коли ми запускаємо обидві моделі на новій архітектурі Fusion одночасно на FrontierCode 1.1, Fable виявився дешевшим. Нічого дивного: його бали також вищі. У цій статті пояснюється чому, і що це означає для «цінування агентних (agentic) робіт».

Вступ

Кожен, хто запускає програмні agent-и, знає: сильніша модель дає кращі результати, але ти маєш «ковтнути» вартість.

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

Але якщо головна модель делегує більшість роботи, чи її ціна за токен усе ще домінуватиме над усім рахунком? Вартість Fable 5 за токен у два рази вища за 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 |

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

Налаштування експерименту

Швидко нагадаємо, як працює структура помічника в Fusion. Головний agent має весь робочий сесійний контекст: він спілкується з користувачем, планує, переглядає роботу і робить commit. Також у нього є постійно присутній дочірній під-agent, який використовується для делегування задач. Головна модель простими словами пише службову/перехідну записку про передачу (handoff), а дочірній agent, що приводиться в дію значно дешевшою моделлю, виконує це у своєму власному контексті та повертає результати. Головна модель перевіряє результати і вирішує, що робити далі.

Щоб з’ясувати, куди саме йдуть витрати, ми зробили дві речі. По-перше, ми розібрали кожен із викликів LLM у всіх 3,000 робочих сесіях: яка модель говорить, які інструменти вона викликає, скільки токенів вона читає/пише і скільки грошей коштує кожен виклик. По-друге, ми відібрали 40 задач для ближчого спостереження: ті, де Fable явно дешевший, ті, де Opus явно дешевший, а також ще одна група випадкових зразків із проміжного регіону. Для кожної ми аналізували пліч-о-пліч виконання, де головною була Fable, і де головною була Opus, дивилися їхні траєкторії та спостерігали, куди пішли гроші.

Вартість одного agent-а

Нижче показано, як у нашому експерименті витрати розподілялися між головною моделлю та помічником:

| | | --- | Головна $ | Помічник $ | Загальна вартість за запуск $ | Раундів за запуск (головна) | Вхідні токени (в сумі) | | --- | --- | --- | --- | --- | | Fable + помічник | $1.28 | $0.58 | $1.86 | 11.5 | 545k tok | | Opus + помічник | $1.73 | $0.31 | $2.04 | 26.5 | 1，679k tok |

Fable витрачає на помічника більше, ніж Opus — на $0.27 більше за кожен запуск. Але вона витрачає на себе менше — на $0.45. Головна модель у Fable проходить 11.5 раундів за запуск проти 26.5 у Opus; кількість output-токенів лише третина (6.1k проти 19.0k), а витрачені input-токени теж лише третина. У перерахунку на токен Fable помітно дорожча, але їй вдається перемогти за управлінням контекстом і за кількістю раундів.

Економія токенів у Fable походить від того, що вона просто уникає роботи. Цікаво, що в 81% запусків, де головною була Fable, головна модель від початку до кінця не робила жодної правки коду. У Opus так само — лише 24% виконань. У 13% запусків, де головною була Fable, головна модель навіть жодного разу не читала жоден файл із repo власноруч.

Мікроменеджер із практикантом vs менеджер із досвідченим інженером

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

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

Типовий запуск, де головною є Fable, починається з кількох розвідкових дій у repo, а потім вона пише бриф рівня специфікації (spec-level memo), делегуючи весь цикл «імплементація + тестування + lint» за один раз. Далі йде git show для перегляду diff, а потім — commit.

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

Іноді перша дія Fable на одній робочій сесії — це передача. На тому ж завданні старт у двох головних моделей виглядає так:

Очевидне рішення — змусити Opus делегувати більше досліджень, але нав’язування такої поведінки зазвичай знижує якість. Знати, коли дослідження можна безпечно делегувати, а коли ти мусиш робити це сам — це й є судження. Модель, яку змушують делегувати, не набуде такої здатності до судження; вона лише делегуватиме те, що не треба.

Керівний стиль кожної моделі проявляється вже в самій передавальній записці. Коли Opus делегує реалізацію, він дає команди; а Fable — пише документ із проєктним описом:

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

Ми виявили, що такий патерн узагальнюється на різні задачі. Передачі в Fable перелічують різні обмеження, граничні випадки та дають визначення того, що вважається «зроблено», — і це економить їй зусилля, а помічнику дозволяє виконати реалізацію дешево й правильно.

Після передачі

Друга частина — що робить головний agent із результатами, які він отримує від помічника. Обидві головні моделі часто виконують ті самі дешеві перевірки: 2–3 виклики git diff / git show. Але Opus на цьому не зупиняється. Вона витягує файли помічника в свій контекст у 2 рази частіше та робить до 4 разів більше виправних правок за ціною головної моделі. У найекстремальнішому випадку вона повністю відміняє (він же — «ще раз переробляє») результати помічника: вона все відновлює і переписує власноруч:

Але недовіра Opus не підвищила правильність. У деяких задачах з оцінювання Fable з однієї лише перевірки diff знайшла справжній баг помічника і вирішила провести ще одну дешеву передачу, а не так часто, як у Opus, вдаватися до перезапису на рівні головної моделі.

Коли делегування не допомагає

Стратегія делегування Fable не універсальна; коли в задачі немає компонентів, які можна делегувати, вона втрачає ефективність. Наступні типи задач, здається, важко розбити:

• Короткі задачі, що складаються лише з кількох раундів головної моделі, де між «вирішенням» і «передачею» немає нічого, що можна делегувати.
• Послідовні задачі з дебагу, де кореневу причину потрібно довго розкручувати ланцюжком безперервних суджень. Тут накопичений контекст сам по собі є роботою.

Важливо зазначити, що в цих задачах Fable майже не делегує. Та сама здатність, яка вміє писати хороші записки, також знає, коли не варто. Але коли в задачі немає нічого, що заслуговує на делегування, делегування взагалі не дає ефекту щодо витрат.

У повноцінному виробничому середовищі Fusion вирішує це на ще одному рівні: рішення про делегування визначає, які роботи лишаються в руках дорогої моделі, а роутинг (routing) вирішує, чи взагалі потрібно втягувати дорогу модель у процес.

Висновки

Коли ми почали цей експеримент, ми очікували оцінити: на скільки збільшаться витрати через 2-кратну премію Fable. Але ми дуже здивувалися, коли виявили, що ефективне делегування в Fable фактично знижує загальну вартість. Вона вказує обмеження й результати, а не розписує імплементацію крок за кроком; вона дає фідбек, а не робить усе сама; і в більшості випадків вона взагалі не торкалася коду. Усе це — звички хорошого менеджера.

У міру того, як помічники стають дешевшими й кращими, дедалі більше роботи можна віддавати їм. А те, за що все ще варто платити «frontier»-ціною в майбутньому — це судження: що потрібно робити, які обмеження встановлювати і кому саме писати.