Anthropic випустила Fable — найпотужнішу модель у лінійці Claude за власними бенчмарками компанії, — але бізнес не поспішає переносити на неї продакшн-навантаження. За даними Mezha, компанії масово лишаються на дешевших моделях або переходять до конкурентів, попри технічну перевагу флагмана Anthropic.

Причина не в якості відповідей. Fable виграє більшість тестових таблиць, на яких Anthropic будує маркетинг випуску. Проблема — в тому, що продакшн-агент викликає модель не один раз на запит користувача, а десятки: планування кроку, виклик інструменту, перевірка результату, повторна спроба. Кожен такий виклик множить ціну токена на обсяг, і ця сума стає рядком у щомісячному рахунку CFO, а не абстрактним відсотком у бенчмарку.

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

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

Чому компанії обирають дешевші моделі замість флагмана?

Бо в продакшні рахунок формує обсяг викликів, а не якість однієї відповіді. Коли агентний пайплайн виконує запит користувача через ланцюжок із п'яти-десяти звернень до моделі, різниця в ціні за мільйон токенів між флагманом і середнім рівнем лінійки помножується на весь цей ланцюжок. Якщо дешевша модель закриває задачу з прийнятною якістю за третину чи чверть ціни Fable, фінансова логіка переважає перевагу в бенчмарку, яку кінцевий користувач найчастіше навіть не помічає.

Де перевага Fable не конвертується в гроші?

Там, де для задачі достатньо середнього рівня якості, а різниця в точності не впливає на результат, який бачить користувач. До таких задач у продакшн-агентах найчастіше належать:

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

У цих сценаріях компанія платить за токени флагмана, не отримуючи різниці, яку можна конвертувати в утримання клієнта чи виручку.

Кому все ж варто платити за найпотужнішу модель?

Там, де ціна однієї помилки перевищує різницю в ціні токена на порядки. Це складне мультиагентне планування з довгими ланцюжками рішень, юридичний і медичний аналіз, а також архітектурні рішення в коді, де відкат помилки коштує дорожче за будь-яку економію на API. Саме тому питання, скільки самостійності довірити моделі на кожному кроці, стає окремою інженерною задачею — ми розбирали це в матеріалі про те, скільки автономії безпечно дати AI-агенту. Так само організація самих агентних систем — з чіткими ролями та контролем результату на кожному рівні, за аналогією з тим, чому AI-агентам потрібна ієрархія, як у компанії — дозволяє тримати дорогу модель лише там, де вона справді потрібна, а не на кожному кроці пайплайну.

Висновок AiiN: unit-економіка важливіша за бенчмарк

За нашою оцінкою, ринок LLM переходить від гонки бенчмарків до гонки unit-економіки: перемагає не модель з найвищим балом, а та, що дає прийнятну якість за прогнозованою ціною на мільйон запитів. Anthropic і конкуренти можуть випускати новий флагман щоквартал, але доки продакшн-пайплайни не навчаться систематично розподіляти виклики між рівнями моделей — дорогу модель лише туди, де ціна помилки виправдовує ціну токена, — масовий ринок і далі платитиме за середній рівень лінійки, а не за вершину. Для AI-білдерів практичний висновок простий: почніть з профілювання того, скільки викликів моделі реально припадає на один запит користувача, і лише потім вирішуйте, чи потрібен там флагман.

Що таке unit-економіка агента і чому вона важливіша за бенчмарк?

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

Чи означає непопулярність Fable, що модель невдала?

Ні: йдеться не про якість самої моделі, а про те, що для більшості продакшн-задач достатньо середнього рівня лінійки. Fable лишається доречним вибором для вузького класу задач із високою ціною помилки, а не для масового трафіку.