Claude Opus 4.6 realiza tareas de 12 horas, pero con solo un 50% de fiabilidad

Google News destacó una afirmación llamativa: Claude Opus 4.6 puede realizar trabajo con AI equivalente a casi 12 horas de esfuerzo humano. Sin embargo, el modelo alcanza esa marca con solo una tasa de éxito prevista del 50%.

Con un umbral de éxito del 80%, su horizonte medido se reduce a unos 70 minutos. Esa diferencia transforma un titular triunfalista en una historia más relevante sobre la fiabilidad de los agentes de AI. Un agente que termina la mitad de sus tareas no es un colega autónomo. Es un generador de borradores incierto cuyos fallos todavía requieren detección humana.

Las cifras provienen de METR, una organización de investigación independiente que evalúa si los agentes de AI pueden completar tareas de software de distintas duraciones. Anthropic lanzó Claude Opus 4.6 en febrero de 2026 y describió un mejor rendimiento en trabajo agéntico sostenido. Los resultados de METR respaldan esa dirección, al tiempo que revelan los límites ocultos tras la cifra más llamativa del titular.

Por tanto, el conflicto no es Claude frente a otro modelo. Es la autonomía tal como se comercializa frente a la autonomía que un equipo puede utilizar con seguridad. Para desarrolladores y compradores empresariales, 70 minutos fiables importan más que 12 horas especulativas.

Qué mide realmente el resultado de 12 horas de Claude

La cifra del titular describe la dificultad de la tarea, no 12 horas de operación autónoma ininterrumpida.

METR define un horizonte temporal de finalización de tareas como la duración que necesita un experto humano para realizar un trabajo que un agente de AI puede terminar con una tasa de éxito determinada. Un horizonte de 12 horas no significa que Claude permanezca activo durante 12 horas. Significa que las tareas evaluadas le llevarían aproximadamente ese tiempo a una persona cualificada.

La distinción importa porque los agentes de AI suelen ejecutar con éxito las tareas más rápido que sus referencias humanas. Pueden escribir varios bloques de código a la vez, buscar documentación rápidamente y evitar parte de la navegación manual. La duración humana funciona como una escala de dificultad, no como un cronómetro para el modelo.

El panel de horizontes temporales de METR estima el éxito ajustando una curva estadística a los resultados de los agentes. Su conjunto de tareas contiene más de 100 encargos orientados al software. Los investigadores ejecutan cada tarea varias veces y comparan los resultados con tiempos estimados de finalización humana.

El trabajo evaluado abarca principalmente ingeniería de software, aprendizaje automático y ciberseguridad. Las tareas están diseñadas para ser autocontenidas, claramente especificadas y calificadas automáticamente. Estas condiciones permiten realizar pruebas sistemáticas, pero difieren del trabajo diario dentro de una empresa.

Según se informa, Claude Opus 4.6 alcanzó un horizonte del 50% de unos 719 minutos, o casi 12 horas. Su horizonte del 80% fue de aproximadamente 70 minutos. La primera cifra genera un titular impactante, mientras que la segunda ofrece una señal más práctica para el despliegue.

Un horizonte del 50% predice éxito en solo la mitad de las tareas comparables. Esa tasa de fallo todavía puede ser útil cuando la verificación es rápida y los errores son baratos. Un desarrollador podría pedir a un agente que intente una refactorización difícil, inspeccionar el resultado y descartarlo si fallan las pruebas.

La misma fiabilidad sería inaceptable para una migración de producción sin supervisión. También sería inadecuada para cambios de seguridad cuyos errores permanecen invisibles hasta que ocurre un incidente. Una mayor capacidad para tareas largas tiene poco valor operativo cuando un equipo no puede reconocer el fallo de forma eficiente.

El umbral del 80% tampoco es perfecto. Implica que uno de cada cinco intentos comparables sigue fallando según el modelo ajustado. Sin embargo, acerca el sistema a un trabajo que puede recibir revisiones periódicas en lugar de supervisión continua.

