Opus 5 es un gran empleado, pero un jefe frustrante

Anthropic lanzó Opus 5 el 24 de julio de 2026. Mi veredicto tras cinco días de investigación es sencillo: es un gran empleado, pero un jefe frustrante [1]. Iguala a Fable 5 en los principales benchmarks a mitad de precio por token, pero pierde fiabilidad cuando debe marcar la dirección [2].

¿Opus 5 es tan capaz como Fable 5? En los benchmarks, casi

En los benchmarks publicados, Opus 5 y Fable 5 están en el mismo nivel de capacidad. Con esfuerzo máximo, Artificial Analysis puntúa a Opus con 61 en su índice de inteligencia, justo por delante de los 60 de Fable; un punto de diferencia es demasiado poco para afirmar que Opus sea el modelo más inteligente [2].

Métrica	Opus 5	Fable 5
Índice de inteligencia de AA	61	60
GDPval-AA v2, Elo	1861 (El mejor valor de la fila)	1747
AA-Briefcase, Elo	1720 (El mejor valor de la fila)	1574
Coste medido por tarea de evaluación, $	2,03 (El mejor valor de la fila)	2,75

Las evaluaciones más específicas de Artificial Analysis respaldan esa conclusión. Opus obtuvo 1861 Elo en GDPval-AA v2, que mide el trabajo profesional basado en conocimientos, y 1720 en AA-Briefcase, que evalúa tareas realizadas por agentes. Son 114 y 146 Elo más que Fable, respectivamente. Además, empató en el primer puesto del Coding Agent Index con esfuerzo xhigh y alcanzó un 89 % en Terminal-Bench 2.1 con esfuerzo máximo [2].

Estos resultados muestran que el modelo más barato puede igualar a Fable cuando la tarea tiene límites claros y un resultado concreto. Anthropic observa el mismo patrón: con esfuerzo máximo, Opus quedó a menos de medio punto de Fable en CursorBench 3.2 y superó el mejor resultado de Fable en OSWorld con cerca de un tercio del coste. Esas últimas mediciones proceden de Anthropic, así que los resultados independientes anteriores tienen más peso [1].

¿Por qué recibe críticas Opus 5? Por la supervisión

Las críticas se deben sobre todo al coste de supervisar a Opus, no a la calidad de su código.

El ejemplo más claro viene de un usuario que le dio un 100 % en un conjunto de tareas reales de programación y consideró que su implementación y disciplina de pruebas eran las mejores que había visto. Aun así, lo llamó “an incredible coder and really painful to work with” [4].

Esa diferencia entre el resultado y la experiencia de trabajo se repite en los hilos negativos, donde aparecen cinco problemas una y otra vez.

Pierde de vista el sistema completo. Opus puede escribir buen código para una parte del proyecto y, al mismo tiempo, tomar peores decisiones sobre la arquitectura, el diseño existente y los componentes que realmente debería modificar. Un desarrollador contó que inventaba mecanismos nuevos y prefería sus propios patrones a los del repositorio, así que volvió a Fable 5 y a una versión anterior de Opus para el trabajo diario [5].

Hace suposiciones en lugar de preguntar. Cuando falta información importante, Opus puede continuar con una idea razonable pero errónea. El resultado parece coherente, aunque resuelva el problema equivocado, y el usuario siente que el modelo no le ha escuchado [5].

Afirma que el trabajo está terminado demasiado pronto. Opus informa de una corrección, pero el usuario encuentra el problema original y, a veces, una regresión nueva. En una sesión de auditoría, el modelo no detectó 46 errores porque su propio script los había ocultado; otros usuarios hablan de verificaciones que nunca se hicieron [6]. Una falsa confirmación resulta especialmente costosa durante una migración o un cambio de despliegue.

Da demasiadas actualizaciones. Opus narra acciones rutinarias, escribe informes de estado largos y presenta pequeños detalles como decisiones importantes. El evaluador que le dio un 100 % también describió su comunicación como nerviosa, pedante y agotadora de supervisar [4].

Las instrucciones antiguas pueden empeorarlo. Al menos un usuario resolvió estos problemas reescribiendo las instrucciones y memorias de proyecto creadas para Opus 4.x [7]. Esos ficheros suelen pedir al modelo que compruebe todo dos veces, prepare planes detallados y cree subagentes. Como Opus 5 ya tiende a tomar la iniciativa, las indicaciones adicionales pueden llevarlo demasiado lejos.

