GPT-5.5 low vs medium vs high vs xhigh: la curva de razonamiento en 26 tareas reales de un repositorio open source

 (reddit.com)
5 puntos por GN⁺ 8 시간 전 | 1 comentarios | Compartir por WhatsApp
  • Al ejecutar GPT-5.5 Codex en 26 tareas reales de GraphQL-go-tools con ajustes low, medium, high, xhigh, las diferencias en esfuerzo de razonamiento se hicieron notar más en la equivalencia semántica con el parche humano y en la tasa de aprobación en code review que en el simple pase de tests
  • El pase de tests fue low 21/26, medium 21/26, high 25/26, xhigh 24/26, pero la equivalencia semántica subió de 4/26 → 11/26 → 18/26 → 23/26 y la aprobación en code review también aumentó de 3/26 → 5/26 → 10/26 → 18/26
  • high mejoró frente a medium en pase de tests, equivalencia y aprobación en review, mientras que el costo promedio subió de $3.13 a $4.49, un aumento de 1.43x, por lo que parece la configuración predeterminada más práctica en este dataset
  • xhigh elevó mucho la equivalencia y la calidad de review por encima de high, pero el costo promedio aumentó a $9.77 y el tiempo promedio de ejecución a 753.3 segundos, además de generar más cambios en tests, fixtures y expected output, lo que también incrementó el riesgo de footprint
  • El efecto del esfuerzo de razonamiento no fue monótono según la tarea: a veces high superó a xhigh, o una configuración más alta produjo implementaciones plausibles pero incorrectas, por lo que el equipo debe medirlo en su propio harness y sus propias tareas, no en benchmarks globales

Objetivo del experimento y método de evaluación

  • Se ejecutó GPT-5.5 Codex sobre las mismas 26 tareas de un repositorio open source con ajustes de esfuerzo de razonamiento low, medium, high, xhigh para comparar no solo el pase de tests, sino también la equivalencia semántica con PRs fusionados por humanos y la posibilidad de pasar code review
  • El repositorio evaluado es GraphQL-go-tools, basado en Go, y cada tarea deriva de un PR o commit real ya fusionado
  • Cada tarea consiste en un snapshot fijo del repositorio, un prompt de solicitud de cambio y un solo intento de generar un parche dentro de un contenedor Docker
  • Stet aplica el parche generado y ejecuta los tests correspondientes de cada tarea en un contenedor aislado para verificar si pasan
  • Después de los tests, también se evaluó con los siguientes criterios
    • Equivalencia: si el parche candidato logra el mismo cambio de comportamiento que el parche original hecho por una persona
    • Aprobación en code review: si un reviewer lo aceptaría considerando corrección, riesgo de introducir bugs, mantenibilidad y edge cases
    • Riesgo de footprint: cuánto código adicional tocó el agente frente al parche humano
    • Rúbrica de elaboración/disciplina: evalúa claridad, simplicidad, consistencia, intencionalidad, robustez, cumplimiento de instrucciones, disciplina de alcance y minimización del diff
  • Todos los modelos se ejecutaron una vez por tarea, con una sola semilla
  • El modelo LLM juez fue GPT-5.4, y el evaluador solo veía el parche y la tarea, no qué modelo o ajuste de razonamiento había producido el parche
  • Los ejemplos representativos también se revisaron manualmente, pero como no hubo una calibración humana separada para este conjunto de tareas, conviene confiar más en la dirección del cambio que en un puntaje absoluto aislado
  • Detalles de la ejecución
    • Modelo: GPT-5.5
    • Harness: Codex 0.128.0
    • Dataset: 26 tareas reales de GraphQL-go-tools
    • Métricas principales: pase de tests, equivalencia semántica, aprobación en code review, riesgo de footprint, evaluación personalizada de elaboración/disciplina, costo y tiempo de ejecución
  • Los gráficos interactivos y el análisis detallado por tarea están en https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve
  • La misma evaluación también se usa en un ciclo de investigación automatizado para mejorar AGENTS.md
    • El agente crea propuestas de mejora para AGENTS.md del repositorio, ejecuta tareas pasadas con Stet y luego itera identificando dónde mejoró o empeoró