Por eso el enfoque de Google News necesita contexto. Doce horas capturan el límite exterior de capacidad de Claude con una fiabilidad de cara o cruz. Setenta minutos describen mejor la duración a partir de la cual un usuario puede empezar a considerar una delegación limitada.

Incluso esa interpretación exige cautela. El resultado no demuestra que Claude pueda completar el 80% de todas las tareas de 70 minutos. METR explica que algunas tareas son sistemáticamente fáciles para un modelo, mientras que otras lo superan de forma constante. El porcentaje representa una expectativa ajustada en todo el conjunto de evaluación.

La pregunta práctica no es si el modelo ha superado una duración impresionante. Es si los usuarios pueden identificar qué encargos se sitúan dentro de su zona fiable antes de delegarlos.

Por qué los lectores de Google News deberían centrarse en la fiabilidad

La fiabilidad de los agentes de AI determina si horizontes más largos ahorran tiempo humano o simplemente lo trasladan a revisión y recuperación.

Una respuesta fallida de chat cuesta segundos. Una ejecución fallida de un agente puede modificar archivos, elegir la dependencia equivocada, interpretar mal los requisitos y construir trabajo adicional sobre un error inicial. El coste de los errores aumenta a medida que un agente recibe más herramientas y más libertad.

Esto crea un problema asimétrico. Las ejecuciones largas exitosas son fáciles de celebrar porque producen resultados visibles. Las ejecuciones fallidas pueden ocultar sus defectos en código verosímil, pruebas incompletas o un resumen confiado. El supervisor puede dedicar más tiempo a auditar un error pulido que a completar la tarea original.

Claude Opus 4.6 importa porque Anthropic lo posicionó explícitamente para flujos de trabajo agénticos más largos. El anuncio del modelo de la empresa afirma que planifica con más cuidado, trabaja de forma más fiable en bases de código grandes y detecta más de sus propios errores. Anthropic también introdujo una ventana de contexto de un millón de tokens en beta.

Una ventana de contexto es la cantidad de información que un modelo puede procesar durante una interacción. Más contexto permite a un agente inspeccionar repositorios más grandes y conservar historiales más extensos. No garantiza que el modelo razone correctamente sobre todo lo incluido en esa ventana.

El contexto largo y los horizontes de tareas largas resuelven limitaciones distintas. El primero se refiere a cuánto material puede consultar el modelo. El segundo estima la dificultad de una tarea que puede completar con un nivel de fiabilidad específico. Combinarlos amplía el espacio de trabajo disponible, pero no elimina el riesgo de ejecución.

La brecha de confianza se vuelve más clara en un escenario real de desarrollo. Imagine asignar a un agente una migración de base de datos que un ingeniero humano necesitaría casi un día entero para completar. El agente escribe scripts de migración, actualiza el código de la aplicación y modifica las pruebas.

Con una fiabilidad del 50%, el equipo no puede tratar el resultado como trabajo terminado. Un ingeniero debe revisar las suposiciones del esquema, el comportamiento de reversión, la preservación de datos y el orden de despliegue. Esa revisión puede acercarse al coste de realizar la tarea directamente.

Ahora considere un encargo más pequeño con una referencia humana de 70 minutos. El agente actualiza un componente definido, ejecuta pruebas y genera un conjunto de cambios compacto. Una tasa de éxito esperada del 80% sigue exigiendo revisión, pero la superficie de revisión es más limitada y los fallos son más fáciles de aislar.

La diferencia afecta tanto al diseño del producto como a la selección del modelo. Los sistemas de agentes útiles necesitan puntos de control, pruebas, límites de permisos y registros completos de los cambios realizados por el modelo. También necesitan una vía de escalamiento cuando aumenta la incertidumbre.

