Claude Opus 5 против GPT-5.6-SOL: проверка на 10 задачах — по точности основных ответов ничья

Что именно означает «модель умнее» — быстрее отвечает, правильно решает задачу или строго соблюдает формат?

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

Обе модели получили одинаковые условия через один OpenAI-compatible endpoint Crazyrouter. Основной набор состоял из 10 задач; строгое соблюдение JSON проверялось отдельно.

Результаты:

• точность основных ответов: Claude Opus 5 — 10/10, GPT-5.6-SOL — 10/10;
• полное выполнение всех подпунктов: Claude Opus 5 — 9/10, GPT-5.6-SOL — 10/10;
• скрытые тесты двух задач на Python: обе модели — 2/2;
• строгий JSON с первой попытки: Claude Opus 5 — 0/1, GPT-5.6-SOL — 1/1;
• в двух дополнительных попытках Opus по-прежнему добавлял к JSON посторонний текст или оформление.

Итог нельзя свести к одному общему баллу: по правильности основных рассуждений модели выступили одинаково, но по полноте и формату ответа — по-разному.

Создать API Key и повторить тестирование на собственных задачах

Краткий ответ

Вопрос	Результат теста
Какая модель точнее решила основные задачи?	Ничья: обе модели получили 10/10
Какая модель выполнила больше заданий целиком?	GPT-5.6-SOL — 10/10; Opus 5 — 9/10
Какая модель надежнее генерирует код?	В этом наборе ничья: обе прошли скрытые тесты двух алгоритмических задач, то есть 2/2
Ошибся ли Opus в сложной задаче по теории вероятностей?	Нет. Основной ответ правильный, но вывод был оборван при max_tokens=3200, поэтому последнее требуемое объяснение отсутствовало
Какая модель точнее соблюдает строгий JSON?	В этом тесте GPT-5.6-SOL: 1/1 с первой попытки против 0/1 у Opus; две дополнительные попытки Opus также не соответствовали формату
Доказывает ли это, что GPT в целом умнее?	Нет. Правильность рассуждений, полноту ответа и соблюдение формата следует оценивать раздельно

Если приоритет — проверяемая правильность математики, физики и алгоритмов, этот набор не выявил преимущества одной модели. Если ответ должен без дополнительной обработки разбираться как JSON или содержать каждый обязательный подпункт, GPT-5.6-SOL в данном тесте показал более стабильную доставку результата.

Почему задержка сети не входит в оценку интеллекта

Полное время ответа API зависит не только от самой модели. На него влияют:

• сетевой маршрут от шлюза до вышестоящего сервиса;
• текущая нагрузка на канал и ограничения учетной записи;
• попадание в кеш;
• выбор конкретного обслуживающего экземпляра;
• способ учета или сокрытия reasoning token вышестоящим сервисом.

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

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

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

Среда и методика проверки

Перед запуском использовался список моделей, чтобы убедиться в доступности точных идентификаторов:

GET https://cn.crazyrouter.com/v1/models

claude-opus-5
gpt-5.6-sol

Все основные запросы отправлялись по одному пути:

POST https://cn.crazyrouter.com/v1/chat/completions

Внутри каждого тестового набора обе модели получали одинаковые:

• system prompt;
• user prompt;
• значение temperature;
• значение max_tokens.

Внешние инструменты не подключались. Успешный HTTP-ответ сам по себе не считался доказательством прохождения задачи.

Три независимых уровня оценки

1. Точность основного ответа
   
   Проверялись ключевые числа, выводы, состояние математической модели и поведение алгоритма.

2. Полное выполнение задания
   
   Проверялось наличие всех подпунктов, которые были явно перечислены в условии.

3. Машинная проверяемость
   
   Код запускался локально на скрытых тестах, а строгий JSON передавался стандартному анализатору.

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

После автоматической проверки проводилась ручная перепроверка. Иначе различия в записи LaTeX, регистре, точной дроби и округленном десятичном значении могли бы дать ложные отрицательные результаты. Например, GPT-5.6-SOL в вероятностной задаче не повторил эталонную дробь буквально, но привел эквивалентную формулу и правильное десятичное значение. Opus в физической задаче записал 0.302 m как 0.30 m с двумя значащими цифрами — это также не является ошибкой.

Результаты 10 задач