Métricas globales e interpretación

  • Las métricas globales muestran que, a medida que aumenta el esfuerzo de razonamiento, las diferencias se ven más en la equivalencia semántica y la tasa de aprobación en review que en el pase de tests
  • Resultados clave
    • Pase de tests: low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • Equivalencia con el parche humano: low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • Aprobación en code review: low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • Promedio de elaboración/disciplina: low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • Costo promedio por tarea: low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • Tiempo promedio de ejecución del agente: low 286.9 segundos, medium 411.0 segundos, high 579.0 segundos, xhigh 753.3 segundos
  • low y medium empatan con 21/26 en pase de tests, pero la equivalencia sube de 4/26 a 11/26 y la aprobación en review de 3/26 a 5/26
  • Frente a medium, high aumentó el pase de tests en +15.4 pp, la equivalencia en +26.9 pp y la aprobación en review en +19.2 pp, mostrando la mejora práctica más clara
  • Frente a high, xhigh bajó -3.8 pp en pase de tests, pero subió +19.2 pp en equivalencia y +30.8 pp en aprobación en review
  • El esfuerzo de razonamiento no solo cambia la tasa de pase de tests: parece cambiar también el tipo de parche que produce Codex
  • Los benchmarks públicos suelen responder si una tarea se resolvió o no en términos binarios, pero en ingeniería de software real también importa si el parche puede fusionarse y mantenerse después
  • Terminal-Bench se centra sobre todo en problemas de programación complejos, SWE-bench verified puede incluir casos donde el modelo ya conocía la respuesta, y SWE-bench Pro es útil pero de carácter más general
  • El foco de este experimento está en si “el agente hizo en mi codebase el mismo tipo de cambio que fusionó una persona” y si “realmente querría hacerme cargo de este parche después”

De low a medium: pasar de heurísticas a modelado de dominio

  • low y medium empatan en pase de tests con 21/26, así que si solo se miran los tests parece un empate
  • Pero medium sube en equivalencia semántica de 4/26 a 11/26, y el promedio de elaboración/disciplina también pasa de 2.311 a 2.604
  • En este tramo, si solo se miden los tests, se pierde la mayor parte de la diferencia en esfuerzo de razonamiento
  • En low, incluso los parches que pasan pueden quedarse en heurísticas o implementaciones parciales; medium, en cambio, se mueve hacia un mejor modelado del repositorio y de la semántica del dominio
  • Ejemplo del PR #1297
    • Es una tarea para validar dependencias @requires externas y anulables en GraphQL Federation
    • Si un campo requerido y anulable regresa null junto con un error, esa entidad contaminada no debe pasarse a un fetch downstream que depende de ella
    • La esencia de la tarea no era solo agregar una rama de validación, sino modelar una regla sutil de dependencia de datos en federation
    • low pasó los tests, pero manejó la coincidencia entre required-field y error con una heurística, omitió la metadata estructurada de @requires anulable, no fue equivalente y tampoco pasó review
    • medium rastreó los objetos contaminados y filtró las entradas del fetch downstream, con lo que sí pasó equivalencia y review, y la calidad de elaboración/disciplina subió de 1.350 a 3.225
    • Como high y xhigh se mantuvieron en una banda de calidad similar, esta tarea muestra sobre todo la mejora al pasar de low a medium

