Anthropic выпустила Fable 5.2: результат уровня Opus почти за полцены на задачу

ИИ-агент может часами исправлять баг, запускать тесты и переписывать собственный патч. Для команды вопрос быстро становится денежным: сколько стоит изменение, которое разработчик действительно согласится принять? Anthropic выпустила Fable 5.2 и заявила, что на одном тесте программирования модель приблизилась к результату Opus 5.5 при почти вдвое меньшей стоимости задачи. Это повод проверить настройки своего агента, особенно если расходы на долгие рассуждения уже заметны в бюджете.

Откуда берётся экономия

На FrontierCode 2.0 Fable 5.2 с настройкой High показала 45,3%, а Opus 5.5 с Max — 45,5%. Тест оценивает, приняли бы сопровождающие открытых репозиториев предложенные моделью изменения. По данным компании, стоимость задачи у Fable в этом сравнении была примерно вдвое ниже. API новой модели стоит $8 за миллион входных токенов и $40 за миллион выходных. Источник цифр — анонс Anthropic.

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

Настройка глубины рассуждений тоже становится частью выбора. Сравнивать модели только на максимальных режимах удобно для таблицы рекордов. Для продукта полезнее найти режим, который даёт приемлемое качество при доступном бюджете. Результат Anthropic показывает, почему такой эксперимент имеет смысл, хотя заранее обещать ту же экономию конкретной команде нельзя.

Как проверить на знакомом баге

Представим сервис подписок: после повторного запроса клиент иногда получает два одинаковых начисления. Агенту нужно разобраться в обработке повторов, поправить код и добавить проверку. Красиво написанное объяснение здесь ничего не решает, если дубли продолжают появляться.

Для сравнения моделей подготовьте одинаковый снимок репозитория, описание ошибки и доступные инструменты. Задайте одинаковые ограничения на время и расходы. Затем проверьте, устраняет ли патч исходную проблему, проходят ли существующие тесты и не меняется ли поведение соседних сценариев. Ревьюеру полезно сначала оценить изменения без названия модели: так меньше соблазна простить ошибку фавориту.

Одного бага мало. Соберите небольшой набор уже решённых задач: исправление регрессии, доработку API, изменение схемы данных, поиск причины медленного запроса. Для каждой сохраните стоимость запусков, число повторных попыток и время проверки человеком. Основная метрика — расходы на принятое исправление. Долю успешных задач и длительность выполнения стоит смотреть рядом, иначе экономия может скрывать ухудшение качества или скорости.

Для продакта это способ проверить конкретную гипотезу: можно ли обслуживать больше сложных запросов при том же бюджете. Для основателя — возможность оценить себестоимость функции до того, как обещать пользователям безлимитного помощника.

Где заканчиваются выводы из анонса

У опубликованного сравнения есть существенное ограничение: результаты представил сам поставщик. Ваши репозитории, инструменты, инструкции и критерии приёмки могут заметно отличаться от тестовых. Разница между 45,3% и 45,5% сама по себе также не доказывает равенство моделей во всех инженерных задачах.

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

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