Задача	Проверяемый результат	Claude Opus 5	GPT-5.6-SOL
Точная цепь Маркова	E[τ]=5, E[τ²]=43, Var(τ)=18	Правильно	Правильно
Осциллятор с двумя степенями свободы	Две собственные частоты, две амплитуды и две фазы	Правильно	Правильно
Поиск с ограничениями	Единственный порядок A,C,E,B,D	Правильно	Правильно
Исправление применения неравенства Кантелли	Вероятность не идентифицируется, верхняя граница равна 0.2	Правильно	Правильно
Проверка Python-кода поиска циклов	Ошибка, контрпример на DAG и минимальное исправление	Правильно	Правильно
Планирование эксперимента	Парное сравнение на одинаковых задачах, контроль сложности и доверительный интервал	Правильно	Правильно
Ожидание шаблона HHTH для смещенной монеты	Математическое ожидание около 12.6547 и правильные переходы состояний	Основной ответ правильный, последнее объяснение отсутствует из-за обрыва	Правильно и полностью
Алгоритм агрегирования журналов	Временное окно, события отказа, доля попаданий в кеш и пользователи с максимальными затратами	Скрытые тесты пройдены	Скрытые тесты пройдены
Неупругое столкновение и пружина	v1≈6.10, v2≈2.44, x≈0.302	Правильно	Правильно
Алгоритм стабильной маршрутизации	cost, latency, reliability и лексикографическое правило	Скрытые тесты пройдены	Скрытые тесты пройдены

Сводный результат основного набора:

• основные ответы — 10/10 у обеих моделей;
• полное выполнение всех подпунктов — 9/10 у Opus 5 и 10/10 у GPT-5.6-SOL;
• скрытые тесты кода — 2/2 у обеих моделей.

Самая сложная задача по теории вероятностей

В задаче требовалось найти ожидаемое число бросков до появления шаблона HHTH для смещенной монеты:

P(H)=0.62
P(T)=0.38

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

• почему после состояния HH и очередного H процесс остается в HH;
• почему математическое ожидание нельзя просто записать как 1/P(HHTH).

Обе модели получили правильный основной результат:

E[N] ≈ 12.6547

GPT-5.6-SOL завершил весь вывод и учел перекрытия шаблона:

E[N] = 1 / P(HHTH) + 1 / P(H)

Opus 5 также правильно определил состояния, составил уравнения и привел точную дробь вместе с десятичным результатом. Однако ответ завершился с:

finish_reason=length

При границе:

max_tokens=3200

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

Это различие напрямую показывает, зачем разделять два критерия:

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

Методологически это тот же риск, который рассматривался в повторном тесте обрыва по max_tokens: вместе с содержимым ответа необходимо сохранять finish_reason и заданный бюджет вывода. Частично правильный ответ нельзя автоматически считать полной доставкой результата.

Проверка исполняемого кода

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

Агрегатор журналов

Функция должна была корректно обрабатывать:

• полуоткрытое временное окно;
• разные правила учета успешных и неуспешных запросов;
• отсутствующих пользователей и модели;
• cache hit rate;
• лексикографическую сортировку пользователей при одинаковом cost;
• запрет на изменение входных объектов.

Обе реализации прошли скрытые тесты.

Стабильная маршрутизация с ограничением надежности

Алгоритм поиска пути должен был последовательно применять следующие критерии:

1. минимальная общая стоимость;
2. при равной стоимости — минимальная задержка;
3. при равной стоимости и задержке — максимальная надежность;
4. при полном равенстве — лексикографический порядок пути.

Дополнительно проверялись:

• banned nodes;
• максимальное число hops;
• минимально допустимая reliability;
• некорректные ребра.

Обе модели прошли и этот набор. Таким образом, результат по исполняемому коду — 2/2 у Claude Opus 5 и 2/2 у GPT-5.6-SOL. Оснований объявлять победителя по этим двум задачам нет.

Другой набор сложных задач по физике и алгоритмам приведен в материале GPT-5.6-SOL vs GPT-5.5: тест сложной физики и кода.

Строгий JSON: проверка формата, а не математических способностей

В отдельном задании нужно было представить данные об инциденте в виде одного объекта. Требование формулировалось однозначно:

exactly one JSON object and no Markdown

Обе модели правильно вычислили:

• долю отказов;
• принадлежность отказов к каналам;
• число запросов, не восстановленных после повторной попытки.

Различие возникло только на уровне выходного формата:

