Artificial Analysis Coding Agent Index coloca a Claude en primer lugar, pero el costo reordena a los líderes
Artificial Analysis colocó a Claude Sonnet 5.5 en primer lugar con 68 puntos, pero sus nuevos resultados sobre agentes de programación revelan una realidad de costos mucho menos favorable.
El Artificial Analysis Coding Agent Index sitúa a Claude Code con Sonnet 5.5 en esfuerzo máximo por delante de Gemini 4 Argon y GPT-6.1 Sol. Sin embargo, el ganador consume mucho más tiempo, tokens y gasto de API por tarea que sus rivales nuevos más cercanos.
Esa diferencia cambia la decisión práctica para los equipos de desarrollo. Claude lidera el benchmark compuesto, mientras que Codex con GPT-6.1 Sol ofrece resultados casi comparables usando una fracción de los recursos medidos. Gemini 4 Argon se sitúa entre ambos, al combinar una sólida puntuación agregada con una ventaja notable en tareas de software de largo horizonte.
La publicación original del benchmark presenta los tres lanzamientos como nuevos líderes. Los resultados subyacentes respaldan su importancia, pero no un simple podio de tres posiciones. Otras configuraciones, incluida Claude Opus 5.5, también aparecen cerca de la cima.
Más importante aún, cada resultado corresponde a un modelo, una configuración de razonamiento y un arnés de agentes. La clasificación no evalúa solo inteligencia abstracta del modelo. Evalúa sistemas completos de programación como Claude Code, Codex y Antigravity CLI.
Esa distinción es el núcleo de la historia. Los equipos ya no eligen únicamente el modelo con la puntuación más alta. Eligen cuánto tiempo y cómputo adicional vale un punto más en un benchmark.
Qué cambió en el Artificial Analysis Coding Agent Index
Los resultados más recientes separan con mayor claridad el liderazgo en benchmarks de la eficiencia operativa que las comparaciones anteriores de modelos.
Artificial Analysis evalúa agentes de programación en trabajo de extremo a extremo, en lugar de preguntas aisladas de autocompletado de código. Su índice combina modificación de repositorios, operación de terminal y comprensión de bases de código en una sola puntuación.
Claude Code ejecutando Sonnet 5.5 con esfuerzo máximo lidera con 68 puntos. Sus resultados por componente son 72 por ciento en DeepSWE v1.1, 66 por ciento en Terminal-Bench 4.0 y 67 por ciento en SWE-Atlas-QnA.
Antigravity CLI ejecutando Gemini 4 Argon obtiene 64. Alcanza 79 por ciento en DeepSWE, 56 por ciento en Terminal-Bench y 56 por ciento en preguntas sobre repositorios.
Codex con GPT-6.1 Sol con esfuerzo xhigh obtiene 63. Esa configuración registra 73 por ciento en DeepSWE, 55 por ciento en Terminal-Bench y 61 por ciento en SWE-Atlas-QnA.
Esos totales dejan solo cinco puntos entre Claude y Sol. Sin embargo, Artificial Analysis midió la configuración de Claude utilizando aproximadamente 8,7 veces más tokens por tarea. También se ejecutó casi seis veces más tiempo.
El costo de API medido muestra una brecha aún mayor. La configuración de Claude con esfuerzo máximo cuesta aproximadamente 13,6 veces más por tarea que Sol en xhigh dentro de Codex.
Gemini 4 Argon queda entre esos extremos. Su costo medido es aproximadamente 5,6 veces el de Sol, mientras que su ventaja en el índice es de un punto. Consume cerca de 4,3 veces más tokens y tarda más del doble.
La comparación del benchmark cuenta, por lo tanto, dos historias. Claude tiene la puntuación compuesta más alta, mientras que Sol ofrece la relación entre puntuación medida y costo más sólida entre estas tres configuraciones.
Artificial Analysis también informa varias configuraciones de esfuerzo para Sonnet 5.5. Ese detalle importa porque el esfuerzo máximo no es la configuración predeterminada de Claude Code.
Sonnet 5.5 con esfuerzo xhigh obtiene 63, igualando la puntuación destacada de Sol. Usa más del doble de tokens que Sol y tiene un costo medido más de tres veces superior.
Con esfuerzo high, Sonnet obtiene 55. Con esfuerzo medium, el valor predeterminado en Claude Code, obtiene 46. Estos resultados demuestran cuánto cambia el presupuesto de razonamiento el producto que se está evaluando.
El mismo patrón aparece en los resultados de Sol. GPT-6.1 Sol con esfuerzo medium obtiene 61, solo dos puntos por debajo de su configuración xhigh. Su costo medido y tiempo de ejecución también disminuyen sustancialmente.
El razonamiento máximo no produce automáticamente el mejor resultado. El resultado xhigh de Sol supera en tres puntos su resultado con esfuerzo máximo en la evaluación publicada.
Ese resultado contraintuitivo recuerda que los benchmarks de agentes contienen variabilidad. Más tiempo de inferencia puede ayudar, pero también puede generar trayectorias más largas, llamadas a herramientas innecesarias o reconsideraciones improductivas.
El ganador del titular sigue siendo Claude Code con Sonnet 5.5 en esfuerzo máximo. El cambio más relevante es que los compradores ahora pueden ver cuán elevado es el precio de sus últimos cinco puntos.
El benchmark mide sistemas, no solo modelos
La puntuación de un agente de programación refleja la interacción entre un modelo, su arnés, sus herramientas y su presupuesto de razonamiento.
El Coding Agent Index v1.5 utiliza tres componentes con el mismo peso. Según la metodología publicada del índice, cada componente evalúa una parte distinta del trabajo de software.
DeepSWE v1.1 contiene 113 tareas de largo horizonte. Los agentes deben modificar repositorios existentes, mientras entornos de verificación independientes determinan si sus parches confirmados superan las pruebas.
Terminal-Bench 4.0 contiene 66 tareas que cubren áreas como ingeniería de software, aprendizaje automático, seguridad y administración de sistemas. Los agentes trabajan en entornos de línea de comandos y, después, suites de pruebas califican sus resultados.
SWE-Atlas-QnA contiene 124 preguntas sobre repositorios. Estas tareas miden si un agente puede rastrear código desconocido y explicar con precisión su comportamiento.
Cada tarea recibe tres intentos. Artificial Analysis calcula resultados pass-at-one para cada componente y, después, asigna el mismo peso a los tres componentes en el índice compuesto.
Esta estructura es más amplia que una prueba convencional de generación de código. Recompensa a los agentes capaces de inspeccionar repositorios, elegir herramientas, operar terminales, mantener el contexto y recuperarse de errores.
También hace importante el arnés. Un arnés es la capa de software que conecta un modelo con archivos, terminales, instrucciones, gestión de contexto y ejecución de herramientas.
Claude Code, Codex y Antigravity CLI no exponen flujos de trabajo idénticos. Pueden empaquetar el contexto de forma diferente, fomentar distintos patrones de uso de herramientas o imponer límites distintos.
En consecuencia, el benchmark no puede establecer que Sonnet 5.5 sea siempre un mejor modelo de programación que GPT-6.1 Sol. Establece que una configuración evaluada de Claude Code obtuvo una puntuación superior a una configuración evaluada de Codex.
La distinción se hace visible en las puntuaciones de los componentes. Gemini 4 Argon lidera al trío en DeepSWE con 79 por ciento, pese a quedar por debajo de Claude en el resultado global.
Sol supera por poco a Sonnet con esfuerzo máximo en DeepSWE. Claude construye su ventaja general a través de Terminal-Bench y SWE-Atlas-QnA, donde obtiene márgenes mayores.
Por tanto, los resultados describen perfiles de capacidad diferentes. Gemini parece más fuerte en los cambios de repositorios de largo horizonte del benchmark. Claude parece más equilibrado entre trabajo de terminal y comprensión de repositorios.
Sol sigue siendo competitivo en los tres mientras utiliza menos recursos medidos. No gana un componente incluido frente a ambos rivales, pero evita una debilidad grave.
Ese equilibrio importa en el uso en producción. Un equipo que mantiene un repositorio grande puede valorar más la finalización de parches que la respuesta a preguntas sobre repositorios. Otro equipo puede necesitar trabajo fiable en terminales a través de entornos variados.
El número único del índice ayuda a los lectores a examinar rápidamente el panorama. No debería sustituir los resultados por componente al seleccionar una herramienta para una carga de trabajo definida.
Artificial Analysis también agrupa datos de tokens, costo y tiempo de la misma suite de benchmarks. La telemetría faltante se excluye del promedio pertinente en lugar de tratarse como cero.
Su cálculo de costos considera tokens de entrada ordinarios, entrada en caché, escrituras de caché, razonamiento y salida cuando los proveedores fijan precios por separado para esas categorías. Representa el costo de API de pago por token, no el precio de suscripción.
El costo informado también excluye varios gastos operativos. No incluye integración de ingeniería, revisión humana, configuración de entornos, controles de seguridad ni las consecuencias de un parche defectuoso.
Estas exclusiones no debilitan la comparación. Definen lo que puede responder: cuánto uso de modelo consumieron los agentes evaluados bajo esta prueba.
También explican por qué la ejecución de benchmark más barata no siempre producirá la solicitud de extracción aceptada más barata. Un resultado más débil puede generar costos adicionales de revisión, corrección y nueva ejecución.
Por ello, los equipos deberían evaluar tanto el costo directo de inferencia como el costo por resultado exitoso. El índice publicado proporciona elementos útiles, pero no calcula esa medida empresarial completa.
Claude Sonnet 5.5 gana en rendimiento con una elevada prima de eficiencia
La ventaja de Claude es real dentro de este benchmark, pero el esfuerzo máximo convierte una modesta ventaja de puntuación en un gran compromiso de recursos.
Anthropic lanzó Sonnet 5.5 el 28 de septiembre de 2026. La empresa lo posiciona como un complemento más rápido y de menor costo para Opus 5.5 en tareas diarias acotadas, depuración y creación de documentos.
Los detalles del lanzamiento del modelo de Anthropic destacan el esfuerzo ajustable. Las configuraciones inferiores priorizan velocidad y economía, mientras que las superiores dan al modelo más tiempo para razonar y comprobar su trabajo.
Los resultados de Artificial Analysis muestran ambos lados de ese diseño. Pasar Sonnet de esfuerzo medium a máximo eleva su índice de 46 a 68.
Esa mejora de 22 puntos es sustancial. Va acompañada de aproximadamente 21 veces más tokens, más de diez veces el tiempo de ejecución y casi 23 veces el costo de API medido.
El esfuerzo máximo también produce trayectorias de agentes muy largas. Artificial Analysis registra cerca de 266 turnos por tarea y 27,7 millones de tokens totales para la configuración líder.
Estas cifras no significan que cada tarea real consumirá los mismos recursos. Muestran el comportamiento promedio en una exigente suite de benchmarks con cientos de intentos de tareas.
También aclaran cómo gana el modelo. La configuración de mejor rendimiento no se limita a producir una respuesta más inteligente con el mismo presupuesto. Dedica mucho más tiempo a interactuar con su entorno.
Esa estrategia se refleja en la puntuación compuesta. Claude supera a Gemini por cuatro puntos y a Sol por cinco. También logra los mejores resultados del trío en dos de los tres benchmarks por componente.
La prima se vuelve más difícil de justificar cuando las configuraciones de menor esfuerzo de Claude entran en la comparación. Sonnet en xhigh iguala la puntuación de 63 de Sol, pero consume más tokens, tiempo y gasto medido.
Con esfuerzo high, Claude queda ocho puntos por detrás de Sol xhigh. Su uso de recursos se acerca al de Sol, pero la brecha de rendimiento se vuelve significativa.
Con esfuerzo medium, Claude se vuelve mucho más barato y rápido que su configuración máxima. Sin embargo, su puntuación queda 17 puntos por debajo de Sol xhigh y 18 puntos por debajo de Gemini.
No hay contradicción entre estos resultados. Anthropic permite a los usuarios adquirir más razonamiento en tiempo de prueba, y el benchmark muestra que ese razonamiento adicional puede elevar la finalización de tareas.
La disyuntiva tiene que ver con la escala. Un desarrollador individual puede aceptar una ejecución larga y costosa para una migración difícil. Una empresa que procesa miles de cambios rutinarios se enfrenta a un cálculo distinto.
La mejor configuración también puede variar dentro de un mismo flujo de trabajo. Un equipo puede usar esfuerzo medium para exploración, high para implementación y máximo solo para fallos persistentes.
Esa estrategia de enrutamiento preservaría el acceso a la máxima capacidad de Claude sin aplicar su mayor presupuesto de recursos a cada ticket. Requiere medición y reglas claras de escalamiento.
La victoria de Claude en los benchmarks es, por tanto, más relevante para tareas en las que la calidad de finalización domina sobre todas las demás restricciones. Entre los ejemplos se incluyen correcciones complejas entre repositorios, migraciones frágiles o incidentes con altos costos de fallo.
Resulta menos decisiva para el mantenimiento de gran volumen. Las actualizaciones de dependencias, los pequeños refactors, la generación de pruebas y las correcciones rutinarias de errores suelen recompensar una calidad aceptable a un coste predecible.
Por eso el Artificial Analysis Coding Agent Index no debería convertirse en un atajo de compra. El resultado de 68 puntos representa una configuración de techo, no una opción predeterminada automática.
GPT-6.1 Sol y Gemini 4 Argon presionan a Claude desde distintas direcciones
Sol desafía a Claude en eficiencia, mientras que Argon lo desafía en el trabajo de repositorio de largo alcance.
OpenAI presentó GPT-6.1 Sol el 29 de septiembre, un día después de que Anthropic lanzara Sonnet 5.5. Google le siguió con Gemini 4 Argon el 30 de septiembre.
El calendario permitió a Artificial Analysis comparar tres nuevas configuraciones de frontera en cuestión de días. Sus posiciones en el benchmark revelan una diferenciación mayor de la que sugieren sus descripciones de lanzamiento.
OpenAI describe Sol como un modelo cercano a los insignia para programación, uso de ordenadores y trabajo profesional a menor coste. Su ficha del modelo Sol admite cinco ajustes de razonamiento, desde bajo hasta máximo.
En el Coding Agent Index, xhigh es la mejor configuración probada de Sol. Obtiene 63 puntos, mientras que el esfuerzo máximo obtiene 60.
Ese resultado cuestiona la suposición de que el mayor presupuesto de razonamiento es siempre el más seguro. Sugiere que los equipos deberían evaluar los ajustes de esfuerzo en benchmarks en lugar de seleccionar por defecto la etiqueta más alta.
La principal ventaja de Sol es la consistencia por unidad de recurso. La configuración xhigh completa una tarea media en unos 15,5 minutos y consume 3,2 millones de tokens.
Claude con esfuerzo máximo necesita unos 90 minutos y 27,7 millones de tokens. Gemini requiere unos 34,5 minutos y 13,7 millones de tokens.
Sol también ofrece un rendimiento competitivo en cada componente. Su resultado de 73 por ciento en DeepSWE supera el 72 por ciento de Claude, aunque queda por detrás del 79 por ciento de Gemini.
Sus puntuaciones en Terminal-Bench y preguntas sobre repositorios se mantienen por debajo de las de Claude. Esas desventajas generan la brecha compuesta de cinco puntos.
Para muchas organizaciones, esa brecha será aceptable. El menor uso de recursos de Sol permite más intentos, un despliegue más amplio o verificaciones adicionales con el mismo presupuesto.
La comparación no establece que Sol sea universalmente más económico. Los precios de los proveedores pueden cambiar, los patrones de caché difieren y las cargas de trabajo internas pueden producir distribuciones de tokens distintas.
Sí establece una hipótesis sólida que merece probarse. Si las tareas de un equipo se parecen a las del benchmark, Codex con Sol podría ofrecer un mejor equilibrio entre coste y rendimiento que Claude con esfuerzo máximo.
Gemini 4 Argon genera otro tipo de presión. Google presentó Argon como un modelo para el razonamiento sostenido en flujos de trabajo profesionales complejos.
El anuncio de Argon de Google describe usos internos relacionados con migración de código, optimización de memoria, investigación y ciberseguridad. Esos ejemplos siguen siendo afirmaciones de la empresa salvo que se reproduzcan de forma independiente.
El Coding Agent Index añade evidencia de terceros para una parte de esa historia. El resultado de 79 por ciento de Argon en DeepSWE es el más sólido entre los tres sistemas destacados.
Ese resultado se alinea con el enfoque de Google en el trabajo de largo alcance. Sugiere que Argon merece atención para cambios extensos en repositorios, aunque Claude lidera el índice general.
La puntuación más débil de Argon en preguntas sobre repositorios reduce su resultado compuesto. Su resultado de 56 por ciento queda cinco puntos por detrás de Sol y once por detrás de Claude.
El modelo tampoco cuenta con la eficiencia medida de Sol. Argon gana un punto agregado sobre Sol mientras requiere más de cuatro veces tantos tokens por tarea.
Eso no hace que la configuración sea irracional. Una mayor tasa de finalización en DeepSWE puede compensar el uso de recursos para organizaciones que afrontan trabajo de implementación difícil.
La pregunta importante es la adecuación a la carga de trabajo. Sol parece atractivo como generalista eficiente, mientras que Argon ofrece una señal más fuerte en la modificación de repositorios de larga duración.
Claude sigue siendo el líder en rendimiento equilibrado con su configuración más agresiva. La presión de mercado procede de rivales que restan valor a distintas partes de esa ventaja.
Este es un panorama competitivo más saludable que una clasificación universal. Ofrece a los equipos de ingeniería opciones diferenciadas en lugar de tres marcas de modelos casi intercambiables.
También aumenta la importancia de mantener flujos de trabajo portables. Los equipos deberían evitar vincular prompts, prácticas de revisión y preparación de contexto a un único modelo salvo que el beneficio sea medible.
Un registro consultable de requisitos, decisiones y cambios anteriores puede hacer que esas comparaciones sean más consistentes. Los equipos pueden usar una base de conocimientos de ingeniería para conservar ese contexto entre pruebas con agentes.
El objetivo no es cambiar de modelo cada semana. Es hacer posible el cambio y la evaluación cuando se mueva la frontera de rendimiento.
Lo que los números no demuestran
Una ventaja de cinco puntos en un benchmark no garantiza mejor código, despliegues más seguros ni un menor coste total de ingeniería dentro de una organización real.
Artificial Analysis publica más detalle metodológico que muchos operadores de clasificaciones. Sus tareas por componente, número de intentos, métodos de puntuación y definiciones de eficiencia están documentados.
Aun así, un benchmark sigue siendo una muestra. No puede representar todos los lenguajes, estructuras de repositorio, entornos de dependencias, políticas de seguridad ni estándares de revisión.
El índice pondera sus tres componentes por igual. Una empresa real rara vez valora las preguntas sobre repositorios, las operaciones de terminal y la finalización de parches en proporciones exactamente iguales.
Una organización puede dedicar la mayor parte de su tiempo a servicios TypeScript con pruebas exhaustivas. Otra puede mantener código C embebido, canalizaciones de datos o sistemas financieros regulados.
Su clasificación interna puede diferir de la tabla pública. Un modelo que destaca en DeepSWE aún puede tener dificultades con frameworks propietarios o código heredado mal documentado.
La puntuación pass-at-one también comprime diferencias importantes de calidad. Dos parches pueden superar un verificador automatizado y, sin embargo, diferir en mantenibilidad, seguridad, legibilidad o adecuación arquitectónica.
También puede ocurrir lo contrario. Una solución parcial útil puede fallar una condición del verificador y recibir el mismo resultado binario que un intento inutilizable.
SWE-Atlas-QnA introduce otra dependencia. Artificial Analysis utiliza un juez automatizado para decidir si las respuestas sobre repositorios cumplen todos los criterios requeridos.
La evaluación automatizada permite realizar mediciones a escala. Aun así, puede heredar ambigüedad, sesgos de modelo o errores de calificación, especialmente en explicaciones con varias formulaciones válidas.
Los promedios agrupados del benchmark también ocultan la dispersión. El coste medio no revela si la mayoría de las tareas son predecibles mientras un grupo pequeño genera trayectorias extremadamente largas.
Esa variación importa para la presupuestación. Un servicio puede tolerar una media moderada y aun así sufrir ejecuciones individuales que consumen tokens en exceso u ocupan entornos durante horas.
El comportamiento de los agentes también puede cambiar después de actualizaciones de producto. La selección de herramientas, la compresión de contexto, la lógica de reintentos y las instrucciones de sistema ocultas pueden variar sin un nuevo nombre público de modelo.
Por ese motivo, el benchmark debe tratarse como una medición fechada. No es una propiedad permanente de Claude Code, Codex, Antigravity CLI ni de sus modelos subyacentes.
Claude con esfuerzo máximo ilustra el riesgo de interpretar un resultado de techo como una experiencia predeterminada. La configuración evaluada en el benchmark consume muchos más recursos que el valor predeterminado medio de Claude Code.
El índice también compara el gasto de API de pago por token. Los límites de suscripción, las tarifas empresariales negociadas, el procesamiento regional y la infraestructura interna pueden modificar la economía real de un equipo.
También faltan los costes humanos. Un agente más lento puede ser aceptable si trabaja de forma asíncrona. Un agente más rápido puede ser más valioso cuando un desarrollador espera comentarios.
La carga de revisión es otra variable sin resolver. Un parche económico que requiere una inspección exhaustiva puede costar más en conjunto que un parche caro aceptado tras una revisión breve.
La seguridad merece una cautela similar. Ninguna de las puntuaciones principales demuestra por sí sola que un agente siga el acceso de mínimo privilegio, resista instrucciones maliciosas en repositorios o evite filtrar contexto sensible.
Google ha limitado la disponibilidad inicial de Argon mientras realiza trabajo de seguridad por etapas. Ese lanzamiento implica que la evidencia de su uso público puede seguir siendo menor de lo que sugiere la atención del benchmark.
Las afirmaciones de los proveedores también requieren una atribución cuidadosa. Anthropic, OpenAI y Google destacan cada una resultados favorables de evaluación procedentes de distintos conjuntos y configuraciones.
Esos resultados pueden ser precisos sin ser directamente comparables. Diferentes harnesses, conjuntos de tareas, presupuestos y reglas de puntuación suelen producir líderes distintos.
El benchmark de Artificial Analysis mejora la comparabilidad al ejecutar configuraciones en un mismo marco. No puede eliminar todas las diferencias introducidas por agentes propietarios e interfaces de modelo.
Los líderes de ingeniería deberían reproducir una pequeña prueba interna antes de estandarizar. Un conjunto de pruebas útil incluye tickets completados, casos de fallo conocidos y restricciones representativas del repositorio.
Los revisores deberían evaluar la corrección, los cambios innecesarios, la seguridad, la cobertura de pruebas, la calidad de las explicaciones y el tiempo hasta la aceptación. El gasto de tokens debería registrarse junto a esos resultados.
La métrica resultante debería ser trabajo aceptado por dólar o trabajo aceptado por hora de ingeniería. Una puntuación compuesta pública puede orientar la selección de candidatos, pero no puede sustituir esa medición.
Tres señales decidirán si importa la ventaja de Claude
La siguiente fase se decidirá por el rendimiento con ajustes de esfuerzo predeterminados, la economía de los cambios aceptados y la estabilidad del benchmark entre actualizaciones.
La primera señal es el rendimiento con ajustes de esfuerzo prácticos. Las configuraciones máximas atraen titulares, pero los valores predeterminados determinan la mayor parte del uso diario.
Sonnet 5.5 con esfuerzo medio puntúa muy por debajo de su resultado máximo. Sol pierde solo dos puntos al pasar de xhigh a medio en los datos publicados.
Si Anthropic reduce esa brecha en los ajustes predeterminados, el techo de 68 puntos de Claude será más relevante para los equipos ordinarios. Si la brecha persiste, se reforzará el argumento de eficiencia de Sol.
La segunda señal es el coste por cambio aceptado. Los benchmarks públicos miden actualmente el gasto de API por tarea, no el recorrido completo desde la solicitud hasta el código fusionado.
Los equipos deberían observar si los proveedores o evaluadores independientes publican resultados ajustados por revisión. Estos deberían incluir repeticiones, tiempo de corrección humana y regresiones descubiertas después de la verificación.
La prima de Claude será más fácil de defender si sus parches requieren menos revisión. La ventaja de Sol se fortalecerá si su menor uso de inferencia no genera trabajo adicional de corrección.
Argon podría liderar esta medida en cambios complejos de repositorios si su fortaleza en DeepSWE se traslada a producción. Su puntuación agregada por sí sola no puede responder a esa pregunta.
La tercera señal es la estabilidad de la clasificación. Los agentes de programación cambian mediante actualizaciones de modelos, revisiones de harnesses, políticas de herramientas y mejoras en la gestión del contexto.
Un líder estable debería mantener su posición en ejecuciones repetidas y versiones del benchmark. Los cambios grandes tras pequeñas actualizaciones del sistema reducirían la confianza en diferencias estrechas de puntuación.
Artificial Analysis ya publica resultados por componente, métricas de eficiencia y revisiones metodológicas. Las futuras repeticiones mostrarán si la diferencia de cinco puntos representa una separación duradera o efectos temporales de configuración.
Los equipos de desarrollo no necesitan esperar a un benchmark perfecto. Ya pueden tomar una decisión acotada.
Comiencen con un conjunto representativo de tareas internas. Comparen Claude en más de un nivel de esfuerzo con Sol y Argon, cuando el acceso lo permita.
Mantengan coherentes los permisos del agente, la instantánea del repositorio y los criterios de éxito. Registren el tiempo total transcurrido, los tokens, los fallos, el tiempo de revisión y si se aceptó el cambio final.
Utilicen una configuración de alto esfuerzo solo cuando la tarea justifique esa escalada. El trabajo rutinario debería comenzar con la opción menos costosa que cumpla el umbral de aceptación del equipo.
Revisen la comparación tras actualizaciones importantes del modelo o del entorno de pruebas. El Artificial Analysis Coding Agent Index resulta útil precisamente porque la frontera está en constante movimiento.
Por ahora, su mensaje es claro. Claude Sonnet 5.5 obtiene la puntuación publicada más alta entre las tres nuevas configuraciones, pero no lidera todas las definiciones prácticas del primer puesto.
GPT-6.1 Sol ofrece un perfil de eficiencia convincente, mientras que Gemini 4 Argon lidera el trío en trabajo de repositorio de larga duración. La elección correcta depende del resultado que valore cada equipo.
¿Pagaría su organización un gran sobrecoste de recursos por cinco puntos adicionales en el índice, o financiaría más intentos y verificación con Sol? Prueben esa cuestión con su propio trabajo integrado antes de elegir una opción predeterminada.
