Gemini 4 Argon, GPT-6 Astra y Claude Opus 5.5: tres modelos de frontera, tres ganadores distintos

El artículo de lanzamiento de Gemini 4 Argon de Google incluye una tabla comparativa de 19 filas. Según nuestro recuento, Argon lidera de forma absoluta en 13 de ellas y empata en una. Las cinco que pierde no son casualidad: GPT-6 Astra se queda con FrontierSWE v2, Terminal-Bench Science y OSWorld-2.0; Claude Opus 5.5 se lleva Terminal-bench 4.0 y PostTrainBench. Se trata de dos filas de Terminal-Bench, una de programación con agentes, una de ingeniería de ML y una de las dos de uso de computadora: gran parte del trabajo al que un equipo de desarrollo dedica realmente sus ejecuciones. Y la duda ya no es hipotética: desde el 13 de octubre de 2026, Argon está disponible de forma general en la API de pago de Gemini como gemini-4-argon.

Por tanto, la pregunta de «¿qué modelo gana?» tiene tres respuestas distintas según la fila, y para un equipo que ejecuta varios agentes de programación esto no es un detalle menor. Si cada Agente del tablero funciona sobre el mismo Runtime, el equipo hereda tanto las victorias como las derrotas de un único laboratorio, y cada nuevo lanzamiento reabre el debate. Qué agente se encarga de qué, qué tareas se han completado y cuáles necesitan revisión: nada de eso debería depender de quién haya encabezado una tabla esta semana.

TL;DR

Ningún laboratorio de frontera lidera todas las filas, ni siquiera en su propia tabla. Toma cada lanzamiento como una pista para el enrutamiento, no como un motivo para migrar: mantén conectado más de un Runtime, pon la regla de enrutamiento por escrito (un valor por defecto, las condiciones para derivar una Tarea a otro Agente y quién se encarga de la revisión) y ponla a prueba con tres Tareas de tu propio codebase. Astra se ejecuta a través de Codex, Opus 5.5 mediante Claude Code y los modelos Gemini a través de Gemini CLI con una clave de pago. Google no ha confirmado que Gemini CLI admita Argon, así que haz un smoke test con gemini-4-argon antes de que asuma Tareas reales.

Qué dice la tabla de Google, según el tipo de tarea

Las filas relevantes para los agentes de programación, agrupadas según las propias categorías de Google:

Tan solo la categoría de programación con agentes cuenta con cuatro filas y tres líderes distintos. El pleno indiscutible de Argon se da en tareas de conocimiento, contexto largo y filas multimodales, aspectos que tienen menor impacto para un equipo cuyas Tareas culminan en un diff.

Conviene interpretar estos datos con cierta cautela: se trata de la tabla de Google. Google evaluó a Argon internamente en varias filas, las cifras de la competencia son en su mayoría autodeclaradas o tomadas de tablas de clasificación públicas, y los entornos de prueba difieren. La metodología de evaluación detalla la fuente de cada celda. Los resultados independientes publicados tras el lanzamiento tampoco coinciden entre sí: Humanity’s Sixth Sense de Scale AI sitúa a Argon en primer lugar con un 55,4 % frente al 53,6 % de GPT-6 Astra, Cursor lo considera a la par de Opus 5.5 en su CursorBench, y Artificial Analysis posiciona a Argon (High) en el octavo puesto de 216 variantes analizadas a fecha del 15 de octubre.

El precio tampoco inclina la balanza de forma definitiva. Argon cuesta 2 $ por millón de tokens de entrada y 10 $ por millón de tokens de salida hasta el 30 de noviembre de 2026, pasando después a 4 $ y 20 $ a partir del 1 de diciembre. Esta última tarifa coincide con la de Opus 5.5. Por su parte, Astra tiene un precio oficial de 10 $ y 50 $.

Ningún laboratorio domina todas las filas, así que ninguno debería adueñarse de todo el tablero

Los propios datos de los proveedores respaldan este punto, no nosotros. Si la tabla de Google, diseñada específicamente por Google para exhibir su modelo, cede cinco filas a dos competidores, significa que no existe un único mejor modelo para agentes de programación. Lo que hay es un modelo óptimo para determinado tipo de Tarea, durante este trimestre y sobre un entorno de evaluación concreto.

Esto cambia el enfoque ante cada lanzamiento. La tentación habitual es acometer una migración completa: cambiar el Runtime por defecto, reconfigurar todo el entorno y forzar a todo el equipo a cambiar sus hábitos. La alternativa más rentable es tratar al nuevo modelo como un candidato más para las Tareas donde sus resultados destacan, dejando el resto del tablero tal como está. Ya hemos argumentado que el mejor agente de programación importa menos que la forma de gestionar el trabajo; y una tabla donde tres modelos se reparten las victorias confirma ese razonamiento con números.

El dilema se reduce a una decisión clara:

• Mantén un único Runtime por defecto si la mayoría de tus Tareas son homogéneas y una sola persona lo revisa todo. Un segundo Runtime supone una configuración más que mantener, una factura adicional y una nueva serie de posibles fallos.
• Utiliza dos o tres Runtimes si tus Tareas se dividen entre trabajo intensivo en terminal, validación de interfaces y lectura de bases de código extensas, ya que es ahí exactamente donde la tabla se fragmenta.

Pon por escrito la regla de enrutamiento