• GPT-5.6-SOL с первой попытки вернул только JSON, который можно было сразу передать в json.loads;
• Opus 5 с первой попытки добавил ограждение блока кода и раздел Verification;
• в первой дополнительной попытке Opus выдал компактный JSON, но затем снова добавил Verification;
• во второй дополнительной попытке Opus опять добавил ограждение блока кода и пояснение.

Итог строгой проверки с первой попытки:

• Claude Opus 5 — 0/1;
• GPT-5.6-SOL — 1/1.

Две дополнительные попытки Opus также остались несоответствующими строгому формату. При этом сами данные и значения полей были правильными.

Поэтому корректная классификация такова: данные верны, формат не соблюден. Это нарушение инструкции и контракта ответа, а не ошибка вычисления.

Минимальная локальная проверка

import json

REQUIRED_KEYS = [
    "window",
    "total_requests",
    "failed_requests",
    "failure_rate_pct",
    "provider_owned_failures",
    "customer_owned_failures",
    "recovered_by_retry",
    "unrecovered_failures",
    "root_cause",
    "action",
]


def parse_incident_json(raw: str) -> dict:
    payload = json.loads(raw)
    if list(payload) != REQUIRED_KEYS:
        raise ValueError("unexpected schema or key order")
    if payload["failed_requests"] != 84:
        raise ValueError("failed request count mismatch")
    return payload

Этот код проверяет три независимых свойства:

1. ответ действительно разбирается как JSON;
2. схема и порядок ключей соответствуют ожидаемому контракту;
3. одно из критических значений совпадает с эталоном.

Один system prompt не гарантирует структурированный вывод. В рабочей системе безопаснее использовать поддерживаемые поставщиком параметры структурированного ответа, выполнять локальную проверку schema и предусматривать повторный запрос либо переключение модели после ошибки разбора.

Как воспроизвести сравнение через один API

Ниже приведен минимальный исполняемый пример для OpenAI-compatible chat completions endpoint. К самому API endpoint UTM-параметры не добавляются.

import os
import requests

BASE_URL = "https://cn.crazyrouter.com/v1"
API_KEY = os.environ["CRAZYROUTER_API_KEY"]


def ask(model: str, prompt: str, max_tokens: int = 4000) -> dict:
    response = requests.post(
        f"{BASE_URL}/chat/completions",
        headers={
            "Authorization": f"Bearer {API_KEY}",
            "Content-Type": "application/json",
        },
        json={
            "model": model,
            "messages": [
                {"role": "system", "content": "Answer accurately and follow every requested constraint."},
                {"role": "user", "content": prompt},
            ],
            "temperature": 0.2,
            "max_tokens": max_tokens,
        },
        timeout=600,
    )
    response.raise_for_status()
    return response.json()


for model in ("claude-opus-5", "gpt-5.6-sol"):
    result = ask(model, "Your benchmark prompt here")
    choice = result["choices"][0]
    print(model, choice.get("finish_reason"), choice["message"].get("content", ""))

Для воспроизводимого теста недостаточно сохранить только видимый текст ответа. На каждом запуске также следует записывать:

• точный model ID;
• response ID;
• returned model;
• исходный prompt;
• temperature;
• max_tokens;
• finish_reason;
• необработанное содержимое ответа;
• результат локальной проверки;
• версию тестового набора.

Текущую доступность моделей можно проверить в списке моделей Crazyrouter, после чего запустить небольшой регрессионный набор на собственных рабочих запросах.

Рекомендации для рабочих систем

Где обе модели остаются подходящими кандидатами

Обе модели имеет смысл тестировать в сценариях, где:

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

Когда по результатам этого теста разумно сначала проверить GPT-5.6-SOL

GPT-5.6-SOL в этом наборе показал более полную доставку результата, если:

• каждый подпункт должен быть выполнен в одном ответе;
• тело ответа обязано содержать только JSON;
• нежелательно извлекать структурированные данные из пояснений или Markdown;
• нарушение формата должно быть редким уже на первом запросе.

Это вывод только по текущему набору: полное выполнение составило 10/10, а строгий JSON с первой попытки — 1/1.

Какие защитные меры нужны при работе с Opus 5

Для Claude Opus 5 особенно важно:

• выделять достаточный max_tokens для длинных выводов;
• всегда проверять finish_reason;
• разбирать JSON до передачи результата последующим компонентам;
• отклонять ответы с дополнительным Markdown или пояснениями;
• предусматривать повторную генерацию либо переключение модели;
• отдельно проверять наличие каждого обязательного подпункта.

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

