Un equipo arma un agente que anda bien en el piloto. En producción empieza a fallar más, y nadie tocó nada. Alguien abrió un hilo sobre eso en un foro de agentes (la prueba 101).
Un comentarista hizo la cuenta. Si cada paso sale bien 90 % de las veces, un flujo de 5 pasos falla cerca de 41 %. La razón es que 0,9 elevado a 5 da cerca de 0,59.
90 % por paso, 41 % de falla en 5 pasos
Cuenta de un comentarista (0,9 elevado a 5 da cerca de 0,59). Prueba 101
Otro comentarista agregó que es un problema del sistema, y que más código solo no lo arregla.
La tesis que se juzga es la intuición que esa cuenta rompe: si cada paso acierta 90 %, el agente es confiable. En una demo ves el número por paso. En producción pagás el del proceso entero.
Confiabilidad, acá, quiere decir que el agente se comporte bien de forma sostenida, no una vez.
Detrás hay una apuesta más grande: el próximo modelo, más contexto o tareas más largas van a arreglar el problema. La apuesta tiene datos.
Los modelos completan tareas cada vez más largas, y eso sostiene la apuesta.
METR mide el horizonte temporal de los modelos: cuánto tarda una persona experta en las tareas que la IA resuelve con 50 % de éxito. Según su página de datos (la prueba 55), desde 2023 ese horizonte se duplica cada 128,7 días, unos 4,2 meses.
Claude Opus 4.5 llega a 293 minutos, con un intervalo de 162 a 624. El intervalo es el rango donde probablemente está el valor real.
Claude Opus 4.6, que salió después, llega a 719 minutos. Son tareas de software, aprendizaje automático y ciberseguridad.
Con un conjunto más grande, de 228 tareas (la prueba 47), la tendencia general casi no cambia. Si se mide desde 2024, la duplicación es todavía más rápida: 88,6 días. Leída así, el éxito por paso no es fijo: sube con cada generación de modelos, y con él el largo de las tareas.
La otra mitad de la apuesta es darle más material al modelo: si ve todo, decide mejor. Ninguna fuente de la base lo defiende con datos, pero la intuición es fuerte.
El éxito de la cadena es el éxito por paso multiplicado por sí mismo, una vez por paso. En otro hilo (la prueba 111), la cuenta sale con 95 % por paso:
Un proceso de 5 pasos sale bien 77 % de las veces.
Uno de 10 pasos sale bien 60 %.
Uno de 20 pasos sale bien menos de 36 %.
El autor de ese post concluyó que no se puede automatizar trabajo serio de forma rentable. Un comentario propuso medir el costo por resultado exitoso, el tema del capítulo 9.
La cuenta supone errores independientes, es decir, que cada paso falla sin importar lo que pasó antes. Los dos hilos son chicos y no traen datos de campo.
La cuenta también muestra la salida. Un paper sobre una tarea de un millón de pasos (la prueba 19) parte el trabajo en pasos mínimos. En cada paso votan varias respuestas hasta que una saca 3 votos de ventaja.
Así, un modelo chico y sin razonamiento completó las Torres de Hanoi con 20 discos. Fueron 1.048.575 pasos sin un error. Sin razonamiento quiere decir sin el modo que piensa antes de responder.
Sin el método, dicen los autores, “the process inevitably becomes derailed after at most a few hundred steps”. Es un preprint, un paper todavía sin revisión de otros expertos. Además, los pasos estaban definidos de antemano: es ejecución pura, no descubrimiento.
Si cada paso acierta 90 % de las veces, el agente es confiable.
Veredicto: No: los errores se multiplican. Con 90 % por paso, un flujo de 5 pasos falla cerca de 41 % de las veces. Con 95 % por paso, uno de 20 pasos sale bien menos de 36 % de las veces. Esa cuenta supone errores independientes. La contracara: un modelo chico partió la tarea en pasos mínimos y votó cada uno. Así completó 1.048.575 pasos sin un error.
Criterio
Calculá la confiabilidad del proceso entero: el éxito por paso elevado a la cantidad de pasos. Si no llega a lo que pide la tarea, acortá la cadena o poné una verificación entre pasos.
Por qué confianza media. La cuenta es aritmética y supone errores independientes. Los dos hilos de Reddit que la hacen son chicos. El paper del millón de pasos es un preprint (un artículo sin revisión de pares). Sus pasos estaban definidos de antemano: es ejecución pura, no descubrimiento. Ninguna fuente sostiene que 90 % por paso alcance.
Ver el detalle de las 3 pruebasOcultar el detalle0 a favor, 2 en contra, 1 matiza
Hilo sobre agentes que andan en el piloto y se degradan en producción. Un comentario hace la cuenta: con 90 % de éxito por paso, un flujo de 5 pasos falla cerca de 41 % de las veces. Pasa porque los errores se multiplican. Otro dice que es un problema del sistema y que más código solo no lo arregla.
Números
90 % por paso, 41 % de falla en 5 pasosCuenta de un comentarista (0,9 elevado a 5 da cerca de 0,59).
Limitación Hilo chico (6 puntos y 30 comentarios en el archivo). La cuenta es aritmética, sin datos de campo, y supone errores independientes. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“compounding errors is a systematic problem that you cannot code your way out of”
El post dice que el precio por token es la métrica equivocada, porque se paga igual si el resultado está bien o mal. La confiabilidad cae con el largo de la cadena de pasos, así que hay que sumar el costo de revisar. El autor concluye que no se puede automatizar trabajo serio de forma rentable. Un comentario propone algo más útil: medir el costo por resultado exitoso.
Números
77 %, 60 % y menos de 36 %Confiabilidad de un proceso de 5, 10 y 20 pasos con 95 % de acierto por paso, si los errores fueran independientes.
Limitación Hilo muy chico (2 puntos y 6 comentarios en el archivo) y el post promociona un artículo del autor. La cuenta es aritmética, no una medición. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“Cost per successful outcome seems like a far more useful metric than cost per token”
Meyerson, E., Paolo, G., Dailey, R., et al. arXiv (Cognizant AI Lab, UT Austin)
La otra cara de la confiabilidad compuesta: parten la tarea en pasos mínimos, cada uno a cargo de un microagente. En cada paso votan entre varias respuestas hasta que una saca 3 votos de ventaja, y descartan las que muestran señales de confusión. Así completan las Torres de Hanoi con 20 discos sin un solo error, con un modelo chico sin razonamiento. La salida no es un modelo más grande, sino descomponer y verificar cada paso.
Números
1.048.575 pasosLargo de la tarea resuelta sin errores, con gpt-4.1-mini.
cerca de 0,22 %Error por paso del modelo usado.
unos 3.500 dólaresCosto proyectado para 95 % de éxito; el paper no da el costo real de la corrida.
Limitación Preprint. Los pasos tienen que estar definidos de antemano y la estrategia se le da al modelo en cada prompt: es ejecución pura, no descubrimiento. El análisis supone errores independientes.
“the process inevitably becomes derailed after at most a few hundred steps”
Los 293 minutos no quieren decir que el agente puede trabajar solo casi cinco horas. Los autores de la métrica lo aclaran en una nota (la prueba 44). El horizonte dice cuánto trabajo humano resuelve la IA con 50 % de éxito.
En tareas de uso visual de una computadora, el horizonte es de 40 a 100 veces menor. En una tarea física real, hacer café, Claude 4.5 Sonnet tiene un horizonte de unos 2 minutos.
Para trabajo que necesita 98 % de éxito o más, un horizonte al 50 % no sirve como guía. Si se pide 80 % de éxito, el horizonte de Claude Opus 4.5 baja de 293 a 49 minutos.
Quién corrige también cambia la cifra. Otra nota de METR (la prueba 67) usó pull requests de agentes, es decir, pedidos de cambio de código. Esos cambios ya habían pasado el corrector automático de SWE-bench Verified.
Cuatro mantenedores de scikit-learn, Sphinx y pytest los revisaron. Cerca de la mitad no pasaba esa revisión.
Con mantenedores como jueces, el horizonte de Claude Sonnet 4.5 baja de unos 50 a unos 8 minutos. Los autores avisan que esa cifra es muy ruidosa.
Horizonte de Claude Sonnet 4.5 con el corrector automático y con revisión de mantenedores; los autores dicen que esta cifra es muy ruidosa.Prueba 67
Horizonte de tiempo, en minutos
Corrector automáticounos 50 minutos
Mantenedoresunos 8 minutos
0
Si un agente resuelve tareas de horas, ya le puedo delegar horas de trabajo.
Veredicto: No. El horizonte mide cuánto trabajo humano resuelve la IA con 50 % de éxito. No mide cuánto tiempo puede trabajar sola. Para Claude Opus 4.5 es de 293 minutos, con un intervalo de 162 a 624. Pero con 80 % de éxito baja a 49. En tareas de uso visual de una computadora es de 40 a 100 veces menor. Si juzgan mantenedores en vez del corrector, el de Claude Sonnet 4.5 baja de unos 50 a unos 8 minutos.
Criterio
Fijá el éxito que necesita la tarea antes de delegarla y medí al agente con ese umbral, en tu dominio. Partí el trabajo largo en tramos cortos, con un control al final de cada uno.
Por qué confianza media. Las fuentes de METR son primarias, pero son del mismo grupo. Tienen intervalos muy anchos y tareas de software, aprendizaje automático y ciberseguridad. Los autores dicen que la cifra con mantenedores es muy ruidosa. El costo cerca del límite sale de un hilo sobre un ensayo de 2025.
Ver el detalle de las 5 pruebasOcultar el detalle1 a favor, 2 en contra, 2 matizan
Página de datos de METR con el horizonte temporal 1.1. Mide el largo de las tareas que cada modelo resuelve con 50 % y con 80 % de éxito, en tiempo de una persona experta. La tendencia sigue siendo exponencial, y desde 2023 el horizonte se duplica más rápido que en el paper de 2025. Pero el horizonte con 80 % de éxito es entre 4 y 10 veces más corto que el de 50 %. METR avisa que por encima de 16 horas su medición ya no es confiable.
Números
128,7 días (intervalo de 104,4 a 158,0)Tiempo en que se duplica el horizonte al 50 %, contando desde 2023 (unos 4,2 meses). Desde 2019 es de 187,8 días. Excluye mediciones de más de 16 horas.
293 minutos (162 a 624) y 49 minutos (21 a 105)Horizonte de Claude Opus 4.5 con 50 % y con 80 % de éxito, con los datos corregidos el 3 de marzo de 2026.
719 minutos (317 a 3.634) y 70 minutosHorizonte de Claude Opus 4.6 con 50 % y con 80 % de éxito.
1.045 minutos (509 a 3.304) y 186 minutosHorizonte de Claude Mythos Preview (versión temprana, abril de 2026) con 50 % y con 80 % de éxito: unas 17,4 horas y 3,1 horas. Está por encima del techo de 16 horas que METR considera confiable.
352, 342 y 384 minutosHorizonte al 50 % de GPT-5.2, GPT-5.4 y Gemini 3.1 Pro.
Limitación Los números salen del archivo de datos de la página (benchmark_results_1_1.yaml). El 3 de marzo de 2026 METR corrigió un error de regularización, así que las cifras de 1.1 publicadas antes de esa fecha no coinciden. El 8 de septiembre de 2026 METR dijo que la página ya no se actualiza activamente. Son tareas de software, aprendizaje automático y ciberseguridad, y 50 % de éxito es un umbral bajo para delegar.
“Measurements above 16 hrs are unreliable with our current task suite.”
Nota de los propios autores de la métrica. El horizonte temporal no dice cuánto tiempo puede trabajar solo un agente. Dice cuánto trabajo humano reemplaza la IA con 50 % de éxito. La cifra cambia mucho según el dominio y no se traslada sin más al trabajo real, que es más desordenado.
Números
4 h 49 minHorizonte de Claude Opus 4.5, con un intervalo del 95 % que va de 1 h 49 min a 20 h 25 min.
de 40 a 100 veces menorHorizonte en tareas de uso visual de una computadora.
unos 2 minutosHorizonte de Claude 4.5 Sonnet en una tarea física real: hacer café.
Limitación Es una nota de los autores sobre su propia métrica, no un estudio aparte. La cifra de 4 h 49 min es una medición con la serie TH1. Con TH1.1, tras la corrección de METR, el mismo modelo da 293 minutos (ficha “Time Horizon 1.1”). Para trabajo que necesita 98 % de éxito o más, un horizonte al 50 % no sirve como guía.
Cuatro mantenedores de scikit-learn, Sphinx y pytest revisaron pull requests de agentes que ya pasaban el corrector automático de SWE-bench Verified. Cerca de la mitad no se integraría. En los modelos nuevos, las fallas se corrieron hacia la calidad del código más que hacia funciones rotas. Los autores aclaran que no prueba un límite de capacidad: el agente tuvo un solo intento, sin poder iterar con el revisor.
Números
24,2 puntosCuánto más da el corrector automático que los mantenedores, normalizado contra pull requests humanos (error estándar 2,7). Sin normalizar, 34,9 puntos.
296 pull requests de agentesRevisados, junto con 47 humanos de referencia, en 95 de los 500 problemas. Los mantenedores integraron cerca de 68 % de los humanos.
unos 50 contra unos 8 minutosHorizonte de Claude Sonnet 4.5 con el corrector automático y con revisión de mantenedores; los autores dicen que esta cifra es muy ruidosa.
Limitación Nota de investigación, no paper revisado. Cuatro mantenedores y tres repositorios. Modelos desde Claude 3.5 Sonnet hasta Claude Sonnet 4.5 y GPT-5.
“roughly half of test-passing SWE-bench Verified PRs”
METR amplió su conjunto de tareas y volvió a estimar el horizonte temporal. El horizonte es cuánto tarda una persona en las tareas que la IA resuelve con 50 % de éxito. La tendencia general casi no cambia, pero la de los últimos años es más rápida.
Números
228 tareas (antes 170)Tamaño del conjunto de tareas.
130,8 días y 88,6 díasTiempo en que se duplica el horizonte, midiendo desde 2023 (intervalo de 107 a 161 días) y desde 2024.
293 minutosHorizonte al 50 % de Claude Opus 4.5 tras la corrección de METR del 3 de marzo de 2026. El intervalo va de 162 a 624 minutos. El post de enero, anterior a la corrección, daba 320 (170 a 729).
Limitación El 3 de marzo de 2026 METR corrigió un error de regularización que cambió las mediciones. El post sigue mostrando las cifras de enero. La cifra de Claude Opus 4.5 de esta ficha es la corregida, tomada de la página de horizontes de METR. Un 50 % de éxito es un umbral bajo para delegar trabajo crítico. Los intervalos de confianza son muy anchos. De 31 tareas de 8 horas o más, solo 5 tienen una línea base humana medida. Son tareas de software, aprendizaje automático y ciberseguridad.
Hilo sobre un ensayo de Toby Ord que usa datos de METR para estimar el costo por hora de los agentes. Ese costo sube mucho cuando la tarea se acerca al límite de lo que el modelo puede hacer, justo donde más falla. El contrapunto más fuerte del hilo es que modelos abiertos más baratos completan el mismo conjunto de tareas por mucho menos.
Números
unos 350 dólares por horaCosto de o3 en su horizonte máximo, donde todavía falla cerca de la mitad de las veces.
306 puntos y 137 comentariosTamaño del hilo.
Limitación El ensayo es de 2025 y usa modelos de ese año. Se leyó el hilo en news.ycombinator.com y en la API pública de Algolia, no el ensayo completo. Las citas del hilo no se cotejaron palabra por palabra en la verificación de origen y por eso no se usan.
El contexto es todo lo que el modelo tiene delante al decidir: instrucciones, documentos, historial y resultados de herramientas. Un preprint de fines de 2025 (la prueba 7) probó cinco modelos con la información relevante ya recuperada entera. Aun así, el rendimiento cayó entre 13,9 % y 85 % a medida que crecía la entrada.
El efecto siguió cuando cambiaron el texto sobrante por espacios en blanco. El largo solo, sin distracción, ya daña.
Las herramientas también ocupan contexto. Según Anthropic (la prueba 23), 58 herramientas de 5 servidores MCP ocupaban unos 55.000 tokens antes de empezar.
MCP es un estándar para conectar herramientas a un modelo. Un token es más o menos una parte de una palabra.
Cuando el modelo buscó las herramientas a demanda, la precisión de Opus 4.5 subió de 79,5 % a 88,1 %. Es un anuncio de producto con evaluaciones internas.
Según el post de Fly.io (la prueba 16), pasado un umbral el sistema empeora sin aviso. Las salidas que funcionan sacan cosas del contexto.
En tareas largas, Anthropic encontró que compactar el historial no alcanzaba (la prueba 26). Compactar es resumir la conversación para que ocupe menos. Funcionó guardar el estado afuera, en un archivo de progreso y en commits de git.
Chroma, que vende búsqueda, va por el mismo lado: su subagente trabaja con un presupuesto fijo de tokens (la prueba 72). Un subagente es un agente que otro agente llama para una tarea parcial.
Cuanto más contexto le das al agente, mejor decide.
Veredicto: No: más entrada no garantiza mejor uso. Cinco modelos recuperaron toda la información relevante. Aun así rindieron entre 13,9 % y 85 % menos al crecer la entrada. Según un proveedor, 58 herramientas ocupaban unos 55.000 tokens antes de empezar. En sus evaluaciones, buscarlas a demanda subió la precisión de 79,5 % a 88,1 %. En tareas largas funcionó sacar el estado del contexto.
Criterio
Tratá el contexto como un presupuesto: poné solo lo que la decisión necesita y cargá las herramientas cuando hacen falta. En tareas largas, guardá el estado en archivos o commits, no en la conversación.
Por qué confianza media. El estudio del largo de la entrada es un preprint con cinco modelos, sin revisión de pares, y se leyó el resumen. Lo demás son posts de proveedores con casos propios y un ensayo de opinión. Uno de esos posts es de una empresa que vende búsqueda. Ninguna fuente defiende que más contexto sea siempre mejor.
Ver el detalle de las 5 pruebasOcultar el detalle0 a favor, 3 en contra, 2 matizan
Aun cuando recupera toda la información relevante, el modelo rinde peor a medida que crece la entrada. Pasa dentro del largo que dice soportar, y sigue si los tokens de más son espacios en blanco o están ocultos del todo. El largo solo, sin distracción, ya daña. Pedirle al modelo que repita la evidencia antes de resolver ayuda un poco.
Números
de 13,9 % a 85 %Caída del rendimiento al crecer la entrada, en 5 modelos abiertos y cerrados y tareas de matemática, preguntas y código.
hasta 4 %Mejora de GPT-4o en RULER al pedirle que repita la evidencia.
Limitación Preprint; se leyó el resumen. Cinco modelos.
“degrades substantially (13.9%--85%) as input length increases”
Anthropic suma tres funciones: buscar herramientas a demanda, llamarlas desde código y sumar ejemplos de uso a la definición. El código corre en un sandbox, un entorno aislado. Muestra que muchas definiciones de herramientas gastan contexto y bajan la precisión. Propone cargar las herramientas cuando hacen falta, no tener pocas.
Números
unos 55.000 tokensLo que ocupan 58 herramientas de 5 servidores MCP antes de empezar.
unos 8.700 contra 77.000 tokensContexto usado con búsqueda de herramientas y sin ella (85 % menos).
de 79,5 % a 88,1 %Precisión de Opus 4.5 en evaluaciones de MCP sin y con búsqueda de herramientas (Opus 4: de 49 % a 74 %).
Limitación Anuncio de producto del proveedor; las evaluaciones son internas.
Un agente es una llamada al modelo dentro de un bucle con herramientas, y escribir uno es simple. Lo difícil es manejar el contexto: pasado un umbral, el sistema empeora sin aviso. Conectar el agente con la realidad, para que no crea que resolvió algo que no resolvió, queda como problema abierto.
Números
1.070 puntos y 395 comentariosTamaño de la discusión en Hacker News (item 45840088).
Limitación El post no muestra autor ni fecha; la fecha es la de la discusión en Hacker News. Opinión, sin datos.
“Past a threshold, the whole system begins getting nondeterministically stupider.”
En tareas largas, cada sesión del agente empieza sin memoria, y compactar el contexto (resumirlo) no alcanza. Lo que funcionó fue guardar el estado fuera del contexto. Un agente inicial arma el entorno, un archivo de progreso, commits de git y una lista de funciones en JSON. Al principio, todas esas funciones fallan. Después, cada agente avanza de a una función y deja todo limpio. Fallas vistas: dar el proyecto por terminado antes de tiempo y marcar funciones como hechas sin probarlas.
Números
más de 200 funcionesTamaño del proyecto de ejemplo, con unos 5 pasos de prueba por función (modelo Opus 4.5).
Limitación Post del proveedor con un caso propio; no da tamaños de contexto ni tokens.
Bashir, H., Hong, K., Jiang, P., Shi, Z. Chroma, UIUC
El equipo que midió cómo el contexto largo empeora a los modelos entrena un subagente de búsqueda. El subagente puede borrar partes de su propio contexto y trabaja con un presupuesto fijo de tokens, para evitar ese deterioro. Después le pasa documentos a un modelo de frontera (de los más avanzados), que es el que responde.
Números
0,97 contra 0,95 y 0,99Tasa con la que encuentra la respuesta final con contexto acotado: Context-1 (versión 4x) contra gpt-5.2 y opus-4.5. El modelo base llega a 0,58.
20.000 millones de parámetrosTamaño del subagente.
Limitación Chroma vende búsqueda; los números son propios.
“we bound the context window to a fixed token budget”
Los modelos mejoran de verdad, y por eso crece el largo de las tareas que completan.Esperar al próximo modelo, en cambio, no arregla la cadena.
SlopCodeBench (la prueba 100) lo muestra donde más duele. Es una prueba estándar donde el agente extiende su propio código a medida que cambian los requisitos.
Ninguno de 15 agentes completó un problema de punta a punta. El mejor pasó 14,8 % de los controles.
14,8 %
Checkpoints que pasa el mejor de 15 agentes, en 36 problemas y 196 checkpoints. Prueba 100
El código de los agentes se vuelve más largo y más enredado en cada vuelta. Pedirle calidad en el prompt no frena la degradación.
La confiabilidad larga vino de otro lado. El millón de pasos sin error salió de partir la tarea y verificar cada paso, con un modelo chico.
Una comparación amplia de Google y otros encontró algo parecido (la prueba 31). Sin un punto de verificación central, los errores se propagan más.
Un estudio con 86 practicantes con agentes en producción (la prueba 29) da el mismo diagnóstico. La confiabilidad sigue siendo el desafío principal. Esos equipos la atacan con diseño: 68 % deja como máximo 10 pasos al agente antes de que intervenga una persona.
Un modelo mejor cambia qué controles hacen falta, pero no los vuelve innecesarios. Anthropic contó que, con Opus 4.6, pudo sacar piezas del arnés que había armado para Opus 4.5 (la prueba 70). Un arnés es el código que rodea al modelo y controla el recorrido.
Cada pieza suponía algo que el modelo anterior no podía hacer solo. Es un caso del proveedor, pero deja una tarea: cuando cambiás de modelo, revisás el arnés.
Una verificación en código entre pasos parte la cadena en tramos. Si un tramo falla, el código lo detecta ahí.
El tramo siguiente arranca desde un estado comprobado. Así, la multiplicación se aplica a cada tramo corto, no a la cadena entera.
Las fallas en tareas largas se van a arreglar con el próximo modelo, que va a ser más grande.
Veredicto: En parte. El horizonte con 50 % de éxito pasó de 293 minutos en Claude Opus 4.5 a 719 en Opus 4.6. Pero ninguno de 15 agentes completó un problema donde tenía que extender su propio código. El mejor pasó 14,8 % de los controles. La confiabilidad larga salió de partir la tarea y verificar cada paso, aun con un modelo chico.
Criterio
No esperes al próximo modelo para arreglar la cadena. Poné verificaciones en código entre pasos. Cada vez que cambies de modelo, revisá qué piezas del arnés (el código que rodea al agente) siguen haciendo falta.
Por qué confianza media. Los papers son primarios y coinciden en el mecanismo. Pero son preprints, sin revisión de pares, con benchmarks y tareas sintéticas, no despliegues reales. El horizonte de Opus 4.6 tiene un intervalo de 317 a 3.634 minutos. Que un modelo mejor permita sacar piezas del arnés es un caso propio de un proveedor. El estudio de producción confirma que la confiabilidad sigue siendo el desafío principal, con una muestra chica.
Ver el detalle de las 6 pruebasOcultar el detalle1 a favor, 2 en contra, 3 matizan
Página de datos de METR con el horizonte temporal 1.1. Mide el largo de las tareas que cada modelo resuelve con 50 % y con 80 % de éxito, en tiempo de una persona experta. La tendencia sigue siendo exponencial, y desde 2023 el horizonte se duplica más rápido que en el paper de 2025. Pero el horizonte con 80 % de éxito es entre 4 y 10 veces más corto que el de 50 %. METR avisa que por encima de 16 horas su medición ya no es confiable.
Números
128,7 días (intervalo de 104,4 a 158,0)Tiempo en que se duplica el horizonte al 50 %, contando desde 2023 (unos 4,2 meses). Desde 2019 es de 187,8 días. Excluye mediciones de más de 16 horas.
293 minutos (162 a 624) y 49 minutos (21 a 105)Horizonte de Claude Opus 4.5 con 50 % y con 80 % de éxito, con los datos corregidos el 3 de marzo de 2026.
719 minutos (317 a 3.634) y 70 minutosHorizonte de Claude Opus 4.6 con 50 % y con 80 % de éxito.
1.045 minutos (509 a 3.304) y 186 minutosHorizonte de Claude Mythos Preview (versión temprana, abril de 2026) con 50 % y con 80 % de éxito: unas 17,4 horas y 3,1 horas. Está por encima del techo de 16 horas que METR considera confiable.
352, 342 y 384 minutosHorizonte al 50 % de GPT-5.2, GPT-5.4 y Gemini 3.1 Pro.
Limitación Los números salen del archivo de datos de la página (benchmark_results_1_1.yaml). El 3 de marzo de 2026 METR corrigió un error de regularización, así que las cifras de 1.1 publicadas antes de esa fecha no coinciden. El 8 de septiembre de 2026 METR dijo que la página ya no se actualiza activamente. Son tareas de software, aprendizaje automático y ciberseguridad, y 50 % de éxito es un umbral bajo para delegar.
“Measurements above 16 hrs are unreliable with our current task suite.”
Orlanski, G., Roy, D., et al. arXiv (UW-Madison y otros)
El agente tiene que extender su propio código a medida que cambian los requisitos. Ningún agente resuelve un problema completo de punta a punta. El código del agente se vuelve más largo y más enredado en cada iteración, mientras el código humano se mantiene estable. Pedirle calidad en el prompt mejora el arranque, pero no frena la degradación.
Números
14,8 %Checkpoints que pasa el mejor de 15 agentes, en 36 problemas y 196 checkpoints.
77 % y 75,5 %Trayectorias en las que sube la erosión estructural y en las que sube la verbosidad del código.
2,3 y 2,0 vecesCuánto más verboso y más erosionado es el código del agente que el de 473 repositorios de Python de código abierto.
Limitación Se usan los números de la versión 2 (7 de mayo de 2026), que amplía el benchmark de 20 a 36 problemas y cambia los resultados. La versión 1 es del 25 de marzo de 2026. Se leyó el resumen. Mide calidad de código, no errores por paso.
Meyerson, E., Paolo, G., Dailey, R., et al. arXiv (Cognizant AI Lab, UT Austin)
La otra cara de la confiabilidad compuesta: parten la tarea en pasos mínimos, cada uno a cargo de un microagente. En cada paso votan entre varias respuestas hasta que una saca 3 votos de ventaja, y descartan las que muestran señales de confusión. Así completan las Torres de Hanoi con 20 discos sin un solo error, con un modelo chico sin razonamiento. La salida no es un modelo más grande, sino descomponer y verificar cada paso.
Números
1.048.575 pasosLargo de la tarea resuelta sin errores, con gpt-4.1-mini.
cerca de 0,22 %Error por paso del modelo usado.
unos 3.500 dólaresCosto proyectado para 95 % de éxito; el paper no da el costo real de la corrida.
Limitación Preprint. Los pasos tienen que estar definidos de antemano y la estrategia se le da al modelo en cada prompt: es ejecución pura, no descubrimiento. El análisis supone errores independientes.
“the process inevitably becomes derailed after at most a few hundred steps”
Compara un agente solo con un arnés de tres agentes (planificador, generador y evaluador) para construir aplicaciones completas. El arnés dio resultados claramente mejores, pero costó más de 20 veces. Los agentes que se califican a sí mismos son demasiado generosos. El evaluador separado también fallaba hasta que lo afinaron para ser escéptico y probar con una herramienta externa. Cada pieza del arnés supone algo que el modelo no puede hacer solo, y con un modelo mejor (Opus 4.6) sacaron piezas.
Números
20 minutos y 9 dólares contra 6 horas y 200 dólaresUn juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).
3 horas 50 minutos y 124,70 dólaresUna estación de audio digital con Opus 4.6 y el arnés simplificado.
Limitación Casos propios del proveedor, sin grupo de control sistemático.
“agents reliably skew positive when grading their own work”
Kim, Y., Gu, K., Park, C., et al. arXiv (Google y otros)
Es una comparación controlada y amplia entre un agente único y cuatro arquitecturas multiagente. El resultado depende de cómo es la tarea: coordinar varios agentes ayuda si la tarea se divide en partes y daña si es secuencial. Las arquitecturas sin verificación central propagan más errores.
Números
260 configuracionesCombinaciones de 6 benchmarks, 5 arquitecturas y 3 familias de modelos.
de +80,8 % a -70,0 %Cambio frente al agente único: de razonamiento financiero descomponible a planificación secuencial.
87 %Configuraciones de prueba donde su modelo elige la mejor arquitectura.
Limitación Son benchmarks, no despliegues reales. El modelo predictivo explica una parte modesta de la varianza (R² de 0,373). Cifras de versiones anteriores, como una amplificación de errores de hasta 17,2 veces, no se verificaron en la versión 3 y no se usan.
Estudio de casos y encuesta a profesionales que tienen agentes en producción. La mayoría evalúa con personas y no con benchmarks (pruebas estándar), y deja pocos pasos al agente antes de que intervenga alguien. La confiabilidad, es decir, que el agente se comporte bien de forma sostenida, sigue siendo el principal desafío. Los equipos la atacan con diseño del sistema.
Números
20 casos y 86 practicantesBase del estudio: 20 entrevistas en profundidad y una encuesta a practicantes de 26 dominios.
74 %Depende sobre todo de evaluación humana.
68 %Corre como máximo 10 pasos antes de que intervenga una persona.
70 %Usa modelos comerciales con prompts en vez de reentrenarlos.
Limitación Muestra chica y elegida por los autores; no representa a todas las empresas. Preprint.
“Reliability (consistent correct behavior over time) remains the top development challenge”
Medí la confiabilidad del proceso entero, no la del paso. Diseñá la cadena para que un error no se arrastre. En la práctica:
Fijá el éxito que necesita la tarea antes de delegarla, y medí al agente con ese umbral en tu dominio.
Calculá el éxito del proceso: el éxito por paso elevado a la cantidad de pasos. Si no llega al objetivo, acortá la cadena o poné una verificación entre pasos.
Verificá con código el estado real después de cada paso. No te fíes de que el modelo diga que terminó.
Tratá el contexto como un presupuesto: solo lo que la decisión necesita, y las herramientas cargadas cuando hacen falta.
En tareas largas, guardá el estado en archivos o commits, no en la conversación. Partí el trabajo en tramos cortos, con un control al final de cada uno.
Cada vez que cambies de modelo, revisá qué piezas del arnés siguen haciendo falta.
Ahora:
Tomá el agente o el flujo que más te preocupa.
Contá sus pasos y anotá cuántas veces sale bien cada uno en tus registros. Si no tenés ese dato, ese es tu primer hallazgo.
Cargá los números en la calculadora con el éxito que pide la tarea.
La revisión de diseño trae estos controles en su apartado de control del flujo. El plan de evaluación te ayuda a medir el éxito por paso con tareas reales.