Esto hace que el contexto rastreable sea especialmente importante para el trabajo de conocimiento. Una base de conocimiento de AI con capacidad de búsqueda puede preservar requisitos, decisiones de reuniones y material fuente. No puede garantizar un razonamiento correcto, pero proporciona a las personas evidencia para revisar las conclusiones de un agente.

El benchmark actual también pone presión sobre los equipos que anuncian agentes como sustitutos de roles completos. La medición de METR no respalda esa interpretación. Un rol combina solicitudes ambiguas, contexto organizativo, negociación, juicio y responsabilidad a través de muchas tareas conectadas.

En cambio, el conjunto se parece a encargos claramente delimitados asignados a un trabajador con poco contexto. METR advierte específicamente que sus horizontes no deben equipararse al trabajo realizado por un empleado experimentado que conoce la historia de una empresa.

Esa advertencia cambia cómo los compradores deberían interpretar los titulares sobre AI. La unidad relevante no son las horas de trabajo nominal. Es el trabajo verificado completado por hora de atención humana.

La verdadera competencia es entre la autonomía de AI y la verificación humana

La limitación central ya no es si un agente de AI puede intentar trabajo prolongado, sino si las personas pueden verificar ese trabajo sin recrearlo.

Los horizontes de tareas más largos siguen siendo un progreso significativo. La investigación original de METR concluyó que los horizontes de los modelos de frontera crecieron exponencialmente durante varios años. Los investigadores atribuyeron la mejora, en parte, a un mejor razonamiento, uso de herramientas, fiabilidad y recuperación de errores.

Su estudio sobre tareas largas informó de un periodo histórico de duplicación de aproximadamente siete meses desde 2019. El análisis TH1.1 más reciente de METR encontró un intervalo de duplicación más corto, de 89 días, al ajustar solo modelos lanzados desde 2024.

Estas dos cifras describen ventanas temporales diferentes. La estimación reciente más rápida no elimina la tendencia histórica más prolongada. Sugiere una aceleración bajo un ajuste, sin resolver si ese ritmo persistirá.

La actualización TH1.1 también amplió el conjunto de 170 a 228 tareas. Más que duplicó el número de encargos que duran al menos ocho horas humanas, de 14 a 31. Las incorporaciones mejoraron la cobertura en el extremo largo, donde los modelos más nuevos estaban agotando el benchmark anterior.

Claude Opus 4.6 presionó directamente contra ese límite. Cuando un modelo tiene éxito en casi todas las tareas más cortas, la curva ajustada depende en gran medida del grupo más pequeño de encargos largos. Entonces, las estimaciones se vuelven más sensibles a la selección de tareas y a las suposiciones estadísticas.

METR reconoció este problema en un análisis de marzo sobre suposiciones de modelado. La organización afirmó que su conjunto se acercaba a la saturación y que los resultados recientes se habían vuelto más sensibles a las decisiones analíticas.

Eso no hace que el resultado de 12 horas carezca de sentido. Hace que la confianza en torno a una duración precisa de titular sea más débil de lo que el titular sugiere. La tendencia general hacia trabajo exitoso más prolongado sigue siendo más clara que la posición exacta de un modelo.

La tensión también explica por qué el 80% merece más atención. Un horizonte del 50% reacciona con fuerza a la frontera incierta donde éxitos y fallos están equilibrados. El horizonte del 80% se mantiene más cerca de la región donde el modelo ha acumulado más evidencia de éxito.

Aun así, el 80% no es un umbral universal de confianza. La tasa aceptable depende de la tarea y de su coste de verificación.

Un agente de programación puede intentar una funcionalidad bien probada porque las comprobaciones automatizadas detectan muchos errores. Un agente de investigación que resume documentos privados necesita citas porque omisiones sutiles pueden escapar a una prueba simple. Un agente que modifica controles de acceso exige una revisión más estricta porque un solo error inadvertido puede exponer sistemas sensibles.

Estas diferencias crean tres categorías prácticas de delegación.