Una regla de enrutamiento que solo existe en la cabeza de un ingeniero es un simple hábito, y los hábitos no sobreviven a una nueva contratación ni a la semana de un gran lanzamiento. Escríbela en un lugar accesible para todo el equipo:

Routing rule v1 (re-test after every frontier launch)

Default
  The Agent on your current default Runtime, until your own
  comparison says otherwise.

Send the Task to the Claude Code Agent (Opus 5.5 set in Claude Code) when
  - most of the work happens in a terminal: builds, CI repair, setup  [Terminal-bench 4.0]
  - it is training or evaluation plumbing for a model pipeline        [PostTrainBench]

Send the Task to the Codex Agent (GPT-6 Astra set in Codex) when
  - the change has to be verified by driving a desktop or browser UI  [OSWorld-2.0]
  - it is scientific or data work done mostly in a terminal           [Terminal-Bench Science]

Send the Task to the Gemini CLI Agent (gemini-4-argon) when
  - it needs a very large codebase or log read in one pass            [GraphWalks]
  - note: the 1M window is shared by input, thinking and output, and
    Gemini CLI support is unverified. Smoke-test before this line routes work.

Escalate
  If a run fails its acceptance checks twice, reassign the Task to the next
  Agent in this rule. The failed runs stay on the Task as evidence.

Review
  An Agent on a different Runtime from the author reads the diff and the
  evidence. A person accepts the result.

Cada condición hace referencia a la métrica que la justifica y a un tipo de Tarea fácilmente reconocible. La línea relativa a la revisión es la más importante: que un modelo examine un diff que no ha escrito supone una segunda opinión económica, mientras que la aprobación final sigue recayendo en una persona.

El lugar donde debe residir esta regla depende de quién gestione el enrutamiento. Si las personas asignan directamente la tarea, debe constar en las convenciones escritas del Space. Si la asignación corre a cargo de un responsable de Crew, pertenece a las instrucciones del Crew. En cualquier caso, el resultado vuelve a la misma Tarea, conservando así el historial de comparaciones en un solo sitio. El artículo Which model for which coding task profundiza en cómo hacer coincidir los perfiles de tarea con los roles de cada modelo.

Prueba la regla en tu propio codebase antes de confiar en ella

Una métrica de referencia incluye un tipo de Tarea en la lista de candidatos; tu repositorio es el que decide el valor por defecto. El método descrito en how to compare coding agents on your own codebase encaja a la perfección con esta tabla, ya que esta misma te indica qué tres Tareas seleccionar:

1. Una Tarea intensiva en terminal, como solucionar un fallo en la integración continua (CI).
2. Una Tarea cuyo cambio deba verificarse a través de una interfaz de usuario.
3. Una consulta que requiera cargar en contexto una parte amplia del repositorio.

Asigna a cada Agente la misma descripción de la Tarea y los mismos criterios de aceptación, usando el modo Create temporary directory para que cada ejecución cuente con su propio worktree. Después, evalúa lo que realmente se entrega en la Tarea, no lo que el agente afirme haber hecho: el diff, las comprobaciones y sus resultados, las preguntas formuladas y el tiempo que una persona necesitó para dar el visto bueno.

Argon ya puede entrar en esta comparativa tan pronto como supere un smoke prompt básico con gemini-4-argon en tu Gemini CLI. Ejecuta las mismas tres Tareas con él antes de modificar cualquier otra configuración. La comparativa entre Opus 5.5 y GPT-6 Sol como Runtime por defecto analiza a fondo la vertiente del coste por tarea completada en esta misma toma de decisiones.

Dónde se ejecuta cada modelo a 15 de octubre de 2026

Las filas de Gemini esconden una trampa. Desde el 18 de junio de 2026, Gemini CLI ya no admite cuentas Google AI Pro, Ultra ni cuentas gratuitas de Code Assist para particulares, según el aviso de transición de Google. Los planes Pro y Ultra incluyen Argon dentro de la aplicación Gemini, pero una suscripción no equivale a una clave de API, y Argon carece de un nivel de API gratuito.

Sharkly no elige los modelos por ti. La documentación de Agents lo explica con claridad: «El Agente sigue el modelo por defecto del Runtime. No garantiza ni muestra un nombre de modelo específico». El modelo se define a través de los Custom arguments en el Agente o en el Runtime, o bien en la propia configuración de la herramienta dentro de la Computer. De este modo, «el Agente de Codex» en la regla de enrutamiento se refiere a un Agente ejecutado sobre un Runtime de Codex configurado para utilizar Astra.

Las guías de configuración están disponibles en GPT-6 Astra in Sharkly, Claude Opus 5.5 in Sharkly y, para configurar Gemini CLI y dar el salto a Argon, en Gemini 4 Argon for coding agents.

La tabla cambia; el tablero no debería

El próximo lanzamiento volverá a redefinir esta tabla. Lo que debe permanecer estable es todo lo que rodea al modelo: la regla de enrutamiento, las Tareas, las evidencias que aporta cada ejecución y la persona encargada de validar el resultado. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan el rumbo, otorgan autorizaciones y dan el visto bueno final.

Si tu objetivo es seguir aprovechando múltiples agentes de desarrollo en lugar de atarte a un único ecosistema, ese es precisamente el problema para el que se diseñó Sharkly.