На этой неделе на Хабре развернулся спор о том, нужны ли программисту самые умные модели. Поводом стала статья «Я перестал пользоваться самыми умными ИИ-моделями»: её автор утверждает, что для рутины хватает дешёвых, а упирается всё теперь в скорость. Под материалом почти триста комментариев, но замеров на одинаковых задачах в них не нашлось. Автор нового сравнения взял пять типовых задач на Python — от одного до пяти файлов — и прогнал их через четыре модели одного семейства.

Задачи подобраны как повседневная рутина разработчика: off-by-one в пагинации, переименование функции во всём проекте с подвохом (в одном месте имя лежит строкой в словаре и вызывается через getattr), нормализация российского номера телефона по словесному описанию, разбиение функции на полсотни строк с тройной копипастой на части по двадцать строк с сохранением вывода байт в байт, и делёж счёта на n человек с потерей копеек. Модели — Haiku 4.5, Sonnet 5, Opus 5 и Fable 5.1. Агент везде один: Claude Code в режиме -p, MCP отключён, промпт один, на каждый прогон чистая папка. Каждую задачу гоняли по два раза на каждой модели, итого сорок прогонов. Проверял скрытый скрипт, которого модель не видит: там тесты автора и проверка, что видимые тесты никто не подправил.

МодельРешеноВремя на 10 прогоновХодов агентаТокенов выводаЦена к младшей
Haiku 4.58 из 10395 с10039 137
Sonnet 59 из 10450 с10931 3593,3×
Opus 510 из 10557 с10839 4556,9×
Fable 5.110 из 10341 с8523 0108,8×

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

Четыре задачи из пяти — пагинация, переименование через getattr, нормализация телефона, рефакторинг — все модели решили 32 раза из 32.

Вся разница вылезла на пятой задаче — делёжке счёта. Наивное решение через divmod(total_cents, n) с раздачей остатка первым в списке даёт для 1000 на троих [334, 333, 333], но для возврата −1000 — [-333, -333, -334]: деление в Python округляет вниз, и лишняя копейка уезжает в конец списка. В требованиях было «лишние копейки достаются первым», так что формально это ошибка. Haiku 4.5 написала именно так оба раза, Sonnet 5 — один раз из двух. Opus 5 и Fable 5.1 все четыре раза делили модуль суммы, а знак возвращали потом, и в отчёте объяснили, почему так. Fable 5.1 в одном прогоне ещё и написала скрипт, перебравший все суммы от −300 до 299 при n от 1 до 11, хотя её об этом не просили.

Отдельно автор отмечает отчёт младшей модели: две галочки подряд, где вторая строка опровергает первую. Видимый тест зелёный, отчёт бодрый, а баг вылезет на первом же возврате. Справедливости ради, требование про возвраты можно прочитать по-разному, и кто-нибудь в комментариях наверняка скажет, что [-333, -333, -334] тоже нормально. Но старшие модели эту развилку увидели и объяснили, что выбрали. Младшая просто поставила галочку.

По времени и токенам картина неочевидная. Самая дорогая модель оказалась и самой быстрой: 341 секунда против 395 у самой дешёвой. Причина видна в соседних колонках: у старшей меньше ходов агента и почти вдвое меньше текста. Младшая много рассуждает — 18 754 токена размышлений на десять прогонов против 2 674 у старшей. Токены у неё летят быстрее, но их надо больше, и в сумме выходит дольше. При этом Opus 5, вторая сверху по цене, оказалась самой медленной из четырёх, так что «дороже значит быстрее» тоже не работает. Автор для себя решил смотреть на время задачи целиком: токены в секунду его не предсказывают.

Практический вывод автора такой. Задачи, где всё расписано и есть тесты, он отдаёт младшей модели: 32 из 32 и дешевле почти на порядок. Если в требованиях мелькает «и для отрицательных», «и для пустого», «как было раньше» — берёт старшую. Код дешёвая модель пишет нормально, она пропускает сам вопрос. И отчёту «всё работает» он верит ровно настолько, насколько сам видит проверку: один скрытый тест на граничный случай дешевле любой модели. В UPD автор уточняет, что все прогоны в таблице шли на дефолтном уровне reasoning (high), и он перепроверил три старшие модели на low.