El trabajo reversible y de bajo coste puede tolerar fallos frecuentes. Los ejemplos incluyen redactar casos de prueba, explorar opciones de implementación o producir un prototipo desechable. Una persona puede volver a ejecutar el agente o rechazar el resultado.

El trabajo de producción verificable necesita evidencia más sólida. Los ejemplos incluyen corregir un error localizado o actualizar un cliente de API documentado. Las pruebas, el análisis estático y la revisión de código pueden limitar el riesgo.

El trabajo de alto impacto y difícil de verificar necesita una fiabilidad mucho mayor. Las recomendaciones estratégicas, las decisiones de seguridad, el análisis jurídico y las operaciones de datos irreversibles no se vuelven seguras simplemente porque el agente haya trabajado más tiempo.

La industria suele condensar las tres categorías en la palabra "autonomía". Ese enfoque oculta el mecanismo que determina el valor real. Un agente resulta útil cuando es más fácil verificar su resultado que producirlo.

Por tanto, la marca de 12 horas representa capacidad sin certeza suficiente. La marca de 70 minutos representa un rango operativo más creíble, aunque sigue siendo inadecuado para trabajos críticos sin supervisión.

Esta es la inversión detrás del titular. La cifra más larga mide ambición. La cifra más corta mide confianza.

Lo que los números de Claude Opus 4.6 no demuestran

El resultado de METR no demuestra que Claude pueda automatizar una jornada laboral, sustituir a un desarrollador ni rendir igual de bien fuera de las tareas de software.

La primera limitación es la cobertura de dominios. La suite actual de METR se concentra en ingeniería de software, aprendizaje automático y ciberseguridad. Estos campos ofrecen entornos ejecutables y evaluaciones objetivas, lo que los hace especialmente adecuados para evaluar agentes.

Muchas tareas empresariales carecen de esas propiedades. Un análisis de mercado puede sonar convincente y, aun así, omitir una fuente decisiva. Un plan de ventas puede seguir cada paso solicitado y aun así malinterpretar al cliente. Una nota de política puede requerir un criterio que ninguna prueba automatizada puede calificar.

La segunda limitación es la definición de la tarea. Las asignaciones de los benchmarks son autocontenidas y, por lo general, cuentan con criterios claros de finalización. Los proyectos reales comienzan con requisitos incompletos, expectativas contradictorias de las partes interesadas y restricciones no documentadas.

Un modelo que tiene éxito tras recibir una especificación precisa no ha demostrado que pueda descubrir la especificación correcta. Los profesionales humanos dedican mucho tiempo a resolver esa incertidumbre antes de que comience la implementación.

La tercera limitación se refiere al contexto. METR compara agentes con expertos humanos que abordan las tareas sin la familiaridad organizativa de un empleado consolidado. Eso hace que el benchmark sea más comparable, pero limita la conclusión económica.

Un ingeniero con experiencia sabe por qué existe una solución alternativa extraña. Un gerente de producto recuerda qué promesa al cliente limitó una funcionalidad. Un responsable de seguridad entiende qué riesgo teórico ya ha aceptado la empresa. Esos hechos rara vez caben dentro de un ticket.

Las ventanas de contexto grandes pueden proporcionar más documentos, pero seleccionar el contexto adecuado sigue siendo difícil. Las decisiones antiguas pueden entrar en conflicto con las más recientes. Las excepciones informales pueden vivir en reuniones o mensajes privados. Más información puede introducir más evidencia irrelevante junto al material útil.

La cuarta limitación es la propia estimación ajustada. Un horizonte temporal resume tareas variadas en un único eje de duración. La duración de la tarea se correlaciona con la dificultad, pero dos asignaciones que requieren el mismo tiempo humano pueden plantear retos completamente distintos para un modelo.

Una puede requerir cambios repetitivos de código que un agente maneja bien. Otra puede depender de reconocer una restricción arquitectónica sutil. La misma duración no genera la misma probabilidad de fallo en ambas.