Дополнительное сравнение поведения моделей Claude доступно в материале Claude Opus 5 против Claude Fable 5: тест реального API.

FAQ

Claude Opus 5 или GPT-5.6-SOL — какая модель умнее?

По этому набору нельзя обоснованно назвать одну модель в целом более умной. На 10 объективно проверяемых задачах обе получили 10/10 по правильности основных ответов.

Почему полное выполнение заданий не закончилось ничьей?

Ответ Opus на сложную задачу по вероятностям был оборван при max_tokens=3200 и завершился с finish_reason=length. Число 12.6547 и уравнения были правильными, но последнее требуемое объяснение отсутствовало. Поэтому Opus получил 9/10 по полной доставке, а GPT-5.6-SOL — 10/10.

Почему обрыв ответа не считается ошибкой основного рассуждения?

Потому что основной математический результат был получен правильно. Однако задача содержала дополнительное требование, которое не было выполнено. Правильность рассуждений и полнота ответа — разные показатели.

Следует ли считать нарушение строгого JSON ошибкой интеллекта?

Не как математическую ошибку. Opus правильно вычислил поля и значения, но нарушил требование к внешнему формату. Это следует учитывать как ошибку соблюдения инструкции и машинного контракта.

Что именно произошло при повторных попытках Opus с JSON?

С первой попытки Opus добавил ограждение блока кода и Verification. В первой дополнительной попытке после компактного JSON снова появился Verification. Во второй дополнительной попытке модель вновь добавила ограждение блока кода и пояснение. Таким образом, все три ответа не соответствовали требованию «ровно один JSON-объект без Markdown».

Как оценивались две задачи на программирование?

Код сохранялся в файлы Python и запускался на одинаковых скрытых тестах. Проверялись граничные условия, правила сортировки, некорректные входные данные и неизменность входных объектов. Обе модели прошли обе задачи — 2/2.

Почему в сравнении нет победителя по скорости?

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

Достаточно ли 10 задач для долгосрочного выбора модели?

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

Как начать собственное сравнение?

Выберите 10–30 реальных рабочих запросов и заранее задайте для каждого машинно проверяемые критерии. Затем отправляйте обеим моделям одинаковые входные данные с одинаковыми параметрами и сохраняйте необработанные ответы вместе с finish_reason. Критерии необходимо определить до просмотра результатов.

Что важнее для backend-системы: точность или формат?

Оба свойства важны, но проверять их нужно отдельно. Правильный ответ в неразбираемом формате может быть бесполезен для конвейера. И наоборот, синтаксически корректный JSON не гарантирует правильность значений. Надежная система проверяет и содержание, и контракт ответа.

Итоговый вывод

Главный результат этого сравнения — не безусловная победа одной модели, а четкое разделение двух аспектов качества:

Claude Opus 5 и GPT-5.6-SOL получили по 10/10 за правильность основных ответов. GPT-5.6-SOL полнее выполнил все подпункты — 10/10 против 9/10 — и с первой попытки соблюл строгий JSON: 1/1 против 0/1. Opus сохранил правильность рассуждений, но потребовал более строгого контроля бюджета вывода и формата.

Если задачу можно проверять по эталонному ответу или скрытым тестам, обе модели заслуживают включения в список кандидатов. Если последующие компоненты напрямую потребляют JSON, локальная проверка, контроль finish_reason, повторные запросы и переключение модели должны рассматриваться как обязательная часть архитектуры.

Создать учетную запись Crazyrouter и запустить собственное сравнение Opus 5 и GPT-5.6-SOL

Comments

[Luis Cruz]

Результаты этого сравнения между Claude Opus 5 и GPT-5.6-SOL показывают интересную картину, где обе модели демонстрируют высокую точность основных ответов, но различаются по полноте и соблюдению формата ответа. В частности, тот факт, что GPT-5.6-SOL лучше соблюдает строгий JSON и выполняет все подпункты заданий, поднимает вопрос о важности не только правильности ответов, но и точности форматирования и полноты информации в контексте задач, требующих严ого формата. Это подчеркивает необходимость учитывать несколько критериев при оценке моделей, включая не только точность, но и способность следовать конкретным форматам и требованиям. Какие еще факторы, по вашему мнению, следует учитывать при сравнении моделей языка, помимо точности и соблюдения формата?