La guía de prompting de Anthropic recoge casi la misma lista. Explica que Opus 5 narra más, verifica su propio trabajo y crea subagentes con mayor facilidad; también puede ampliar el alcance, añadir pasos no solicitados y decidir por sí mismo qué debe incluir la tarea. Anthropic recomienda marcar límites claros, fijar un máximo de subagentes y pedir directamente actualizaciones de estado más cortas [8].

También hay informes positivos creíbles. Un usuario centrado en tareas empresariales y basadas en conocimientos encontró que Opus rendía mejor que Sonnet 5 y Opus 4.8 con esfuerzo bajo y medio. Solo Fable se mantuvo por delante, y únicamente en los problemas más difíciles [9].

¿Por qué discrepan los benchmarks y los usuarios? El trabajo evaluado es distinto

Los benchmarks y los proyectos reales miden aspectos distintos, por lo que ambos grupos de resultados pueden ser correctos. Un benchmark comprueba el resultado final; un proyecto también deja ver si el modelo eligió el problema adecuado, necesitó correcciones constantes y explicó con sinceridad lo que había hecho.

Esa diferencia importa al interpretar el resultado de Anthropic en Frontier-Bench, que fue más del doble que el de Opus 4.8. La empresa utilizó un harness concreto de mini-SWE-agent y calculó la media de cinco intentos por tarea [1]. El método es razonable, pero la media reduce el efecto de las sesiones especialmente buenas o malas, que es justo lo que los usuarios suelen notar más.

Un resultado independiente ayuda a entender mejor las quejas. En AA-Omniscience, Artificial Analysis encontró que Opus 5 era más preciso que Opus 4.8, pero también más dispuesto a responder cuando no tenía certeza. Según el sistema de puntuación del benchmark, su tasa de alucinación rondó el 50 % [2]. Eso no significa que la mitad de una respuesta normal de Opus sea inventada, ya que la prueba plantea preguntas que los modelos solo conocen en parte. Sí apunta a una contrapartida: seguir trabajando pese a la incertidumbre permite resolver más tareas, pero también puede producir más errores expresados con seguridad.

¿Opus 5 cuesta realmente la mitad? Solo por token

Opus 5 cuesta la mitad por token, pero una tarea terminada suele costar más de la mitad de lo que costaría con Fable. Según Claude Platform Docs, las tarifas de la API son de 5 $ por millón de tokens de entrada y 25 $ por millón de tokens de salida para Opus, frente a 10 $ y 50 $ para Fable [10].

• Opus 5
• Fable 5

Ver los datos en una tabla

Tipo de token	Opus 5	Fable 5
Entrada	5 $/MTok	10 $/MTok
Salida	25 $/MTok	50 $/MTok

La diferencia se reduce al medir la tarea completa. Artificial Analysis pagó 2,03 $ por cada tarea de Opus 5 en su conjunto de evaluaciones y 2,75 $ por cada tarea de Fable, lo que dejó el ahorro en un 26 % [2]. Un usuario de Reddit vio una brecha todavía menor en dos tareas grandes de programación: 106,69 $ con Opus y 118,46 $ con Fable, alrededor de un 10 %. Consideró que el resultado de Fable era claramente mejor y, en la segunda tarea, Opus incluso costó más [11].

La comparación útil es el coste de un resultado aceptado, no solo el precio de cada token. La prueba de dos tareas de una sola persona no permite calcular el coste medio, pero muestra cómo puede desaparecer el descuento cuando los pasos innecesarios, las llamadas adicionales a herramientas, el código no solicitado y las rondas de corrección consumen tokens. Si Fable todavía debe revisar el resultado, se suma otro cargo.

¿Por qué cada versión de Opus parece distinta? Porque su comportamiento cambia

Cada versión de Opus puede comportarse de forma tan distinta que los prompts que funcionaban con la anterior dejan de hacerlo. Los propios materiales de Anthropic describen muchos de esos cambios.

Las versiones no siguen un camino simple hacia una mayor iniciativa. Las publicaciones de Anthropic aportan las fechas [12] [13] [14] [1], mientras que su investigación sobre los valores de los modelos ayuda a explicar los cambios de conducta. Ese trabajo relacionó Opus 4.6 con la deferencia, la brevedad y la ejecución, pero asoció 4.7 con la cautela, la profundidad y la franqueza [15].

Las notas de migración concretan la diferencia. Opus 4.7 seguía las instrucciones de manera más literal, discrepaba con mayor facilidad y hacía menos llamadas a herramientas con esfuerzo bajo; Anthropic también advirtió que los prompts antiguos podían comportarse mal con él [13]. Opus 4.8 redujo después el exceso de comentarios y explicaciones de 4.7 [14], antes de que Opus 5 volviera con decisión hacia una mayor iniciativa [8].

