Opus 5: почему рекорды тестов расходятся с практикой

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

Что показали тесты

На внутреннем бенчмарке Frontier-Bench v0.1 Opus 5 набрала 43,3 балла против 18,9 у Opus 4.8 — результат более чем вдвое выше предшественника и заметно выше ближайшего конкурента. Модель уверенно держится в верхней части публичных рейтингов по программированию.

Сильные стороны подтверждаются и вне тестов: длительные автономные задачи, исследовательская работа, управление компьютером, сложные визуальные проекты. Здесь модель работает долго без вмешательства человека и доводит задачу до конца.

Что увидели в рабочих условиях

Сервис проверки кода CodeRabbit прогнал модель на своей контролируемой выборке с заранее известными дефектами. Opus 5 нашла меньше этих дефектов, чем базовая система компании, и при этом выдала примерно вчетверо больше малозначительных замечаний.

Расход токенов оказался второй проблемой. На одной и той же работе по ревью кода Opus 5 тратила около 60,5 тысячи входных и 9,5 тысячи выходных токенов за вызов против примерно 40,5 тысячи и 5,8 тысячи у GPT-5.6. То есть читает она примерно на 50 процентов больше, а пишет на 65 процентов больше при том же результате.

Тео Браун, разработчик и глава T3 Chat, описал поведение модели так: почти любой комментарий в коде она воспринимает как критическую проблему и предлагает переписать тысячи строк. После дня плотной работы он оценил реальную экономию от перехода на Opus 5 примерно в 20 процентов вместо ожидаемых по прайсу цифр — именно из-за повышенного расхода токенов на задачу.

Откуда берётся разрыв

Бенчмарк и рабочий день устроены по-разному, и это объясняет большую часть расхождения.

• В тесте задача сформулирована полностью, критерий успеха известен заранее, а контекст ограничен. Модель оптимизируется ровно под это.
• В работе инструкция обычно неполная, требования меняются по ходу, а от небольшой проблемы ждут небольшого исправления. Модель, склонная к исчерпывающему ответу, здесь проигрывает даже при более высоком интеллекте.
• Тщательность, которая приносит баллы на длинной автономной задаче, на коротком ревью превращается в шум: четырёхкратный поток мелких замечаний утомляет ревьюера сильнее, чем помогает.

Ни один из этих пунктов не говорит, что модель слабая. Он говорит, что метрика и сценарий использования разошлись.

Почему собственный бенчмарк — слабый аргумент

Frontier-Bench — тест самой Anthropic. Это не делает цифры выдуманными, но означает, что набор задач и критерии оценки выбирала сторона, заинтересованная в результате. Независимая проверка CodeRabbit проводилась на другом наборе задач и дала обратный знак: меньше найденных дефектов при большем потоке замечаний.

Обе цифры верны одновременно. Просто они измеряют разное, и ни одна не отвечает на вопрос, станет ли конкретной команде работать легче.

Что с этим делать

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

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

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