Claude Opus 5.5 или GPT-6 Sol: что показал бенчмарк BitGN на бизнес-агентах

22 сентября 2026 Anthropic выпустила Claude Opus 5.5, а OpenAI буквально через час ответила GPT-6 Sol и GPT-6 Luna - обычная гонка ценников, которая случается каждые пару месяцев. Через несколько дней канал "LLM под капотом" (бенчмарк BitGN, Ринат Абдуллин) прогнал все три модели плюс Astra 6 и Kimi K3 через свой датасет агентских бизнес-задач - не код, а закрытие тикетов, работа с заказами, финансовые процессы. Итог: GPT-6 Sol забрал первое место по соотношению цена/качество и первым из всех дошёл до 100% на подзадачах автокодинга, Luna сдвинула фронтир по стоимости, а Opus 5.5 упал на 26-е место из-за частых отказов выполнять запросы. Для тех, кто гоняет агентский пайплайн на Claude Code, вывод не "беги переезжай на Sol" - вывод в том, что на бизнес-задачах надёжность tool-calling важнее сырого интеллекта, и на переезде по одному лишь бенчу я уже обжигался. Sol и Luna я сам не гонял - про них здесь только чужой бенчмарк, а мой личный опыт пока только с Opus 5.5.

BitGN меряет не код, а доведённый до конца бизнес-процесс

BitGN - это агентский бенчмарк на бизнес-задачах: модель получает доступ к tool API (тикеты, заказы, платежи в симулированном мире) и должна довести процесс до результата, а не просто выдать текст. Оценка идёт без LLM-as-a-judge - результат либо воспроизводится в симуляции, либо нет.

Для тех, кто гоняет собственный агентский пайплайн, это важнее классических кодинг-бенчей: цикл "прочитать тикет - вызвать три инструмента подряд - закрыть заказ" ближе к тому, что реально делает крон-обвязка вокруг Claude Code, чем задачка вида "напиши функцию по описанию". Модель может писать отличный код и при этом плохо держать длинную цепочку вызовов инструментов без единой ошибки - именно это и меряет BitGN.

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

Задачи генерируются из фиксированных сидов на каждый прогон, но с вариациями мира - модель не может просто вызубрить сценарий заранее. Это отличает BitGN от статических кодинг-бенчей вроде SWE-bench, где решение реально нахардкодить под конкретный тест-сет.

На графиках самого автора есть отдельная серая линия - старый фронтир качества и цены по состоянию на июль 2026, до текущей волны релизов. Свежие модели сравнивают не только друг с другом, а с этой линией: вопрос не "кто выиграл в этом раунде", а "насколько сдвинулся баланс цена/качество за два месяца". На этом фоне Luna сдвинула фронтир по стоимости, а Sol стал лучшей моделью за свои деньги - и заодно самой быстрой при таком качестве.

Кто и с каким счётом попал в рейтинг BitGN

На бизнес-агентском срезе BitGN по состоянию на конец сентября 2026 расклад такой (модели без открытой цены за 1М токенов в своём API-прайсинге в таблице помечены отдельно; цены - по сводке релизов Simon Willison, проверено 05.10.2026):

Кэшированный вход у Opus 5.5 и Sol совпадает - $0,20 за 1М токенов, у Opus 5.5 это на 60% дешевле, чем в предыдущей версии. Но экономия на кэше не спасает от отказов на конкретных агентских сценариях.

Из-за чего Claude Opus 5.5 оказался на 26-м месте BitGN

Opus 5.5 упал в рейтинге не из-за качества ответов, а из-за отказов: на части задач бизнес-датасета модель не выполняет запрос, а возвращает refusal вместо результата. В чате с человеком это раздражает, но терпимо - человек перефразирует промпт и идёт дальше. В автоматизированном пайплайне без человека в петле каждый отказ - это упавшая задача, а не просто более низкий балл в таблице.

Это системная разница между "модель умнее в диалоге" и "модель надёжнее в агентском контуре": Opus 5.5 может быть сильным собеседником в чате и одновременно проигрывать на автоматических бизнес-прогонах, где нет человека, готового объяснить модели, что запрос безопасный.

У моделей Anthropic отказ - это отдельное техническое состояние, а не просто плохой ответ: API может вернуть stop_reason=refusal вместо результата, и пайплайн должен ловить именно этот код, а не путать его с обычной ошибкой выполнения инструмента - я разбирал это на живом инциденте, когда модель Anthropic отказала посреди пайплайна. Если агент не различает "инструмент упал" и "модель отказалась", в логах BitGN и в логах своего пайплайна оба случая выглядят как одна и та же проваленная задача.

При этом отказы - не панацея от рисковых сценариев: тот же пост #946 отдельно отмечает, что через Opus 5.5 всё равно удалось протащить два прокола безопасности. Модель может рефьюзить очевидно опасный запрос и пропустить менее явный - осторожность на бумаге не равна надёжности на практике.

Что показывают другие бенчи по бизнес-задачам агентов

BitGN - не единственный, кто мерил модели на бизнес-агентах в сентябре 2026. На AutomationBench (агенты работают в 47 рабочих инструментах: продажи, маркетинг, поддержка, финансы, HR) GPT-6 Sol на уровне рассуждений xhigh набрал 33,2% и обошёлся в $0,27 за задачу, тогда как Claude Opus 5 на максимальном уровне показал 26,9% и стоил в 11,1 раза дороже за задачу. На Agents' Last Exam - бенче с длинными экономически значимыми задачами из 55 индустрий - Sol на максимальном эффорте набрал 56,4%, обогнав лучший результат Opus 5, и это на 60% дешевле за задачу.

