Technical Context
No veo este mini-benchmark como una competencia de «quién es más inteligente», sino como una señal sobre el perfil de comportamiento de los modelos en una tarea real de extracción de datos. En el caso discutido, Claude Code con Opus 4.6 «trabajó duro» durante unas 8 horas y devolvió 319 objetos, todos bien elaborados. Codex 5.3 (Extra High) funcionó durante unos 20 minutos (más ~10 minutos tras una solicitud explícita de reintento) y entregó 16 objetos. La diferencia no es porcentual: son clases de resultados diferentes.
Como arquitecto, me llama la atención que tales discrepancias suelen nacer de tres factores técnicos: (1) ventana de contexto y estrategia para entradas largas, (2) planificación y descomposición (incluyendo verificaciones de múltiples pasos), y (3) agencia: la capacidad de organizar «recolección → normalización → deduplicación → validación» como un pipeline, y no como una respuesta única.
En las comparaciones públicas, a menudo se asocia a Opus 4.6 con un contexto muy grande (hasta 1M de tokens) y modos de «esfuerzo/profundidad», así como con trabajo de equipo agéntico (subtareas paralelas). En mis proyectos, esto casi siempre significa lo siguiente: el modelo no solo escribe el código del parser, sino que mantiene el esquema de datos en su cabeza, recuerda excepciones, acumula cuidadosamente resultados parciales y, lo más importante, gestiona pacientemente los casos marginales (long tail).
Codex 5.3, a juzgar por las descripciones y su estilo de trabajo, está optimizado para la iteración y ejecución rápida: escribir, ejecutar, corregir, ejecutar de nuevo. Este es el perfil ideal para «agentic coding» en la terminal, pero en tareas donde el objetivo es la máxima integridad de extracción, puede «cortar esquinas»: parada temprana, interpretación estrecha de condiciones, omisión de ramas raras. Una señal de alarma separada de la discusión: la tesis de que a veces es más conveniente usar Codex «a través de su app», mientras que la API podría no seguir el paradigma chat-completion. Para mí, esto no es filosofía, sino un riesgo práctico de integración: cambia la forma de orquestación, el registro (logging), la repetibilidad y el control del contexto.
Business & Automation Impact
Si estoy desarrollando automatización con IA en torno al parsing/extracción de entidades (catálogos, licitaciones, listas de precios, contrapartes, fichas de objetos, especificaciones), el negocio no paga por la «velocidad de respuesta del modelo». El negocio paga por la integridad, la estabilidad del esquema, la reproducibilidad y el costo del control de calidad. En este benchmark, Codex básicamente dio la señal: «Traje una demo rápido». Opus dio la señal: «Realmente miné la base de datos».
¿Quién gana con el enfoque Opus? Equipos donde los datos son un activo: analítica, monitoreo de mercado, cumplimiento (compliance), scoring de riesgo, inteligencia competitiva, compras. Allí, los objetos perdidos no son un «bueno, da igual», sino un sesgo en los KPI: lista de proveedores incompleta, posiciones omitidas, correspondencias de nomenclatura incorrectas. En tales sistemas, casi siempre diseño el circuito para que el modelo trabaje en profundidad, y la velocidad se compense con paralelismo y ejecuciones incrementales (no reconstruir todo cada vez).
¿Quién gana con Codex? Equipos de producto e ingeniería que necesitan «ajustar el pipeline» rápidamente: generar un parser, escribir tests, desplegar un worker, conectar un proxy, ponerlo en un contenedor, arreglar el CI. Codex es conveniente como «multiplicador de fuerza», especialmente cuando el desarrollador permanece en el circuito verificando resultados. Pero si se le da el rol de «extractor de la verdad», sin una capa fuerte de validación, el negocio comenzará a vivir sobre un dataset lleno de agujeros.
En la práctica de Nahornyi AI Lab, divido las tareas en dos presupuestos: presupuesto de cómputo y presupuesto de confianza. Opus suele ser más caro en cómputo (tiempo/tokens), pero más barato en confianza: menos revisión manual, menos momentos de «no sé a dónde fue el 90% de los objetos». Codex es más barato en cómputo, pero puede ser más caro en confianza: habrá que construir un sistema de control más rígido: métricas de cobertura, deduplicación, control de distribuciones, reintentos y auditorías manuales aleatorias.
Strategic Vision & Deep Dive
Mi conclusión no obvia de esta comparación: en 2026, la «elección del modelo» ya no trata sobre la calidad del texto ni siquiera sobre la calidad del código. Trata sobre la arquitectura de soluciones de IA como una línea de producción. Cada vez diseño más un híbrido: Codex como ingeniero rápido (construye/arregla herramientas, scripts, tests, infraestructura) y Opus como minero y normalizador de datos (hace el trabajo semántico pesado donde importan la integridad y la precisión).
Si necesito «hacer automatización con IA» para parsing, establezco varios niveles de defensa contra los fallos típicos de los modelos rápidos:
- Contrato de esquema: Descripción rígida de campos, tipos y reglas de normalización + autoverificaciones.
- Métricas de integridad: Control de cantidad de entidades por fuente/página/categoría y alertas ante caídas.
- Estrategia de dos pasadas: Primera pasada para recolección, segunda para validación y recuperación de remanentes (aquí es donde Opus suele amortizarse).
- Trazabilidad: Para cada objeto guardo una «prueba» (URL/fragmento/captura) y la razón de la extracción.
Aparte sobre paradigmas de API. Si un modelo/plataforma está más orientado a text-completion y escenarios de terminal, planeo una capa adaptadora de antemano: cómo pasar el contexto, cómo almacenar el estado intermedio, cómo hacer cancelación/continuación, cómo protocolizar «por qué el modelo decidió detenerse». Es ingeniería aburrida, pero es exactamente lo que distingue un piloto de una implementación de inteligencia artificial industrial.
No veo sentido en declarar un ganador «en general». En esta prueba ganó Opus, porque el KPI era sobre la recolección integral de datos. Pero en el negocio real, el KPI casi siempre es doble: integridad + tiempo de puesta en producción. Y aquí gana quien construye el stack correcto: un agente rápido para desarrollo y operaciones, un agente profundo para minería y control de calidad. El hype termina en la primera conciliación con contabilidad, CRM o BI: ahí sale a la luz que «16 objetos» no es un MVP, sino un error en la asignación del rol del modelo.
Si lo desea, analizaré su caso (fuentes, integridad requerida, SLA, presupuesto de control de calidad) y propondré una arquitectura de IA objetivo: dónde encaja Codex, dónde se necesita Opus y cómo vincularlos en un solo pipeline. Escriba a Nahornyi AI Lab; la consulta la realizaré yo personalmente, Vadym Nahornyi.