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.