El problema práctico es que cada cambio de conducta puede invalidar las instrucciones escritas para un modelo anterior. La planificación y las comprobaciones adicionales quizá hacían más fiable a Opus 4.6, pero con Opus 5 pueden generar demasiada planificación, explicaciones y trabajo no solicitado. Esto ayuda a entender por qué reescribir las instrucciones antiguas resuelve tantos problemas [7].

Los informes de la primera semana también se ven de otra manera con el paso del tiempo. Opus 4.8 recibió quejas parecidas durante su lanzamiento [16], pero nueve semanas después algunos usuarios ya lo describían como el modelo estable que querían recuperar [17]. Cinco días de reacciones sirven para descubrir fallos posibles, aunque todavía no bastan para emitir un juicio definitivo.

¿Anthropic empeoró Opus en secreto? No encontré pruebas

No encontré pruebas de que Anthropic sustituyera en secreto los pesos de Opus. Aun así, la experiencia puede empeorar porque el tratamiento de las solicitudes, el harness del producto y el contexto de cada usuario cambian de manera independiente.

Pesos del modelo. Anthropic afirma que, desde Claude 4.6, los identificadores de API sin fecha apuntan a versiones fijas, por lo que no sustituye los pesos bajo el mismo identificador [18]. Ese sistema de versiones documentado hace poco probable una sustitución silenciosa de los pesos.

Tratamiento de las solicitudes. El enrutamiento, los clasificadores de seguridad y el uso de modelos de respaldo pueden cambiar aunque el identificador no lo haga. Anthropic documenta que algunas solicitudes de ciberseguridad marcadas y enviadas a Opus 5 pueden pasar a Opus 4.8, algo que también ocurrió en varias evaluaciones publicadas [1]. Por tanto, dos solicitudes al mismo modelo pueden recibir un tratamiento distinto. OpenAI se topó con su propia versión del problema del riesgo cibernético, que trato en qué confirmó OpenAI sobre Astra y por qué frenó el trabajo.

El harness del producto. El informe de Anthropic de abril de 2026 documenta tres regresiones de Claude Code que apenas afectaron a la API. El esfuerzo predeterminado pasó sin aviso de high a medium entre el 4 de marzo y el 7 de abril, mientras que un error de contexto eliminó repetidamente razonamientos anteriores después de periodos de inactividad entre el 26 de marzo y el 10 de abril. Del 16 al 20 de abril, un system prompt también limitó la longitud de las respuestas y redujo cerca de un 3 % el rendimiento en evaluaciones de código [19]. Los límites de uso pertenecen al mismo grupo: la cuota semanal más pequeña de Claude Code tras el fin de una promoción es un cambio de plan, no de modelo.

Tu propio contexto. Las instrucciones antiguas de CLAUDE.md, las memorias guardadas y una sesión larga también pueden cambiar el comportamiento. En ese caso, la versión del modelo es idéntica, pero la experiencia de trabajo no.

El empeoramiento descrito puede ser real y, a veces, reproducible, incluso cuando el diagnóstico es incorrecto. En muchos casos cambió el producto, la configuración o el contexto, no los pesos del modelo.

Anthropic usa el mismo reparto: Opus ejecuta y Fable asesora

Anthropic reparte el trabajo de una forma muy parecida a mi comparación entre empleado y jefe. Su herramienta Advisor combina un ejecutor más barato con un modelo más capaz que puede marcar la dirección, y la documentación presenta a Opus 5 como ejecutor y a Fable 5 como asesor.

El asesor puede leer la sesión actual, proponer un plan y corregir el trabajo durante la tarea, por lo que Anthropic lo recomienda para diseño, arquitectura y evaluación de riesgos. Debe ser al menos tan capaz como el ejecutor, pero pedir más consejos no siempre mejora el resultado: la documentación advierte que un exceso de consultas vuelve la tarea más lenta y cara [20].

responsable

• Tú objetivo, límites, criterios de aceptación

fija la dirección

dirección

• Fable 5 arquitectura, tareas acotadas

tareas acotadas

ejecución

• Opus 5 código, tests, verificación

implementación y resultados de pruebas

revisión

• Fable 5 revisión por hitos

Esta estructura asigna una responsabilidad clara a cada modelo. Tú defines el objetivo y los límites, Fable crea el plan y revisa los hitos importantes, y Opus implementa el trabajo acotado con un precio por token menor. Desde entonces he aplicado este reparto a funcionalidades grandes con varios agentes y lo he contrastado con Codex en mi comparación entre Claude y Codex en funcionalidades grandes.