high: un punto cercano al valor predeterminado práctico

  • high mejora frente a medium en pruebas superadas, equivalencia semántica y aprobación de revisión, mientras que el aumento de costo sigue siendo considerable pero no excesivo
  • Comparación entre high y medium
    • Pruebas superadas: sube de 21/26 a 25/26
    • Equivalencia: sube de 11/26 a 18/26
    • Aprobación de revisión de código: sube de 5/26 a 10/26
    • Riesgo de huella promedio: sube de 0.268 a 0.314
    • Promedio de construcción/disciplina: sube de 2.604 a 2.736
    • Costo promedio por tarea: sube de $3.13 a $4.49, 1.43 veces
    • Tiempo promedio de ejecución: sube de 411.0 segundos a 579.0 segundos
  • high parece ser el punto donde los tokens adicionales se convierten en ganancias reales, con una mayor tasa de aciertos en los detalles de integración
  • Ejemplo de PR #1209
    • Se trata de una tarea en la que el datasource de gRPC debe respetar el alias de GraphQL en el JSON de respuesta, validar por adelantado los tipos de mensaje protobuf referenciados y actualizar la cobertura de mapeo de la ruta de mutation de union/interface
    • low y medium superaron las pruebas, pero no fueron equivalentes y también fallaron la revisión
    • medium resolvió en gran parte la serialización de alias y la validación de mensajes faltantes, pero omitió la actualización del mapeo de la mutation createUser y cargó a JSONPath con demasiada semántica de response-key
    • high introdujo un manejo explícito de response-key/alias y propagó el alias a través de la planificación y del JSON marshaling, logrando así el primer pase estricto
    • La calidad personalizada de high subió a 3.625, y no se trató solo de agregar más código, sino de acertar exactamente con las obligaciones de integración
    • xhigh también aprobó, pero no mejoró la interpretación a nivel de tarea, y el tiempo de ejecución del agente según el criterio de resumen regenerado fue de 790.7s, mayor que los 314.0s de high
  • Ejemplo de PR #1155
    • Es un trabajo de hardening del datasource de gRPC que incluye soporte para repeated scalar field, evitar pánicos por mensajes nulos o inválidos, propagación de gRPC status code, desactivación del datasource y soporte para dynamic client
    • low y medium superaron las pruebas, pero no fueron equivalentes
    • medium mejoró la robustez, pero serializó un repeated field inválido como un arreglo vacío, omitió el comportamiento de planificación de raíz con alias y dejó riesgos en el ciclo de vida del dynamic client
    • high superó equivalencia y revisión con un manejo más seguro de nil/inválidos, propagación de status code, comportamiento de datasource desactivado y cobertura del proveedor de dynamic client
    • En esta tarea, xhigh pasó las pruebas, pero se dio una inversión porque manejó mal la semántica de datasource desactivado y el comportamiento de lista inválida, por lo que no fue equivalente y también falló la revisión