Важная оговорка: оба сравнения - против Claude Opus 5, а не 5.5. Opus 5.5 вышел в тот же день, примерно на час раньше Sol, и в бенчмарках запуска Sol меряют против Opus 5 и Fable 5.1, а не против Opus 5.5 - прямого сравнения нет. Есть только независимый прогон BitGN, где Opus 5.5 уже участвует и проседает по отказам.

Разница между бенчами важна: в опубликованных цифрах AutomationBench и Agents' Last Exam видна только итоговая точность и цена за задачу, без разбивки по причине провала - рефьюз там, судя по всему, считается такой же неудачей, как обычная ошибка. BitGN в этом смысле нагляднее: пост #946 отдельно называет отказы причиной падения Opus 5.5, а не просто её итоговое место. Это и объясняет, почему одна и та же модель может звучать сильной в отчётах по чистой точности и слабой в конкретно агентском бизнес-рейтинге - смотря какую метрику считать главной.

Что я сделал у себя после релиза: прибил модель к конвейеру

Сразу оговорка, чтобы не было путаницы: GPT-6 Sol и Luna в своём пайплайне я не запускал. Всё, что выше про них, - чужой бенчмарк, а не моя практика. Мой опыт только с Opus 5.5, и первым делом он оказался не про отказы, а про то, что модель под капотом может смениться молча.

Конвейер статей и постов у меня держится на восьми вызовах claude -p в cron-обёртках: черновики, проверка, правки, беклог тем, Threads. Пока модель в них не была указана явно, каждый вызов брал дефолт CLI. А дефолт уезжает вместе с релизами - после волны вроде 22 сентября пайплайн мог тихо пересесть на другую модель, и я бы понял это по странным текстам где-то через неделю. А новая модель на старых промптах - это миграция, а не бесплатный апгрейд, ниже расскажу, во что мне обошлась прошлая.

01.10.2026 закрепил модель явно. В общей библиотеке cron-обёрток одна переменная окружения:

export BP_CLAUDE_MODEL="${BP_CLAUDE_MODEL:-claude-opus-5-5}"

И --model во всех восьми вызовах, например в обёртке правок черновиков:

claude --model "$BP_CLAUDE_MODEL" -p "/blog-edit $id" --permission-mode acceptEdits

Поверх этого тест: проходит по всем обёрткам регэкспом и падает, если хоть один вызов claude не пинит модель. Падает он и тогда, когда вызовов нашлось меньше восьми - значит, сломался сам регэксп, а не "всё чисто". Захочу попробовать другую модель - поменяю одну переменную, а не буду вспоминать, где ещё остался голый claude -p.

Проверил в тот же вечер на реальном cron-прогоне генерации постов Threads. В логе сессии 51 ответ модели, все 51 - claude-opus-5-5. Итог прогона: добавлено 6, отклонено 0, отправлено 6, упало 0. Это один прогон и один тип задач, так что вывод скромный: на моей схеме тулов Opus 5.5 пайплайн пока не валит, а 26-е место в BitGN - это про чужую схему тулов, не про мою.

Почему место в чужом рейтинге не переносится на свой пайплайн

Я уже переезжал пайплайн блога на новую модель по чистому счёту в бенчах - когда переходил на Opus 5, половина скиллов сломалась от смены поведения модели на тех же промптах. Дешевле за задачу и выше в рейтинге не значит "подставь новый model= и всё заработает": у каждой модели свой стиль вызова тулов и свой порог, после которого она решает, что запрос слишком рискованный, и рефьюзит. Мой пайплайн - это не один промпт, а полтора десятка скиллов Claude Code поверх Claude API, и claude code skills в такой связке ведут себя как хрупкий контракт: смени модель под капотом - и часть скиллов начинает падать не на логике, а на самом формате вызова тула.

Поэтому смотреть на голый процент в BitGN для своего пайплайна на Claude Code - плохая идея. Смотреть стоит на три вещи. Первое - как часто модель отказывается конкретно на твоей схеме тулов, а не на абстрактном бизнес-датасете чужой компании. Второе - что ломается в промптах и скиллах при миграции: я уже считал реальную стоимость прогона агента, и там львиная доля цены сидит не в токенах модели, а в количестве неудачных попыток и ретраев. Третье - экономика по факту, а не по прайс-листу: то же самое я разбирал на паре Kimi K3 против Opus 4.8 - дешевле по токену не значит дешевле по задаче, если модель тормозит или требует больше шагов на тот же результат.

Что в итоге делать прямо сейчас

Если пайплайн уже стоит на Claude Code и работает - переезжать на Sol только из-за одного бенчмарка рано: прямого сравнения именно с Opus 5.5 нет, а миграция стоит дороже, чем экономия в центах за задачу. Если пайплайн собирается с нуля или уже гоняет несколько моделей параллельно под разные типы задач - GPT-6 Sol и Luna стоит добавить в ротацию именно для агентских, не творческих задач: там разница в цене и в частоте отказов ощутима сильнее всего.

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