Benchmark web agéntico de AIM
Los agentes dependen de las interfaces web para completar tareas en la web. Para comparar la finalización de tareas entre interfaces web, creamos el Benchmark web agéntico de AIM y ejecutamos 100 tareas en 7 interfaces, 5 veces cada una, para obtener 3.500 resultados puntuados.
Tasas de éxito
Bright Data CLI y Bright Data MCP completaron 8.2 y 8.4 tareas más por cada 100 que Firecrawl MCP, la mejor de las otras cinco.
Diez tareas de ejemplo están en GitHub y la metodología explica cómo ejecutamos el benchmark.
Consistencia entre ejecuciones
Bright Data MCP tiene la mejor ejecución con 52 %. La diferencia entre la mejor y la peor ejecución en Oxylabs MCP es de solo 5 tareas en 5 ejecuciones. Es la interfaz más consistente del panel, seguida de:
- Bright Data CLI: 7
- Nimble MCP: 7
- Nimble CLI: 9
- Firecrawl MCP: 10
- ZenRows MCP: 11
- Bright Data MCP: 15
Coste y velocidad
Bright Data MCP es la interfaz más rápida con una mediana de 186 segundos por tarea, y las cinco herramientas MCP tuvieron medianas más bajas que ambas herramientas CLI. En el mismo proveedor, la CLI tardó 1.9 veces más que el servidor MCP en Bright Data y 3.3 veces más en Nimble. Nimble CLI es la más lenta con 830 segundos y reintentó 144 de sus 500 tareas tras los tiempos de espera, más que cualquier otra interfaz.
El coste total es el gasto en tokens del agente más la tarifa del proveedor. Nimble MCP tiene el total más bajo con $0,072 por tarea. En las dos interfaces de Bright Data y ZenRows MCP, que usan un navegador remoto facturado por ancho de banda, las tarifas del proveedor representan del 40 al 51 por ciento del total. La cifra de Firecrawl excluye las sesiones de navegador por minuto, por lo que es un límite inferior.
Motivos de fallo
Bright Data CLI se bloqueó en promedio 17.6 veces por cada 100 tareas, la menor cantidad del panel, mientras que Firecrawl MCP, Nimble MCP y Oxylabs MCP se bloquearon 1.7 a 2 veces más a menudo.
Nimble CLI fue la menos bloqueada entre las cinco interfaces que no son de Bright Data con 18.2, pero no devolvió nada en 28.4 tareas por cada 100, la mayor falta de entrega del panel, lo que refleja que alcanzó el límite de 30 minutos en el 36.3 por ciento de sus intentos (los intentos superan a las tareas porque las tareas agotadas se reintentaron una vez).
Añadir como fuente preferidaMetodología
Cada interfaz se ejecutó en su propio VPS. El agente fue OpenClaw ejecutando MiniMax M3 a través de OpenRouter, sin ejecuciones de tareas en paralelo. Cada servidor tenía 2 vCPUs y 2GB de RAM.
El conjunto de tareas utilizado fue idéntico para las siete interfaces en las 5 ejecuciones.
Antes de cada ejecución, una sonda obtenía una página de bajo coste a través de la cuenta del proveedor, y la ejecución se negaba a comenzar si esa obtención fallaba. Cada intento tenía 30 minutos.
Una tarea que se quedaba sin tiempo o devolvía menos de 500 bytes de salida tenía un reintento, excepto las cuatro tareas que cambian estado, que nunca se reintentaban porque un primer intento ya podía haber modificado un carrito. El reintento es el intento que se puntúa, y el coste y el tiempo del modelo provienen de él, incluso cuando también alcanzaba el límite.
Versiones utilizadas en este benchmark:
Tareas de ejemplo
Diez de las 100 tareas están publicadas íntegramente en GitHub, con la instrucción que se le dio al agente, el formato de salida, las reglas de aprobación y cómo puntuó cada interfaz.
Dataset
Las 100 tareas abarcan 29 sitios web en seis categorías. Seleccionamos los sitios web entre los 20 principales sitios de SimilarWeb por tráfico en cada categoría el 15 de mayo de 2026, comenzando por el principio de cada lista.
Omitimos los sitios que atienden a un único mercado fuera de EE. UU., las copias regionales de un sitio elegido, las aplicaciones de mensajería, los sitios que requieren iniciar sesión y los sitios sin listados públicos que buscar.
Preparamos de 2 a 5 tareas por sitio web según cuántas acciones admite el sitio. Noventa y seis tareas recuperan información y cuatro cambian el estado en el sitio remoto.
Evaluación
Cada tarea y sus condiciones de aprobación se escribieron en inglés. El evaluador lee el archivo de reglas y solo puntúa cuando se cumple cada regla que le aplica.
Bloqueado significa que el agente devolvió un mensaje de error en lugar de datos, por ejemplo, que el proveedor no pudo acceder al sitio o que no se mostró un desglose de tarifas en la página.
Evitado significa que el agente obtuvo la página directamente en lugar de usar la interfaz del proveedor, normalmente mediante una solicitud directa desde la consola. Encontramos estos casos en los registros de sesión. Una tarea evitada no obtiene nada y permanece en el total de 100 tareas.
Las celdas “No determinado” son aquellas en las que el evaluador no pudo decidir si la respuesta era correcta. Estas no se contaron ni como correctas ni como bloqueadas. Esto abarca de 8 a 18 tareas por interfaz y por ejecución, todas del mismo conjunto de 28 tareas.
Se utilizaron las mismas tareas, instrucciones y modelo en las siete interfaces, y las reglas se bloquearon antes de la primera ejecución.
Coste
El gráfico suma dos cifras. El coste del modelo es lo que el agente gastó en tokens, MiniMax M3 a través de OpenRouter a $0,30 por millón de tokens de entrada, $1,20 por millón de tokens de salida y $0,06 por millón de lecturas de caché, contado a partir del intento puntuado de cada tarea.
El coste de la interfaz es lo que el proveedor cobró por el mismo trabajo, promediado en cinco ejecuciones:
- Bright Data: se lee de la facturación de la cuenta por zona y por día. Scraping Browser cuesta $8 por GB más $0,10 por hora, Web Unlocker $1,50 por cada 1K solicitudes, SERP $1,50 por cada 1K.
- ZenRows: de su panel, el ancho de banda de la sesión del navegador más los créditos de fetch registrados. El plan es de EUR 129.99 por cada 1M créditos; el navegador equivale a unos 40.500 créditos por GB, y el fetch promedió 14 créditos por solicitud tras los multiplicadores de renderizado JS y proxy premium.
- Oxylabs: recuentos de solicitudes de las transcripciones del agente a $1,15 por cada 1K resultados.
- Firecrawl: créditos contados a partir de las transcripciones a $83 por cada 100K créditos, 1 crédito por scrape.
- Nimble: solicitudes contadas a partir de las transcripciones a $1,00 por cada 1K para extracción y $1,10 por cada 1K para búsqueda.
Limitaciones
Nimble CLI se quedó sin tiempo en el 36.5 por ciento de sus intentos.
Todas las interfaces tienen velocidades diferentes, por lo que no todas las tareas empiezan o terminan al mismo tiempo. Algunas tareas dependen de la fecha o de lo que aparece en ese momento, por lo que, en esos casos, algunos proveedores no vieron la misma página. Las reglas de aprobación se redactaron para evaluar el formato y la recuperación, no un listado concreto, de modo que una página cambiada no cambia la puntuación.
Cita esta investigación
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Kalelioğlu, Berk},
title = {{Benchmark web agéntico de AIM}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/agentic-web}},
note = {AIMultiple. Recuperado el 29 de septiembre de 2026}
}Resultados y marcas de tiempo de 16 puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 2 archivos CSV.
¿Quieres los datos granulares que hay detrás? Únete a Premium
El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]
A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.
Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.
Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.