Anthropic lanzó Claude Sonnet 5.5 el 28 de septiembre a 2 $ por millón de tokens de entrada y 10 $ por millón de salida. OpenAI lanzó GPT-6 Sol el 22 de septiembre con esas mismas tarifas de 2 $ y 10 $. Con solo seis días de diferencia y un precio de lista idéntico, ambos modelos se sitúan un escalón por debajo del buque insignia de sus respectivos laboratorios. Para un equipo que busca elegir el modelo predeterminado para agentes de programación, el precio no resuelve nada. La verdadera decisión está entre Claude Code o Codex como el Runtime que envuelve a cada modelo, y lo que cuesta cada combinación por tarea completada.
Una prueba honesta implica dos Runtimes, dos configuraciones, dos conjuntos de resultados y una persona a cargo de la revisión intentando recordar qué terminal generó cada diff. Elegir el modelo es un ajuste de una sola línea. Comparar ambos es el caos de los agentes en miniatura.
TL;DR
Claude Sonnet 5.5 y GPT-6 Sol cuestan lo mismo por token y se diferencian en el Runtime en el que los equipos suelen ejecutarlos: Claude Code para Sonnet 5.5 y Codex para Sol. La tabla de lanzamiento de Anthropic incluye cuatro filas con una columna para GPT-6 Sol. Sonnet 5.5 lidera claramente en tres de ellas; la cuarta, FrontierCode, depende del nivel de esfuerzo. El coste por tarea cambia según el benchmark: en FrontierCode, Sonnet 5.5 iguala el mejor resultado de Sol por cerca de una quinta parte de su coste; en AA-Briefcase, el mejor resultado de Sol cuesta 2,67 $ por tarea, frente a los 29,19 $ de Sonnet 5.5. No obstante, se trata de la tabla de un único proveedor. Resuelve el dilema entre Sonnet 5.5 y GPT-6 Sol ejecutando la misma Task en ambos Runtimes sobre tu propio código y contabilizando los minutos de revisión por cada cambio aceptado. Mantener ambos es una respuesta legítima, siempre que la Task se mantenga como el registro de referencia.
Qué permiten comparar realmente las cifras publicadas
Cuatro filas. La publicación de lanzamiento de Claude Sonnet 5.5 compara Sonnet 5.5, Sonnet 5, Opus 5.5 y GPT-6 Sol, y solo estas filas incluyen datos para Sol:
| Fila en la tabla de Anthropic | Ejecutado por | Sonnet 5.5 | GPT-6 Sol |
|---|---|---|---|
| FrontierCode 1.1 (Main) | Cognition: modelos Claude en Claude Code, modelos GPT en Codex CLI | 46,2 % en max, 52,1 % en xhigh | 49,3 % |
| GDPval-AA v2.1 | Artificial Analysis | 1844 | 1487 |
| AA-Briefcase v1.1 | Artificial Analysis | 1811 | 1483 |
| Chartography, sin herramientas | Benchmark de Surge AI; Sonnet 5.5 evaluado por Anthropic, Sol según lo publicado por Surge AI | 61,6 % | 53,6 % |
Esta es la tabla de un único proveedor. El artículo de OpenAI sobre Sol se publicó seis días antes de que existiera Sonnet 5.5, por lo que la única tabla comparativa de un proveedor que incluye ambos modelos es la de Anthropic. Ambas columnas incluyen una advertencia por errores de software: las ejecuciones de Sonnet 5.5 en Artificial Analysis utilizaron un despliegue previo al lanzamiento con un error en las salidas estructuradas (structured output), ya corregido, y OpenAI solucionó recientemente un fallo en la comprensión de imágenes en Sol que los resultados de Artificial Analysis y Surge AI podrían no reflejar.
La fila de FrontierCode es la que cualquier equipo de desarrollo debería analizar, ya que constituye de por sí una comparación entre Runtimes: ese 52,1 % frente al 49,3 % enfrenta a Claude Code con Sonnet 5.5 contra Codex CLI con Sol, la combinación que realmente se desplegaría en producción. La nota al pie sobre la puntuación en esfuerzo máximo (max) es igual de relevante: FrontierCode penaliza las modificaciones fuera del alcance de la tarea, y con el esfuerzo al máximo Sonnet 5.5 ejecutó con mayor frecuencia la habilidad de revisión de código de Claude Code, que se distribuye en múltiples subagentes. En dos casos analizados por Cognition, esto provocó que se agotara el tiempo de espera (timeout) o que se aplicaran ediciones fuera del alcance definido. A mayor esfuerzo, un diff más extenso y más tiempo de revisión.
No hay más cifras sobre Sol en el resto de la página. Los gráficos de esfuerzo para Terminal-Bench 4.0 y CursorBench 4.0 representan a GPT-5.6 Sol, ya que no se publicaron datos para GPT-6 Sol.
Existe un agregador independiente de terceros. A fecha de 29 de septiembre, Artificial Analysis sitúa el endpoint de Sonnet 5.5 en esfuerzo máximo con una puntuación de 56 en su Intelligence Index, en el tercer puesto entre 216 modelos. Por su parte, Sol se situaba en 48 el 23 de septiembre, cuando registramos los datos por última vez. Dos fechas distintas, un índice dinámico y ninguna de las dos cifras evalúa el comportamiento en tu propio repositorio.
Coste por tarea completada, no por token
Tener precios idénticos por token dice muy poco sobre la factura final, ya que los tokens consumidos por tarea dependen del modelo, del nivel de esfuerzo y del Runtime utilizado. La página de lanzamiento de Anthropic publica la puntuación y el coste por tarea según el nivel de esfuerzo para dos de las filas compartidas:
| Nivel de esfuerzo (Effort) | FrontierCode: Sonnet 5.5 | FrontierCode: GPT-6 Sol | AA-Briefcase: Sonnet 5.5 | AA-Briefcase: GPT-6 Sol |
|---|---|---|---|---|
| low | 29,3 %, 0,19 $ | 37,3 %, 0,43 $ | 1264, 0,87 $ | 905, 0,12 $ |
| medium | 36,5 %, 0,24 $ | 45,9 %, 0,77 $ | 1461, 1,64 $ | 1142, 0,34 $ |
| high | 49,4 %, 0,42 $ | 47,7 %, 1,04 $ | 1634, 3,95 $ | 1289, 0,63 $ |
| xhigh | 52,1 %, 1,59 $ | 48,4 %, 1,32 $ | 1746, 9,63 $ | 1364, 1,19 $ |
| max | 46,2 %, 20,78 $ | 49,3 %, 2,07 $ | 1811, 29,19 $ | 1483, 2,67 $ |
Analicemos primero FrontierCode. Sonnet 5.5 en esfuerzo high alcanza un 49,4 % por 0,42 $ por tarea, a la par del mejor resultado de Sol de 49,3 % a 2,07 $; el resumen de Anthropic señala que esto supone «alrededor de una quinta parte del coste por tarea». El detalle clave a tener en cuenta se encuentra más abajo: en medium, Sonnet 5.5 obtiene un 36,5 %, por debajo de Sol incluso en low, y medium es el nivel de esfuerzo predeterminado de Claude Code para Sonnet 5.5. La guía de prompting de Anthropic sugiere empezar en high, o en medium para programación agéntica en tareas bien delimitadas. El ajuste que nadie suele tocar puede ser el que incline la balanza en la comparativa.
AA-Briefcase, un benchmark de trabajo de conocimiento, muestra la tendencia opuesta. El mejor resultado de Sol cuesta 2,67 $ por tarea; el de Sonnet 5.5 cuesta 29,19 $, unas once veces más, aunque logrando una puntuación superior. La configuración de Sonnet 5.5 más próxima en coste al nivel max de Sol, medium a 1,64 $, alcanza 1461 puntos frente a 1483. Se trata de los dos mismos modelos, pero con una respuesta contraria sobre cuál resulta más económico para obtener el resultado deseado.
El almacenamiento en caché reduce esta brecha y cambia el equilibrio. Sonnet 5.5 lee las entradas cacheadas a 0,10 $ por millón, con escrituras en caché de 5 minutos a 2,50 $ (precios de Anthropic). GPT-6 descuenta un 90 % en las lecturas de entrada en caché, lo que equivale a 0,20 $ sobre una tarifa base de 2 $, por lo que una lectura en caché cuesta la mitad en Sonnet 5.5. La diferencia radica en qué invalida la caché: OpenAI afirma que modificar el esfuerzo de razonamiento o la disponibilidad de herramientas ya no la invalida, mientras que la guía de prompting de Sonnet 5.5 de Anthropic advierte que cambiar el esfuerzo general entre peticiones sí lo hace, y sugiere recurrir a un ajuste beta de esfuerzo por mensaje. Los agentes que cambien el esfuerzo a mitad de una tarea lo verán reflejado en la factura.
Ninguna de estas cifras representa tu coste por cambio aceptado. Una ejecución económica que requiera dos reintentos y una revisión exhaustiva termina siendo la más cara.
Cómo decidir con tu propia base de código
Ejecuta la misma Task en ambos Runtimes y contabiliza el tiempo que invierte una persona en aceptar el resultado. Los criterios se detallan en cómo comparar agentes de programación en tu propia base de código; a continuación se describe la configuración para esta comparativa.
Sharkly no elige los modelos. La documentación de Agents es explícita: «El Agent utiliza el modelo predeterminado del Runtime. No garantiza ni muestra un nombre de modelo concreto. Cambie de modelo en la configuración de las herramientas del Runtime o del Computer, no en el Agent». Por lo tanto, la selección del modelo se realiza en el Computer:
- Claude Code con
claude-sonnet-5-5. Requiere Claude Code v2.1.284 o posterior. El modelodefaultde Claude Code es Opus 5.5 en planes Pro, Max, Team, Enterprise y en la API de Anthropic, por lo que un Computer ejecutará Opus hasta que alguien lo modifique, y el aliassonnetsolo equivale a Sonnet 5.5 en la API de Anthropic. Fija el identificador completo y confírmalo conclaude --model claude-sonnet-5-5en ese host. En cómo ejecutar agentes con Sonnet 5.5 en Sharkly encontrarás la ruta completa. - Codex con
gpt-6-sol. Configura el modelo en la configuración de Codex en ese Computer; en cómo ejecutar agentes con GPT-6 Sol en Sharkly se detallan los pasos. - Directorio de trabajo temporal en ambos Agents. Cada ejecución recibe un directorio aislado y las ejecuciones basadas en repositorio pueden preparar un worktree limpio, de modo que los dos intentos nunca compartan el mismo checkout.
A continuación, documenta la prueba por escrito antes de iniciar cualquiera de las dos ejecuciones:
Task: SH-312, one real Task, same description and starting commit for both runs
Run A: Claude Code Agent, claude-sonnet-5-5, effort: medium (Claude Code default) or high
Run B: Codex Agent, gpt-6-sol, effort: whatever Codex on that Computer is set to, written here
Accept: the same acceptance test for both
Record: accepted y/n, human review minutes, reruns, files touched outside scope,
provider cost from your own Anthropic and OpenAI bills
Decide: after several Tasks of each kind you actually assign, not one
Asigna la Task a un Agent y activa el otro mencionándolo en un comentario; Sharkly permite que una mención explícita inicie un Agent que no sea el asignado principal (Assignee). Ambas ejecuciones reportarán en la misma Task, de modo que los dos diffs, las dos ejecuciones de pruebas y cualquier consulta quedarán reunidos en una única cronología en lugar de en dos historiales de terminal independientes. La versión enfocada en un único bug, acompañada de una rúbrica de evaluación, se encuentra en Claude Code frente a Codex en el mismo bug.
Prioriza ante todo los minutos de revisión. La guía de prompting de Anthropic indica que Sonnet 5.5 añade pruebas, documentación y archivos pequeños en todos los niveles de esfuerzo, solicita confirmación preliminar en tareas extensas con esfuerzo low y medium, e inicia rondas de revisión adicionales o subagentes revisores en xhigh y max. Lo que sea que haga Codex con Sol en situaciones similares saldrá a la luz durante la prueba. Todo esto repercute directamente en el tiempo de revisión humana, y nada de ello aparece en la puntuación de un benchmark.
Por qué «ambos» es una respuesta perfectamente válida
La evidencia publicada no arroja un ganador absoluto para todos los casos, y es muy posible que tu prueba tampoco lo haga. Obtener un resultado dividido es un hallazgo valioso, no un fracaso.
Elige un único Runtime cuando la prueba no muestre diferencias que justifiquen el conteo de minutos de revisión, o cuando un equipo pequeño prefiera gestionar una sola suscripción y una única configuración. Si solo utilizas Claude Code y te atrae un flujo de trabajo centrado en la terminal, es posible que ni siquiera necesites una capa de gestión. Conserva ambos si los resultados se dividen según el tipo de tarea o si quieres tener la libertad de cambiar el modelo predeterminado el próximo mes sin tener que rehacer todo el flujo de trabajo. Y el próximo mes no es un escenario hipotético: Opus 5.5, Sol y Luna se lanzaron el mismo día, y Sonnet 5.5 llegó tan solo seis días después.
Mantener ambos solo funciona si la Task, y no el Runtime, actúa como el registro de referencia. Ningún otro modelo puede leer los bloques de pensamiento (thinking blocks) de Sonnet 5.5, por lo que cuando una Task pasa de un Agent de Claude Code a un Agent de Codex, el razonamiento interno se pierde y únicamente se transfiere lo que esté documentado en la Task. Las decisiones, suposiciones y preguntas pendientes deben figurar en la descripción o en los comentarios. En cómo usar Claude Code y Codex juntos en una misma base de código se aborda la práctica diaria, y en Sonnet 5.5 u Opus 5.5 se explica el enrutamiento de tareas en el entorno de Claude.
Los agentes investigan, ejecutan, prueban y reportan. Las personas marcan el rumbo, conceden autorizaciones y validan el resultado. El Runtime puede cambiar cada trimestre; pero el contexto, el progreso, los bloqueos, los resultados y la revisión humana deben permanecer siempre visibles en un único lugar, desde la solicitud inicial hasta el lanzamiento.
La versión de la semana pasada sobre esta cuestión, Opus 5.5 frente a GPT-6 Sol, presentaba el problema simétrico en cuanto a evidencia: la publicación de OpenAI comparaba a Sol con un modelo de Claude que quedó superado pocas horas después. Define claramente tu modelo predeterminado, evalúalo sobre tu propio código y asegúrate de que el Runtime sea una configuración que puedas modificar. Si quieres seguir utilizando múltiples agentes de programación en lugar de comprometerte con un único ecosistema, ese es precisamente el problema en torno al cual está diseñado Sharkly. Conecta un Computer, crea un Agent por cada Runtime y asigna a ambos la misma Task real.
