Семь раз Haiku, один раз - Opus Сегодня обсуждали графики METR (это бенчмарк, где меряют, какой длительности задачу программиста модель может решать автономно). По дефолту график показывает: Opus 4.6 — 12 часов работы программиста, дальше Gemini, GPT-5.2 и т.д. Но я тут заметил мелочь, на которую раньше не обращал внимания: эти 12 часов — при success rate = 50%. То есть в половине случаев Opus решит, в половине — нет. А что если переключить на 80% надёжности (всё ещё не 100%, кстати)? Лидерборд переколбашивается, и Opus уже не 12 часов, а 1ч 10мин. В 10 раз меньше o__O И вот уже Gemini на 1м месте - см. аттач Почему METR выбрал 50% по дефолту? Тут вспоминается Anthropic-овский пост про 2 типа метрик - помните pass@k vs pass^k? - pass@k = достаточно ОДНОГО успеха из k попыток (генерация кода, поиск решения, тулколлы) - pass^k = нужен успех в КАЖДОЙ попытке (письмо клиенту, перевод денег, финальный аутпут) В первом случае вероятности складываются — с каждой попыткой шанс хоть одного успеха растёт. 50% × 7 ≈ 99% (формула 1−(1−p)ⁿ). Во втором — перемножаются. 90% × 5 = 0.9⁵ = 59%. См скриншот в аттаче Из этого [pass@k vs pass^k] есть, кстати, прикладной совет для разработки агентов: Пройтись по своему пайплайну и пометить каждый шаг: retryable он или нет. А дальше уже арифметика: допустим, у вас Opus с 90% успехом или Haiku с 50% на retry-able шаге. 7 запусков Haiku даёт выше надежность при сопоставимой стоимости. Вы, возможно, замечали как Claude Code сам так работает: тулзы часто вызывает Haiku, иногда криво — но через 2-3 попытки правильно. Не баг, а фича. Собственно, имхо вполне нормально, что METR по умолчанию берут 50% success rate, учитывая тип задач, которые они тестят.