xhigh: más cercano a un modo de calidad que al valor predeterminado

  • xhigh elevó la calidad semántica y de revisión frente a high, pero no es un caso donde simplemente subir la configuración haga que todo mejore
  • Comparación entre xhigh y high
    • Pruebas superadas: baja de 25/26 a 24/26
    • Equivalencia: sube de 18/26 a 23/26
    • Aprobación de revisión de código: sube de 10/26 a 18/26
    • Riesgo de huella promedio: sube de 0.314 a 0.365
    • Promedio de construcción/disciplina: sube de 2.736 a 3.071
    • Costo promedio por tarea: sube de $4.49 a $9.77, 2.18 veces
    • Tiempo promedio de ejecución: sube de 579.0 segundos a 753.3 segundos
  • xhigh tiende a cubrir más terreno, alinearse mejor con la intención humana y producir cambios más completos, pero usa muchísimos más tokens
  • La rúbrica de revisión arroja para xhigh un promedio de 3.365 y una mediana de 3.500, por encima del promedio de 2.817 y la mediana de 2.750 de high
  • La mediana también es más alta que el promedio, por lo que la mejora de xhigh no parece ser resultado de uno o dos parches sobresalientes que empujen el promedio hacia arriba
  • xhigh es semánticamente más completo, pero también aumenta el riesgo de huella al tocar más código que un parche hecho por humanos
  • En las 26 tareas, xhigh agregó un total de 13,144 líneas, divididas entre 5,918 líneas de código de implementación y 7,226 líneas de pruebas, fixtures y expected-output
  • En comparación con high, xhigh agregó 2,631 líneas más, de las cuales 2,436 están en archivos de pruebas, fixtures y expected-output
  • El aumento de huella no se debe solo a que haya escrito una enorme cantidad de production code; también influye mucho que xhigh haya generado más validación y cobertura de fixtures
  • Pero los cambios en pruebas, fixtures y expected-output también son una superficie real que hay que revisar y mantener
  • Ejemplo de PR #1076
    • Es una tarea de reestructuración del manejo de subscription para evitar una race condition de mutex compartido
    • Los requisitos incluyen escrituras serializadas por subscription, control de heartbeat por subscription, cobertura con race detector y corrección de la semántica de cierre de WebSocket
    • medium superó las pruebas, pero no fue equivalente y también falló la revisión
    • high logró equivalencia y cumplimiento de instrucciones, pero la nueva worker queue podía bloquear el event loop global de subscription, el shutdown podía quedar detenido detrás de un worker atascado, una actualización colgada podía quedar sin límite y el unsubscribe a nivel de cliente seguía omitiendo la subscription interna, por lo que falló la revisión
    • xhigh fue el primer pase estricto y elevó la calidad personalizada a 3.475
    • Este trabajo es el mejor ejemplo de cómo, en tareas cargadas de concurrencia, xhigh opera como un modo de calidad que compra una limpieza del riesgo de revisión
  • Ejemplo de PR #1308
    • Es una tarea para implementar el input object @oneOf de GraphQL
    • Se necesita agregar la directiva built-in, exponerla en introspection, validar operation literal y runtime variable, y mejorar la source location de variables no definidas
    • medium y high superaron las pruebas, pero no fueron equivalentes y también fallaron la revisión porque omitieron semánticas importantes de @oneOf relacionadas con runtime variable, nullable variable, payload con null provisto e introspection shape
    • xhigh fue el primer pase estricto y registró robustez 3.7, cumplimiento de instrucciones 4.0 y calidad personalizada 3.525
    • La diferencia no está en un pulido superficial, sino en la cobertura de edge cases a través de varias partes del sistema
  • Ejemplo de PR #1240
    • Es una tarea para unificar el field-selection merging del AST de GraphQL y el inline-fragment selection merging en un solo normalization walk
    • low y high fueron pases estrictos
    • xhigh fue equivalente según el criterio de evaluación semántica, pero falló la revisión al mantener un prioritized subpass, cambiar el orden de AbstractFieldNormalizer y dejar un registro antiguo de field-merge
    • Incluso una configuración de razonamiento más alta puede producir refactorizaciones más sofisticadas y plausibles, pero pasar por alto el comportamiento de ejecución exacto que valoran las pruebas y los revisores