METR también advierte que las mediciones por encima de 16 horas no son fiables con su suite actual. La estimación de 12 horas de Claude se sitúa cerca de ese límite y su intervalo de confianza es amplio. Los lectores deberían tratar la estimación puntual como una región de incertidumbre, no como una garantía de servicio calibrada.

La quinta limitación es la dependencia del modelo y del andamiaje. Un andamiaje es el sistema de software que proporciona a un modelo herramientas, instrucciones, memoria y un ciclo para realizar acciones. Claude Code, Codex y otros sistemas de agentes pueden producir resultados distintos con el mismo modelo subyacente.

Los cambios en los prompts, los permisos de herramientas, los presupuestos de tokens y las políticas de reintento pueden afectar materialmente al rendimiento. El resultado de un benchmark para un agente configurado no se transfiere automáticamente a todos los productos que llevan el mismo nombre de modelo.

Por último, las tasas de éxito no revelan el coste humano de la supervisión. Un resultado del 50% puede tener valor comercial si los fallos son inmediatos y evidentes. Un resultado del 80% puede seguir siendo poco atractivo si cada resultado exige una auditoría experta.

METR ha sido inusualmente directo sobre estas salvedades. Su nota sobre limitaciones afirma que un horizonte del 50% no significa que los usuarios puedan simplemente delegar todas las tareas más cortas. Algunas asignaciones requieren tasas de éxito superiores al 98% antes de que la automatización resulte rentable.

Esa afirmación es el contrapeso más importante al titular de Google News. El benchmark mide una frontera en expansión, pero no certifica la preparación para el despliegue.

La propia documentación de seguridad de Anthropic proporciona otro límite necesario. Sus fichas de sistema presentan evaluaciones de capacidad y seguridad bajo condiciones de prueba específicas. Son divulgaciones valiosas, pero siguen siendo evaluaciones de un modelo, no garantías para todos los flujos de trabajo posteriores.

Los compradores empresariales deberían pedir evidencia a nivel de sistema. Eso incluye el modelo, el andamiaje del agente, las herramientas conectadas, los datos organizativos, los permisos y el proceso de revisión. La fiabilidad surge de la configuración completa.

Qué observar después del titular de Google News

La siguiente fase se decidirá mediante mejores pruebas de tareas largas, resultados de mayor fiabilidad y evidencia de despliegues supervisados en el lugar de trabajo.

La primera señal es la próxima expansión de la suite de tareas de METR. Claude Opus 4.6 ya está cerca de saturar partes del benchmark actual, especialmente en duraciones más cortas. Más tareas largas con sólidas líneas de base humanas reducirían la incertidumbre en torno a las estimaciones de frontera.

La calidad de esas incorporaciones importa más que el número bruto de tareas. Los investigadores necesitan asignaciones que sigan siendo autocontenidas y evaluables, a la vez que se parezcan a un trabajo con consecuencias. También necesitan suficientes intentos humanos para estimar los tiempos de finalización sin depender en gran medida de estimaciones de expertos.

Si las evaluaciones más recientes mantienen el horizonte de 12 horas en una suite más amplia, aumentará la confianza en la tendencia de capacidad. Si la estimación cae bruscamente, el titular actual parecerá más un artefacto de medición cerca del techo del benchmark.

La segunda señal es el avance en umbrales de éxito más estrictos. Un modelo que extiende su horizonte del 50% puede intentar trabajos más difíciles, pero no reduce necesariamente el riesgo operativo. El crecimiento en el horizonte del 80% demostraría que las tareas más largas se están volviendo resolubles de forma fiable.

Una señal aún más fuerte sería el rendimiento publicado con una fiabilidad del 90%, 95% o superior. Esos umbrales se alinean más estrechamente con los flujos de trabajo de producción, donde los fallos repetidos generan costes de revisión. También revelarían si las curvas de fiabilidad mejoran de forma uniforme o siguen siendo pronunciadas.