La comparación tiene límites. Anthropic no considera que Opus sea incapaz de planificar, y Claude Code incluye un modo oficial opusplan en el que Opus planifica mientras Sonnet ejecuta [21]. Fable tampoco es un jefe perfecto. Su guía de prompting advierte que puede planificar demasiado, refactorizar sin permiso y convertir tareas pequeñas en grandes; explicar el motivo de un cambio ayuda a mantenerlo centrado [23].

Incluso con esos matices, Anthropic presenta los modelos de forma distinta. Recomienda Fable 5 cuando importa obtener la máxima capacidad y sitúa Opus 5 como la opción con mejor relación entre precio y rendimiento para agentes de programación complejos [10]. Durante el lanzamiento de Fable, afirmó que la ventaja de este modelo aumenta a medida que las tareas son más largas y complejas [22]. Cuando Anthropic lanzó después el siguiente Fable, comparé Fable 5.1 con Opus 5 en tareas largas de agentes y en precio.

Ese reparto también aparece en el análisis de Anthropic sobre unas 400 000 sesiones de Claude Code de aproximadamente 235 000 usuarios. Los humanos tomaron cerca del 70 % de las decisiones de planificación, mientras que los agentes asumieron alrededor del 80 % de las decisiones de ejecución. Los usuarios experimentados generaron de media unas 12 acciones del agente y 3200 palabras, frente a 5 acciones y 600 palabras entre los principiantes; la tasa de éxito verificada fue de alrededor del 15 % para los principiantes y de entre el 28 % y el 33 % a partir del nivel intermedio [24]. Un modelo más proactivo no elimina la necesidad de una dirección clara.

Cómo usaría Opus 5: acotaría la tarea y verificaría el resultado

Yo encargaría a Opus implementaciones acotadas y recurriría a Fable cuando la dirección no esté clara, para la arquitectura y para revisar cambios de alto riesgo.

Según los resultados y los informes de usuarios disponibles, hoy elegiría entre los modelos de esta manera. Es posible que cambie la tabla después de usarlos más directamente. Ese uso más directo está ahora en si Opus 5 es tan malo como dice internet.

Tarea	Modelo
Error claro con pasos de reproducción y una prueba	Opus 5
Funcionalidad acotada con criterios de aceptación	Opus 5
Refactorización hacia una arquitectura conocida	Opus 5, revisión posterior de Fable
Causa raíz poco clara entre varios sistemas	Plan de Fable 5, luego Opus 5
Arquitectura nueva que debe vivir años	Fable 5 primero
Sesiones largas con agentes en varios frentes	Fable 5 como orquestador
Migración de alto riesgo	Diseño con Fable, ejecución con Opus, auditoría con Fable

Antes de cambiar de modelo, yo ajustaría la configuración. Deja activado el thinking: es el valor predeterminado, el esfuerzo bajo con thinking funciona mejor que desactivarlo con un coste similar y, además, apagarlo puede causar un comportamiento extraño al llamar a herramientas [8]. Empieza con un esfuerzo menor y auméntalo cuando la tarea necesite más razonamiento, en vez de usar xhigh de forma predeterminada; Artificial Analysis encontró una gran diferencia entre los ajustes mínimo y máximo [2].

Para que la comparación sea justa, utiliza identificadores completos porque los alias pueden cambiar [21]. También eliminaría las instrucciones creadas para compensar los problemas de Opus 4.x antes de evaluar Opus 5 [8].

Partiría de este prompt de sistema en lugar de la antigua instrucción “sé minucioso y proactivo”:

Implement only the requested task.
Follow the existing architecture and conventions in the repository.
Do not redesign surrounding systems or refactor unrelated code
unless the acceptance criteria require it.

Before editing, state the concrete acceptance criteria.
Do not report the task as complete unless each criterion has been
verified against actual build, test, or tool output.

Do not create subagents for work you can do directly.
If you notice an unrelated problem, mention it at the end
without changing it. Keep progress updates short.

Ese prompt no convertirá Opus en Fable, ni debería hacerlo. Opus 5 funciona mejor cuando la tarea tiene límites y criterios de aceptación claros, porque puede entregar un resultado excelente por un precio menor. Si el objetivo no está claro, esa misma iniciativa puede producir trabajo adicional, suposiciones erróneas y afirmaciones falsas de que todo está terminado.

Por eso usaría Opus como empleado, no como jefe. Actualmente, Fable es mejor para establecer y revisar la dirección, pero el objetivo todavía tiene que venir de ti.