Elaboración·disciplina, costo, limitaciones y conclusión

  • La evaluación personalizada de elaboración·disciplina también sube en general a medida que aumenta el esfuerzo de razonamiento, de forma similar a la rúbrica de revisión
  • La puntuación de all-custom, con promedio de 3.071 y mediana de 3.087 en xhigh, es más alta que el promedio de 2.736 y la mediana de 2.688 en high
  • Como tanto la elaboración como la disciplina también tienen medianas más altas, se puede interpretar que xhigh no solo produjo algunos ejemplos sobresalientes, sino que elevó la calidad general de los parches
  • Métricas de promedio/mediana
    • Craft aggregate: low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Discipline aggregate: low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • All custom graders: low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • Interpretación detallada
    • low tiene debilidades en robustez y seguimiento de instrucciones
    • medium mejora esta parte de forma significativa incluso sin aumentar el total de pruebas aprobadas
    • high mejora la precisión y la robustez de forma sustancial
    • xhigh mejora casi todas las dimensiones, incluyendo alcance y disciplina del diff
  • Costo y tiempo
    • low: costo promedio $2.65, mediana $1.91, tiempo de ejecución promedio 286.9s, mediana 294.6s
    • medium: costo promedio $3.13, mediana $2.87, tiempo de ejecución promedio 411.0s, mediana 371.8s
    • high: costo promedio $4.49, mediana $3.99, tiempo de ejecución promedio 579.0s, mediana 572.9s
    • xhigh: costo promedio $9.77, mediana $6.39, tiempo de ejecución promedio 753.3s, mediana 732.7s
  • El costo está sesgado en low y especialmente en xhigh, y el costo promedio de xhigh está afectado por algunas tareas caras
  • Incluso por mediana, xhigh es más caro y más lento que high
  • high cuesta alrededor de 1.43 veces más por tarea que medium, y xhigh cuesta alrededor de 2.18 veces más que high
  • Limitaciones
    • Se usó una sola seed por tarea
    • Solo se incluyeron 26 tareas reales de GraphQL-go-tools
    • El juez LLM fue GPT-5.4, y ve los parches y las tareas, pero no las labels
    • No hubo calibración del grader para este conjunto de tareas
    • No puede considerarse un resultado universal estadísticamente significativo ni un resultado que se transfiera tal cual a otros repositorios
  • Comparaciones relacionadas
    • El leaderboard de tareas reales de Voratiq también apunta en una dirección similar, aunque con una metodología distinta
    • En Voratiq, GPT-5.5 xhigh tiene 1994 y GPT-5.5 high 1807, un aumento de +187 puntos y +10.3%
    • El costo es $4.23 frente a $2.52, o +67.9%, y el tiempo es 11.9m frente a 7.8m, o +52.6%
    • En el experimento de Stet, el paso de high → xhigh fue mayor, con equivalencia de +19.2%p, relativo de +27.8%, aprobación en code review de +30.8%p, relativo de +80.0%, mientras que el aggregate de elaboración/disciplina fue similar con +12.2%
    • Voratiq es un leaderboard estilo preferencia/selección sobre trabajo en curso, y este experimento es un slice de un solo repositorio con 26 tareas, así que no pueden compararse directamente
  • Conclusión práctica
    • xhigh es adecuado para tareas ambiguas, que abarcan varias áreas, centradas en concurrencia o con alto riesgo de revisión
    • high parece la configuración más práctica como opción predeterminada diaria en este dataset
    • Las configuraciones medium o inferiores son adecuadas cuando el costo importa más y la tarea es rutinaria o está bien definida
    • El efecto del esfuerzo de razonamiento no es uniforme ni monótono según la tarea, y también hay casos inversos en los que high supera a xhigh o una configuración más alta produce una implementación plausible pero incorrecta
    • En lugar de copiar valores predeterminados de benchmarks globales, los equipos deberían medir con su propio harness y sus propias tareas
  • Divulgación
    • Están creando Stet.sh y ejecutaron el experimento con esta herramienta de evaluación local
    • En la versión del producto, el agente de coding genera cambios candidatos como mejoras a AGENTS.md, y los evalúa con Stet sobre tareas históricas del repositorio
    • Si un equipo que usa mucho agentes de coding está por tomar decisiones concretas como high vs xhigh, Codex vs Claude Code, actualizaciones de AGENTS.md o qué tareas es seguro delegar, están buscando equipos con los que ejecutar pruebas por repositorio
    • Stet corre completamente en local usando suscripciones de LLM, y la lista de espera está en https://www.stet.sh/private

Lecturas relacionadas