Por esa razón, la brecha entre el 50% y el 80% merece atención continua. Claude Opus 4.6 muestra una gran separación entre casi 12 horas y 70 minutos. Si los modelos futuros reducen esa brecha, la autonomía será más fácil de desplegar.

Si ambos horizontes aumentan mientras su separación sigue siendo amplia, la capacidad que acapara titulares seguirá superando a la capacidad fiable. Las plataformas de agentes dependerán entonces más de la verificación, los reintentos y los puntos de control humanos.

La tercera señal es la evidencia en el lugar de trabajo que mida resultados completados en lugar de resultados generados. Las organizaciones deberían seguir los cambios aceptados, los defectos que se escapan, el tiempo de revisión, la frecuencia de reversión y el porcentaje de trabajo de los agentes que requiere una revisión sustancial.

Estas medidas responden a la pregunta económica que los benchmarks no pueden resolver. ¿El agente reduce el esfuerzo total de los expertos tras la supervisión, o desplaza ese esfuerzo hacia la depuración y la validación?

Los despliegues controlados también pueden identificar qué categorías de tareas se transfieren más allá del benchmark. Un modelo puede rendir bien en asignaciones de programación aisladas, pero tener dificultades con cambios que afectan a todo el repositorio. Puede redactar análisis financieros de forma eficaz y, sin embargo, no localizar el supuesto interno decisivo.

Los mejores informes separarán la duración de la tarea de su tipo. También revelarán el andamiaje, los permisos, el proceso de revisión y la definición de fallo. Sin esos detalles, las afirmaciones sobre horas autónomas siguen siendo difíciles de comparar.

Los resultados competitivos aportarán contexto útil, pero las clasificaciones de modelos no deberían convertirse en la historia principal. El panel de METR ha medido sistemas de Anthropic, OpenAI, Google y otros desarrolladores. El liderazgo puede cambiar con cada lanzamiento y configuración de evaluación.

La competencia más profunda sigue estando entre una delegación más larga y una verificación asequible. Un modelo no se convierte en un trabajador autónomo cuando encabeza una tabla. Se vuelve útil operativamente cuando un equipo puede confiar en su resultado con un menor coste total de atención.

Para los desarrolladores, la respuesta inmediata debería ser una delegación calibrada. Asignen a los agentes trabajo acotado con pruebas de aceptación explícitas. Conserven registros, exijan resúmenes de los archivos modificados y restrinjan el acceso a sistemas que la tarea no necesita.

Para los compradores empresariales, las preguntas de adquisición deberían ir más allá de la inteligencia del modelo. Pregunten qué sucede tras un fallo parcial. Determinen si el sistema puede revertir cambios, citar evidencia, mostrar incertidumbre y escalar a una persona.

Para los trabajadores del conocimiento, la cifra de 70 minutos ofrece una expectativa más fundamentada. La IA puede llevar cada vez más una asignación definida a través de múltiples pasos. Aun así, necesita a una persona que enmarque la asignación, compruebe el resultado y asuma las consecuencias.

Esta división de responsabilidades cambiará a medida que mejore la fiabilidad. La evidencia no respalda abandonarla ahora.

El titular de Google News captó un hito real, pero su cifra más dramática no es la más útil. Doce horas muestran hasta dónde puede llegar Claude cuando el éxito y el fracaso están equilibrados. Setenta minutos muestran dónde la confianza empieza a volverse práctica.

Antes de entregar a un agente una jornada laboral completa, elijan una tarea con evidencia clara y un resultado reversible. Registren el tiempo humano dedicado a especificarla, supervisarla y revisarla. Después, comparen ese total con el flujo de trabajo original.

Si el agente ahorra atención tras la verificación, amplíen el límite con cuidado. Si la revisión consume el beneficio, un horizonte de modelo más largo no arreglará el proceso. La próxima noticia importante sobre IA no será solo otro récord. Será la prueba de que el trabajo fiable está alcanzando a los intentos impresionantes.