- En la misma tarea de panel administrativo, el agente de visión manipuló la UI con capturas de pantalla y clics, mientras que el agente de API llamó al mismo handler de la aplicación mediante respuestas estructuradas, dejando a la interfaz como la única variable de costo
- Con el prompt base, el agente de API terminó la tarea en 8 llamadas, pero el agente de visión pasó por alto 3 reseñas pendientes que estaban debajo del área visible y solo aprobó 1 de 4
- Al agregar un UI walkthrough de 14 pasos, el agente de visión también completó la tarea, pero la ejecución tomó unos 14 minutos y alrededor de 500 mil tokens de entrada, y esa guía específica en sí misma implica un costo adicional de ingeniería
- En los resultados generales, con Sonnet la ruta de visión usó en promedio 53 pasos, 1003 segundos y 550,976 tokens de entrada, mientras que la ruta por API terminó con 8 llamadas, 19.7 segundos y 12,151 tokens de entrada, con mucha menos variación en costo y tiempo
- La brecha de costo surgió de la estructura de la interfaz más que del rendimiento del modelo, y si se generan endpoints HTTP automáticamente desde event handlers, como en Reflex 0.9, el cálculo de costos favorece la ruta de API estructurada en herramientas internas hechas directamente por el equipo
Objetivo del benchmark y configuración del experimento
- Se midió el costo del uso tipo navegador/computadora haciendo que el mismo panel administrativo fuera operado mediante un agente de visión y mediante una API estructurada
- Cuando un agente de IA debe operar una webapp que no ofrece API, el agente de visión tiende a convertirse en la opción predeterminada
- En equipos que tienen más de 20 herramientas internas, escribir una superficie MCP o REST para cada app se vuelve un proyecto de ingeniería aparte, por lo que muchos equipos eligen agentes de visión
- La app de prueba es un panel administrativo para gestionar clientes, pedidos y reseñas, basado en el modelo del demo react-admin Posters Galore
- Ambos agentes usaron la misma app en ejecución, el mismo Claude Sonnet, el mismo dataset fijo y la misma tarea, dejando a la interfaz como única variable
- La tarea consistía en encontrar, entre los clientes con nombre “Smith”, al cliente con más pedidos; luego encontrar el pedido pendiente más reciente de ese cliente; aprobar todas las reseñas pendientes; y marcar el pedido como enviado
- Esta tarea toca tres recursos e incluye filtrado, paginación, consultas entre entidades, lectura y escritura, por lo que se parece a una carga típica de trabajo en herramientas internas
Las dos rutas de ejecución
-
Ruta A: Vision agent
- Claude Sonnet usó browser-use 0.12 en modo visión para manipular la UI mediante capturas de pantalla y clics
-
Ruta B: API agent
- Claude Sonnet llamó directamente a los endpoints HTTP de la app en modo de uso de herramientas
- Cada herramienta se mapea a uno o más event handlers del estado de la app, usando las mismas funciones que invocan los clics de botones
- El agente recibe respuestas estructuradas en lugar de la página renderizada
Por qué el agente de visión falló con el prompt base
- Se ejecutó a ambos agentes con la misma tarea de seis oraciones
- El agente de API completó la tarea en 8 llamadas
- Listó las reseñas de clientes filtradas por estado pendiente
- Aprobó cada reseña
- Marcó el pedido como enviado
- Ambos agentes llaman la misma lógica de aplicación, pero el agente de API lee directamente respuestas estructuradas en vez de mirar páginas renderizadas
- Con el mismo prompt, el agente de visión solo encontró y aprobó 1 de las 4 reseñas pendientes antes de pasar al siguiente paso
- Las otras 3 reseñas estaban debajo del área visible en la página de reseñas, y el agente no tenía ninguna señal de que debía desplazarse
- Este fallo no surgió de un problema de razonamiento del modelo, sino de que la página renderizada no daba una señal de que no estaba mostrando todo
- El agente de API llama los mismos handlers que invoca la UI, pero la respuesta incluye el conjunto completo de resultados devuelto por el handler, no solo las filas actualmente renderizadas
- El agente de API no interpreta controles de paginación a partir de píxeles, sino que lee directamente información como “página 1 de 4 con 50 elementos por página”
Resultado al agregar una guía de UI de 14 pasos
- Para una comparación justa, el prompt de visión se reescribió como un UI walkthrough explícito
- Se nombraron los elementos de UI con los que el agente debía interactuar en cada paso, como entradas de la barra lateral, pestañas y campos de formulario
- El recorrido de navegación que antes el agente no lograba descubrir por sí mismo se escribió como 14 instrucciones numeradas
- Al proporcionar esta guía, el agente de visión completó la tarea
- Aun así, la ejecución tomó 14 minutos y consumió alrededor de 500 mil tokens de entrada
- Cada instrucción numerada no aparece reflejada en el conteo de tokens, pero representa un costo real de ingeniería
- Para desplegar un agente de visión en herramientas internas, hay que escribir prompts con este nivel de detalle o aceptar la posibilidad de que el agente omita tareas silenciosamente
Forma de ejecución y variabilidad
- La ruta por API se ejecutó 5 veces y la ruta de visión 3 veces
- La ruta de visión se limitó a 3 ejecuciones porque cada corrida tomó entre 14 y 22 minutos y consumió entre 400 mil y 750 mil tokens
- La ruta de visión mostró una varianza alta entre ejecuciones
- En las 3 corridas, el tiempo de reloj real fue de 749 a 1257 segundos
- Los tokens de entrada variaron de 407 mil a 751 mil
- La ejecución más corta tomó 43 ciclos y la más larga 68 ciclos
- En el bucle captura de pantalla → razonamiento → clic hay suficiente no determinismo como para que una sola ejecución no permita estimar un costo representativo
- La ruta por API no mostró esta variabilidad
- Sonnet usó exactamente las mismas 8 llamadas de herramienta en las 5 ejecuciones
- El número de tokens de entrada solo varió dentro de un rango de ±27 en las 5 corridas
- Como las respuestas estructuradas no le dan motivos al agente para desviarse, llama los mismos handlers en el mismo orden
Resultados generales
| Métrica | Vision agent (Sonnet) | API (Sonnet) | API (Haiku) |
|---|---|---|---|
| Pasos / llamadas | 53 ± 13 | 8 ± 0 | 8 ± 0 |
| Tiempo de reloj real | 1003 s ± 254 s, aprox. 17 min | 19.7 s ± 2.8 s | 7.7 s ± 0.5 s |
| Tokens de entrada | 550,976 ± 178,849 | 12,151 ± 27 | 9,478 ± 809 |
| Tokens de salida | 37,962 ± 10,850 | 934 ± 41 | 819 ± 52 |
- Las cifras son promedio ± desviación estándar muestral (n−1); en la ruta por API n=5 y en la ruta de visión n=3
- Los detalles completos de ejecución pueden revisarse en el repositorio
- Haiku no logró completar la ruta de visión
- El fallo se limita al esquema de salida estructurada de browser-use 0.12, que Haiku no pudo generar de forma estable ni en modo visión ni en modo solo texto
- En la ruta por API, Haiku completó la tarea en menos de 8 segundos y con menos de 10 mil tokens de entrada, siendo la configuración más barata de las probadas
Brecha estructural de costos
- La diferencia de costo surge directamente de la arquitectura
- Un agente que necesita ver para poder actuar siempre debe pagar el costo de ver, aunque el modelo mejore
- Un mejor modelo de visión puede reducir la tasa de error por captura de pantalla, pero no reduce la cantidad de capturas necesarias para llegar a los datos relevantes
- Cada renderizado es una captura de pantalla, y una captura de pantalla se convierte en miles de tokens de entrada
- Ambos agentes pasan por la misma lógica de aplicación
- Ambos hacen filtrado, paginación y actualizaciones de la misma forma que la UI
- La diferencia está en qué leen en cada paso
- El agente de visión lee píxeles y debe renderizar e interpretar todos los estados intermedios
- El agente de API lee respuestas estructuradas provenientes de los mismos handlers, y esas respuestas ya contienen los datos que la UI iba a mostrar
- Un mejor modelo puede reducir el costo por paso, pero no el número de pasos, porque eso lo determina la interfaz
Cómo cambia la decisión cuando baja el costo de ingeniería de API
- El benchmark pudo ejecutarse a bajo costo gracias a Reflex 0.9
- Reflex 0.9 incluye un plugin que genera automáticamente endpoints HTTP a partir de los event handlers de una aplicación Reflex
- El argumento estructural no depende de Reflex, pero Reflex permitió ejecutar la ruta por API sin un codebase separado
- El punto clave es qué se vuelve posible cuando el costo de ingeniería de una superficie API se acerca a cero
- Los agentes de visión siguen siendo adecuados para aplicaciones que no controlas directamente
- Productos SaaS de terceros
- Sistemas heredados
- Aplicaciones que no se pueden modificar
- En las herramientas internas que el propio equipo construye, el cálculo de costos pasa a inclinarse en sentido contrario
Alcance del experimento y advertencias
- Los resultados de visión se limitan al modo visión de browser-use 0.12; otros agentes de visión pueden comportarse de otra manera
- El runner de la ruta B convirtió los endpoints generados automáticamente en una pequeña superficie de herramientas REST de unas 30 líneas
- El agente ve esto como herramientas como
list_customersyupdate_order - El dataset es fijo y pequeño
- 900 clientes
- 600 pedidos
- 324 reseñas
- No se midió el comportamiento con datos a escala de producción
- El agente de visión se ejecutó mediante
ChatAnthropicde LangChain - El agente de API se ejecutó usando directamente el SDK de Anthropic
- Los conteos de tokens reportados corresponden a tokens de entrada sin caché
Materiales para reproducir
- El repositorio incluye la generación de datos semilla, el demo parcheado de react-admin, los scripts de ambos agentes y los resultados en bruto
1 comentarios
Comentarios de Hacker News
Aquí está cómo hacer caro que un agente navegue un sitio web: mover los elementos de la pantalla cuando se mueve el mouse, hacer que la UI solo funcione si se fuerza un movimiento natural del mouse, cambiar aleatoriamente desde JS las etiquetas de los botones cada vez que alguien visita, y obligar a hacer scroll hasta el fondo para verificar tareas adicionales ocultas
Espera, esto se parece a una típica app SaaS empresarial
Es interesante y también un poco deprimente ver que no tenían voluntad de hacer esto por los humanos, pero como la IA lo necesita, todos corren a hacerlo. Al final, parece que solo lo hacen para la IA porque sienten que eso los beneficia personalmente más que alguien abstracto del futuro
[0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
No era la era de la IA generativa, pero para operar la app y exportar datos hubo que combinar OCR, entrada de usuario simulada y captura de impresión. Si los desarrolladores hubieran sabido del API de DRM de Windows que bloquea capturas de pantalla, o que es fácil recuperar texto de archivos PostScript con formato mínimo, no sé qué habrían hecho
Irónicamente, el proceso anterior a reemplazar esto consistía en dar a mano de obra barata en el extranjero acceso remoto de solo lectura a todos los datos del sistema, lo cual era un riesgo de seguridad mucho peor que automatizar el trabajo con una herramienta local de un proveedor confiable por parte de personal autorizado y sin acceso a la red
Estoy construyendo algo que resuelve exactamente este problema[1]
Todavía no lo mostramos en la landing page, pero en esencia le damos al agente un pequeño conjunto de herramientas para explorar la superficie de la app y, en particular, el API de funciones de macOS relacionadas con accesibilidad
Después de que el agente explora la app, puede escribir un workflow repetible, y luego ejecutarlo desde la CLI como
invoke chrome pinTabLa razón para usar accesibilidad es que, al final, es un buen DOM para apps. No todas las apps lo implementan perfectamente, pero suficientes sí, así que resulta muy útil
[1] https://getinvoke.com - la landing page actual está dirigida a creadores, así que todavía no cubre este caso de uso
Puedes ver cómo las celdas verdes podrían guiar a un LLM para que solo lea una parte específica de la pantalla o use OCR, cuánto texto ya viene incluido por defecto en el motor de accesibilidad, y cómo esto podría llevar no solo a MCP sino también a generadores de código que creen y ejecuten scripts propios para rastrear la capa de accesibilidad de un workflow
Me parece un terreno muy fértil. Los grandes laboratorios tienen que usar enfoques que funcionen en múltiples plataformas y workflows arbitrarios, y la visión de pantalla completa es el mínimo común denominador. Los enfoques específicos por plataforma son un espacio abierto realmente interesante
Aunque sí habría que garantizar que no se compartan workflows que extraigan información del usuario, como contraseñas
El gran problema es que demasiadas apps exponen estos elementos de manera terrible. Mi enfoque era usar UIAccess o una pasada única de un modelo de visión para crear plantillas de UI: https://github.com/willwade/app-automate?tab=readme-ov-file#...
El contraargumento de reddit es que, en la práctica, la experiencia tiende a ser casi la contraria. UIA se ve uniforme en la documentación, pero WPF, WinForms y Win32 exponen patrones de control distintos, así que al final terminas usando handlers por toolkit. En Qt, QAccessible tiene que compilarse y el plugin de accesibilidad debe cargarse en runtime para que exponga algo, y en los binarios distribuidos casi nunca pasa eso. Electron es igual de opaco en Windows que en macOS, porque al final el mismo Chromium dibuja sobre canvas. La verdadera división no es sistema operativo contra sistema operativo, sino toolkit nativo contra todo lo demás
Decir que escribir una superficie MCP o REST para cada app es un proyecto de ingeniería aparte no necesariamente sería así si el backend estuviera lo suficientemente separado del frontend y las tareas del lado del servidor hubieran sido diseñadas con cuidado y de forma general
Me pregunto si se podría hacer que un agente de visión “mapeara” la UI y luego exponerla a otros agentes como un conjunto de interfaces que se parezcan más a una API
Entiendo que ahora mismo un agente de visión tiene que saber tanto que “siguiente página” muestra más resultados como que en primer lugar necesita traer más resultados
Si un agente explorara solo la UI en un entorno de prueba o algo así y produjera una descripción algo estructurada de varios elementos y acciones de la UI, y luego otro agente recibiera esa descripción, me pregunto si le iría mejor que a un agente que tiene que explorar la UI y ejecutar la tarea al mismo tiempo
Por ejemplo, “traer todas las reseñas” podría definirse como ir a cada página y hacer clic en “ver reseña completa” para cada resumen de reseña, mientras que “ir a cada página” podría definirse como comenzar desde la página 1, que es el valor predeterminado de la pestaña de reseñas, y pulsar “siguiente” hasta que desaparezca el botón
Entonces el segundo agente podría reducir el razonamiento sobre cómo explorar, porque ya tendría esa técnica, y el primer agente solo tendría que explorar la UI una vez en el entorno de prueba sin preocuparse por equivocarse. Puede que haya entendido totalmente mal el post, pero igual me parece interesante
Al final hay que abrirse paso entre HTML/CSS/JavaScript complejos. Para bien o para mal, no es raro que una sola web app pese entre 5 y 10 MiB
En vez de abordar esto “de abajo hacia arriba”, casi como haciendo ingeniería inversa de lo que hace el motor del navegador, parece más fácil abordarlo “de arriba hacia abajo”, viendo la representación visual como lo haría un humano
Para la exploración todavía quedaría un poco de trabajo de visión, pero sería una tarea visual sencilla que no requeriría pensar
Imagen→imagen sí usa la imagen completa
No entiendo bien la premisa. Si es una app interna, ¿por qué sacar el uso de computadora y no hacer que el agente cree una CLI o MCP?
Obviamente el uso de computadora es peor. Es el último recurso. No debería usarse cuando se trata de estado que está en una DB que es mía
Más bien me impresiona que solo sea 50 veces peor
Totalmente de acuerdo. Hace poco, mientras construía una herramienta visual de IA, experimenté con ambos enfoques, y la latencia y el costo del uso genérico del navegador “tipo agente” son mortales para apps de consumo en tiempo real hoy en día
Con APIs estructuradas, incluso solo con una cadena de llamadas a LLM usando un esquema JSON estricto, no solo sale 40 veces más barato, sino que de verdad es lo que permite lanzar un producto estable. El uso de computadora es una demo genial, pero lo que paga los costos del servidor es el API estructurada
Si crees que un LLM sirve para algo, construyes encima de Openrouter un middleware bien definido y muy determinista para ese propósito
Las APIs estructuradas requieren pensamiento real, y hoy en día pensar no está bien visto
Hace unos meses hice una CLI desktopctl para controlar apps GUI inspirada en
kubectlEn Mac, combina OCR y el API de Accessibility para representar la UI en Markdown y exponer acciones de mouse y teclado
La idea central es que el bucle de reconocimiento “rápido” optimiza completamente en local, con GPU, la tokenización de la UI y la detección de cambios, mientras que el bucle de control “lento” necesita ida y vuelta con el LLM y usa una interfaz Markdown eficiente en tokens para la salida de la CLI
Como los controles usan identificadores relativamente estables, el agente puede automatizar acciones generales como
desktopctl pointer click --id btn_savesin necesitar el bucle de tokenización de la UIhttps://github.com/yaroshevych/desktopctl/tree/main
Las buenas apps exponen bien la información y están optimizadas para hacer clic, escribir, etc.
Las mejores GUI aprovechan muy bien la memoria muscular, así que son candidatas perfectas para automatizarse desde una CLI. Por ejemplo, una secuencia simple como “abrir la app Notes, presionar Cmd+F, escribir el término de búsqueda, leer la lista de resultados” puede convertirse en un único comando Bash que invoque un agente de IA
Siempre he sido escéptico con todo el concepto de “uso de computadora”. Es como contratar a alguien, dejarlo entrar a tu casa y decirle que puede dormir en tu cama, usar tu baño, comerse la comida del refri, ver la TV y que la clave de la caja fuerte también está por ahí
Solo que esa persona que contrataste es un mono
Los sitios web que hoy intentan bloquear Claude Code u otros agentes de IA están librando una batalla perdida
El uso de computadora está en una fase temprana, y parece que lo que impide su masificación es la cantidad de tokens necesaria. Si un agente prueba en vano 10 comandos de CLI antes de encontrar el correcto, casi no nos importa
Pero con agentes visuales como el uso del navegador o de la computadora, aunque eventualmente lleguen al lugar correcto, no tenemos paciencia para esperar 20 minutos a que hagan clic en un botón. Si los tokens se vuelven más baratos y rápidos, es muy posible que aparezcan modelos que usen interfaces UI con la misma naturalidad que una CLI