1 comentarios

 
GN⁺ 8 시간 전
Opiniones en Hacker News
  • Esta comparación está buena y también me gustaría ver una comparación con 5.4
    Hasta ahora, por cómo se siente en uso real, 5.5 no vale el costo extra. 5.4-high lo hace mejor que la mayoría de los niveles de razonamiento de 5.5, cuesta la mitad y además tarda mucho menos en la práctica. 5.5-medium no logró completar las tareas, y 5.5-high sobrearquitecturó y creó bugs y regresiones
  • Para la mayoría del trabajo serio, high parece ser el punto adecuado
    Más arriba que eso, la mejora que se obtiene se acerca a rendimientos decrecientes frente al costo
  • En una cuenta Pro estoy usando 5.5 xHigh Codex Terminal CLI como lead principal y Codex Desktop App 5.5 xhigh como lead de apoyo
    A ambos les doy acceso total, peligrosamente amplio, y trabajan sobre el mismo proyecto. A cada uno le cuelgo en promedio 6 subagentes 5.5, y el CLI o la app decide qué nivel de subagentes usar. Sale mezclado, pero el CLI por lo general asigna 5.5 Medium
    El CLI tiene privilegios de administrador y solo el CLI se encarga de cosas como GitHub, Supabase, Vercel, Clerk, Linear y Symphony, además de push, merge, PR y deploy. Yo hago 0 trabajo directo y también 0 issues P0/P1/P2. GitHub, Vercel y Supabase están todos en verde, no hay issues, el código y el producto están limpios, y el frontend sale sorprendentemente bien con una sola imagen de referencia
    La desventaja es que puede quemarse 30% del límite semanal en un solo día
    • Viendo este experimento probé xhigh en algunas tareas y fue bastante efectivo, pero se devora los tokens como loco
      Ahora volví a high
  • Mi mayor queja sobre 5.5 xhigh es que simplemente avanza por su cuenta sin siquiera preguntar
    Aun así, siento que me ahorró varios años de vida y una cantidad considerable de tokens
    • Uso principalmente high y se comporta igual
      Sigo buscando qué frase poner en agents.md para que no haga suposiciones por su cuenta. A veces le hago una pregunta porque necesita averiguar más antes de darle instrucciones de programación sobre algo, y en vez de responder se pone a programar de una vez. Al final sí incluye en la respuesta la contestación a la pregunta, así que parece haber prestado atención a lo que dije, pero no entendió que si había una pregunta eso significaba que todavía no debía empezar a programar
  • Me pregunto si lo ejecutaste varias veces sobre el mismo PR
    Me gustaría saber qué tanta variabilidad hay entre ejecuciones del modelo. Incluso si en el caso de arriba high programó mejor, si la variabilidad entre ejecuciones es grande quizá siga conviniendo usar xhigh
    También como experimento, después de cada ejecución podrías darle retroalimentación sobre el resultado del trabajo, hacer que actualice AGENTS.md, skills, rules, etc. comparándolo con lo que corrigió una persona, y luego volver a correrlo en una sesión nueva con high/xhigh. Si repites eso unas cuantas veces para mejorar y después vuelves a probar en todos los niveles de esfuerzo, parece posible subir la calidad general de salida ajustando bien AGENTS.md y las skills/rules
    • No ejecuté cada variante varias veces. La razón principal es el costo y las limitaciones de tokens. Mi billetera no es infinita, pero como estudio de seguimiento es una muy buena idea
      La optimización de AGENTS.md me gusta mucho, y de hecho hice que Stet, que construí para correr experimentos, hiciera justamente eso. Corre Codex en algunas tareas, observa las puntuaciones y los patrones de falla, hace que modifique AGENTS.md y luego lo vuelve a ejecutar, todo de forma autónoma. Funciona como una investigación automática para AGENTS.md, y es bastante interesante ver cómo vuelve con mejoras basadas en datos incorporadas en AGENTS.md
  • Ahora también necesitamos un índice CPI para la inflación de precios. Se siente como si el CPI mensual fuera casi 100%