Cargando datos de benchmark…
EyesInAI·Cargando datos de benchmark en vivo
«Opus, Sonnet o Haiku». «GPT-5 o 4o». Cada proveedor lanza una línea de modelos con etiquetas seguras y ninguna forma de saber cuál le conviene para el código que tiene enfrente. Esta página responde dos cosas con claridad: qué modelo conviene para cada tarea de programación y cuánto obtienen realmente los modelos de punta cuando tomamos su código y lo ejecutamos: tasas de aprobación sobre casos de prueba ejecutados, no pruebas de los proveedores.
El error más común es elegir por reflejo el modelo más grande. El costo y la latencia se acumulan rápido, y el modelo más grande rara vez gana en un cambio de rutina. Busque su tarea y luego elija el nivel.
Necesita: Velocidad y volumen. La forma ya se conoce; solo quiere que se escriba.
Elija: Un nivel rápido y económico: Haiku 4.5, GPT-4o o un modelo abierto (DeepSeek-V3, Qwen).
Evite: Un modelo de razonamiento de punta. Estaría pagando una profundidad que no necesita.
Necesita: Sabe exactamente lo que quiere: que se haga limpio y rápido.
Elija: El nivel eficiente: Sonnet o GPT-4o. Rápido, capaz y lo bastante económico para usarlo seguido.
Evite: Elegir por reflejo el modelo más grande para un cambio bien delimitado.
Necesita: Razonar sobre el estado, los casos límite y por qué el código realmente falla.
Elija: Un modelo de punta: Opus 4.8, GPT-5 o Gemini 2.5 Pro. Aquí la profundidad se paga sola.
Evite: Un modelo pequeño y rápido: «corregirá» con toda seguridad la línea equivocada.
Necesita: Mantener mucho contexto sin romper el comportamiento en muchos archivos.
Elija: Un modelo de punta con una ventana de contexto grande (Opus 4.8 1M, Gemini 2.5 Pro).
Evite: Repartir el trabajo en un modelo barato para ahorrar: volver a leer cuesta más.
Necesita: Uso de herramientas, mantenerse en la tarea durante muchos pasos y avanzar sin desviarse.
Elija: El nivel más alto: el modelo de punta más grande (Opus 4.8, GPT-5 o Gemini 2.5 Pro); importan los buenos resultados en uso de herramientas.
Evite: Un modelo que arrasa en pruebas de un solo intento pero pierde restricciones en un ciclo largo.
Necesita: Leer con cuidado y detectar errores sutiles, no escribir código nuevo.
Elija: Un modelo de punta, o uno más económico con esfuerzo de razonamiento ALTO como punto medio.
Evite: Suponer que «rápido = suficiente». En la revisión es donde la profundidad se gana su costo sin que se note.
El menú de modelos de Claude Code confunde porque las etiquetas describen capacidad, no trabajo. Esta es la misma línea de modelos según cuándo conviene elegir cada uno, más el esfuerzo, un ajuste aparte: combinar esfuerzo ALTO con un modelo más económico es el punto medio entre rápido y minucioso.
| Modelo | Qué es | Elíjalo cuando |
|---|---|---|
| Fable 5 | El más capaz, el más lento y el más caro | Tareas difíciles Y largas: refactorizaciones grandes, ciclos de agentes de muchos pasos. Úselo solo cuando la tarea justifique el costo. |
| Opus 4.8 | El caballo de batalla diario (contexto de 1M) | Programación realmente compleja o ambigua, o cuando carga muchos archivos. La opción sensata por defecto. |
| Sonnet 5 | El nivel eficiente: un escalón abajo, a propósito | Trabajo de rutina bien delimitado: cambios puntuales, código repetitivo, llamadas de alto volumen. «Sé lo que quiero: hazlo rápido y limpio». |
| Haiku 4.5 | El más rápido, para tareas breves | Cambios triviales, consultas rápidas, funciones pequeñas. La menor profundidad, pero excelente cuando la velocidad es lo único que importa. |
Esta es la línea actual de modelos con los nombres que usan las herramientas. La tabla medida de abajo es la última ejecución de pruebas (4 jul 2026), así que las versiones exactas que evaluó pueden ir detrás de los nombres más nuevos de arriba; la lógica de niveles (rápido y económico frente a punta y profundo) se mantiene sin importar qué versión esté disponible.
Los consejos son baratos; aquí hay cifras. Cada prueba de programación pide a un modelo escribir, corregir o refactorizar una función, y luego ejecutamos su resultado contra casos de prueba ocultos en un entorno aislado. Aprobar significa que el código realmente funciona, no que la respuesta pareciera razonable o llegara rápido. Cada ejecución se repite 3× para que un acierto por suerte no favorezca a nadie.
| Prueba de programación | GPT-5 | Sonnet | Opus | GPT-4o | DeepSeek-V3.1 | Qwen2.5-72B | Gemini |
|---|---|---|---|---|---|---|---|
Depuración: corregir una función con un error sutil code_fix_bug · code_fix_bug | 3/3 | 3/3 | 3/3 | 2/3 | 3/3 | 3/3 | 2/3 |
Implementar a partir de una especificación precisa code_to_spec · code_to_spec | 3/3 | 3/3 | 3/3 | 3/3 | 1/3 | 3/3 | 1/3 |
Refactorizar conservando el comportamiento code_refactor_preserve · code_refactor_preserve | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 |
Algoritmo no trivial (fusión de intervalos) code_algo · code_algo | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 0/3 | 0/3 |
Calidad de la generación de código code · code_flatten | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 3/3 | 2/3 |
Ejecutado en un entorno aislado (subproceso aislado, sin secretos, límite de 5 s). Generado el 2026-07-04. Parte de la serie profunda.
Lea esto como una señal, no un veredicto. Es una serie de programación pequeña y difícil a propósito: un puntaje bajo en una prueba es un hallazgo, no la prueba de que un modelo «no sabe programar». El trabajo real también depende de su entorno, su contexto y su instrucción. Use la tabla para separar los modelos que razonan sobre el código de los que solo imitan patrones, y luego confírmelo en su propia tarea. El costo también importa: el modelo más económico que cumple con su nivel suele ganar.