Technical Context
Я смотрю на этот мини-бенчмарк не как на «кто умнее», а как на сигнал о поведенческом профиле моделей в реальной задаче извлечения данных. В кейсе из обсуждения Claude Code с Opus 4.6 «пыхтел» около 8 часов и вернул 319 объектов, причём с хорошей проработкой. Codex 5.3 (Extra High) отработал около 20 минут (и ещё ~10 минут после явного повторного запроса) и выдал 16 объектов. Разница не в процентах — это разные классы результата.
Как архитектору мне бросается в глаза, что такие расхождения обычно рождаются из трёх технических факторов: (1) контекстное окно и стратегия работы с длинным входом, (2) планирование и декомпозиция (включая многошаговые проверки), (3) агентность — умение организовать «сбор → нормализацию → дедупликацию → валидацию» как конвейер, а не как одноразовый ответ.
В публичных сравнениях Opus 4.6 часто связывают с очень большим контекстом (до 1M токенов) и режимами «усилия/глубины» (несколько уровней), а также с командной агентной работой (параллельные подзадачи). В моих проектах это почти всегда означает следующее: модель не просто пишет код парсера, а держит в голове схему данных, помнит исключения, аккуратно накапливает частичные результаты и, главное, терпеливо доводит хвосты.
Codex 5.3, судя по описаниям и стилю работы, заточен под быструю итерацию и исполнение: написал, запустил, поправил, снова запустил. Это идеальный профиль для «agentic coding» в терминале, но в задачах, где цель — максимальная полнота извлечения, он может «срезать углы»: ранняя остановка, узкая трактовка условия, пропуск редких веток. Отдельный тревожный маркер из обсуждения: тезис, что Codex иногда удобнее использовать «через их аппку», а API может быть не chat-completion-парадигмой. Для меня это не философия, а практический риск интеграции: меняется способ оркестрации, логирование, повторяемость и контроль контекста.
Business & Automation Impact
Если я делаю ИИ автоматизацию вокруг парсинга/извлечения сущностей (каталоги, тендеры, прайсы, контрагенты, карточки объектов, спецификации), то бизнес платит не за «скорость ответа модели». Бизнес платит за полноту, стабильность схемы, воспроизводимость и стоимость контроля качества. В этом бенчмарке Codex фактически дал сигнал: «Я быстро принёс демо». Opus дал сигнал: «Я реально накопал базу».
Кто выигрывает от Opus-подхода? Команды, где данные — это актив: аналитика, мониторинг рынка, комплаенс, риск-скоринг, конкурентная разведка, снабжение. Там потерянные объекты — это не «ну ладно», а перекос KPI: неполный список поставщиков, пропущенные позиции, неправильные соответствия номенклатуры. В таких системах я почти всегда проектирую контур так, чтобы модель работала глубоко, а скорость компенсировалась параллелизмом и инкрементальными прогонов (не пересобирать всё каждый раз).
Кто выигрывает от Codex? Продуктовые и инженерные команды, которым нужно быстро «докрутить пайплайн»: сгенерировать парсер, написать тесты, развернуть воркер, подключить прокси, уложить в контейнер, починить CI. Codex удобен как «ускоритель рук», особенно когда разработчик остаётся в контуре и проверяет результаты. Но если дать ему роль «экстрактора правды», без сильного слоя валидации, бизнес начнёт жить на дырявом датасете.
В практике Nahornyi AI Lab я разделяю задачи на два бюджета: бюджет вычисления и бюджет доверия. Opus обычно дороже по вычислению (время/токены), зато дешевле по доверию: меньше ручной проверки, меньше «непонятно куда делись 90% объектов». Codex дешевле по вычислению, но может быть дороже по доверию: придётся строить более жёсткую систему контроля — метрики покрытия, дедупликация, контроль распределений, повторные прогоны, выборочные ручные аудиты.
Strategic Vision & Deep Dive
Мой неочевидный вывод из этого сравнения: в 2026 году «выбор модели» — это уже не про качество текста и даже не про качество кода. Это про архитектуру ИИ-решений как производственного конвейера. Я всё чаще проектирую гибрид: Codex как быстрый инженер (строит/чинит инструменты, скрипты, тесты, инфраструктуру) и Opus как добытчик и нормализатор данных (делает тяжёлую семантическую работу, где важна полнота и аккуратность).
Если мне нужно «сделать ИИ автоматизацию» для парсинга, я закладываю несколько уровней защиты от типичных провалов быстрых моделей:
- Контракт схемы: жёсткое описание полей, типов и правил нормализации + автопроверки.
- Метрики полноты: контроль количества сущностей по источникам/страницам/категориям и алерты на просадки.
- Двухпроходная стратегия: первый проход — сбор, второй — валидация и добор хвостов (и это место, где Opus часто окупается).
- Трассируемость: для каждого объекта сохраняю «доказательство» (URL/фрагмент/снимок) и причину извлечения.
Отдельно про API-парадигмы. Если модель/платформа сильнее ориентирована на text-completion и терминальные сценарии, я заранее продумываю слой-адаптер: как передавать контекст, как хранить промежуточное состояние, как делать отмену/продолжение, как протоколировать «почему модель решила остановиться». Это скучная инженерия, но именно она отличает пилот от промышленного внедрения искусственного интеллекта.
Я не вижу смысла объявлять победителя «в целом». В этом тесте победил Opus — потому что KPI был про комплексный сбор данных. Но в реальном бизнесе KPI почти всегда двойной: полнота + срок вывода в прод. И здесь выигрывает тот, кто строит правильный стек: быстрый агент для разработки и эксплуатации, глубокий агент для добычи и контроля качества. Хайп заканчивается на первой сверке с бухгалтерией, CRM или BI — там всплывает, что «16 объектов» это не MVP, а ошибка постановки роли модели.
Если вы хотите, я разберу ваш кейс (источники, требуемую полноту, SLA, бюджет на контроль качества) и предложу целевую AI-архитектуру: где уместен Codex, где нужен Opus, и как связать их в один конвейер. Напишите в Nahornyi AI Lab — консультацию проведу лично я, Vadym Nahornyi.