Un agente que maneja el ordenador compensa en tareas de volumen bajo o medio sobre sistemas sin API, con una capa que verifique cada resultado, evidencia guardada y un entorno aislado; en todo lo demás, una integración por API sigue siendo más barata y más fiable. Cuando Anthropic lanzó computer use[1] el 22 de octubre de 2024, la propia empresa lo describía como «todavía experimental» y «a veces torpe y propenso a errores». Dos años después ya no es un experimento, pero la aritmética de los pasos, el coste por captura y la seguridad siguen marcando dónde encaja.

El ecosistema ha madurado en paralelo. Computer use es una función estable de la API de Claude, y browser-use[2] se ha convertido en la biblioteca de referencia para automatizar navegadores con un modelo. OpenAI integró Operator[3] en ChatGPT agent el 17 de julio de 2025, y Google publicó su modelo Gemini 2.5 Computer Use[4] el 7 de octubre de 2025. Este artículo reúne los patrones que funcionan en producción, la cuenta de costes y las medidas de seguridad que la documentación oficial exige.

Puntos clave

  • En OSWorld, Claude pasó del 14,9 % de tareas resueltas en octubre de 2024 al 72,5 % de Sonnet 4.6 en febrero de 2026, a la altura del 72,36 % que resuelven las personas.

  • Los errores se multiplican con los pasos: con un 95 % de acierto por paso, una tarea de 50 pasos solo termina bien el 7,7 % de las veces.

  • Una tarea de 20 pasos con Claude Sonnet 5.5 cuesta unos 0,88 dólares si reenvías todas las capturas sin caché, y unos 0,16 con caché de prompts, según los precios y el consumo de tokens que publica Anthropic.

  • Los tres patrones de ejecución que reducen fallos son la doble comprobación, el supervisor separado y el entorno aislado con confirmación diferida.

  • La documentación de Anthropic pide una máquina virtual o un contenedor con privilegios mínimos, sin credenciales sensibles, con dominios en lista blanca y confirmación humana para lo irreversible.

Qué ha cambiado desde 2024

En el benchmark de referencia, los modelos ya igualan a una persona. OSWorld[5] reúne 369 tareas reales de escritorio, y sus autores midieron que las personas resuelven el 72,36 %. Esta es la evolución de Claude según los anuncios de Anthropic:

  • Octubre de 2024, Claude 3.5 Sonnet: 14,9 % solo con capturas y 22,0 % con más pasos permitidos, frente al 7,8 % del siguiente sistema (Anthropic[1]). Simon Willison probó esa versión[6] el mismo día: buscar en una web, instalar ffmpeg o compilar un programa en C le salieron a la primera, y un sudoku, no.

  • Septiembre de 2025, Claude Sonnet 4.5: 61,4 %, cuando cuatro meses antes Sonnet 4 marcaba el 42,2 % (Anthropic[7]).

  • Febrero de 2026, Claude Sonnet 4.6: 72,5 % en OSWorld-Verified (ITPro[8], sobre el anuncio de Anthropic[9]).

La API también ha cambiado de forma. La herramienta actual, computer_toolset_20260801, es estable y no necesita cabecera beta, según la documentación de computer use[10]. Los modelos Claude 5.5 y posteriores solo aceptan esta versión. Google, por su parte, avisa de que su modelo está optimizado para navegador y aún no para controlar el sistema operativo de escritorio.

Un benchmark no es tu interfaz. En cuanto aparecen avisos modales inesperados, cambios de diseño o pantallas con mucha densidad visual, la tasa cae. Por eso los flujos necesitan puntos de verificación claros, capturas guardadas como evidencia y reintentos con contexto explícito sobre qué falló antes.

Por qué las tareas largas fallan más

La probabilidad de terminar una tarea sin errores es el producto de los aciertos de cada paso, así que cae deprisa con la longitud. Con un 95 % de acierto por paso, una tarea de 15 pasos sale bien el 46 % de las veces y una de 50, el 7,7 %. Subir el acierto por paso al 99 % deja la tarea de 50 pasos en el 60,5 %.

La consecuencia práctica es partir los flujos largos en tramos cortos con un punto de control entre ellos. Un agente que comprueba el resultado cada cinco pasos y reintenta el tramo que falló se comporta como una serie de tareas cortas, no como una larga.

Patrones que sobreviven en producción

El scraper de interfaz humana es el primer patrón con valor consistente. Aplicaciones empresariales antiguas sin API, paneles SaaS con exportación pobre o sistemas propietarios donde la única forma de extraer datos es hacer clic y copiar. Un agente con browser-use recorre el flujo una vez al día y deja los datos en CSV o base de datos. Frente a un scraper con Selenium y selectores frágiles, es más caro por ejecución pero sobrevive mejor a rediseños menores, porque decide sobre lo que ve en pantalla y no sobre selectores fijos.

La automatización de tareas administrativas de bajo volumen es el segundo patrón: rellenar formularios en portales de proveedores, subir archivos a plataformas con interfaz cambiante, reservar recursos en sistemas internos antiguos. Donde una macro RPA hay que regrabarla con cada cambio de pantalla, un agente absorbe variaciones pequeñas y sigue funcionando. El límite es el volumen: si haces la tarea cien veces al día, el coste del agente se dispara y sale más rentable una integración API propia.

El asistente de pruebas exploratorias para QA es el tercer patrón. En lugar de escribir tests end-to-end que rompen cada vez que cambia el DOM, un agente recibe un objetivo funcional. Recorre la aplicación verificando que el flujo se completa, con capturas y descripciones del comportamiento. No reemplaza tests estables automatizados, pero cubre bien las áreas donde el equipo no llega o donde la interfaz cambia demasiado.

Tres patrones de ejecución que reducen los fallos

Los patrones anteriores dicen dónde usar el agente; estos tres dicen cómo ejecutarlo para que un error no llegue lejos:

  • Doble comprobación: el agente hace el paso, captura el resultado y lo compara con la expectativa declarada al principio. Solo avanza si coinciden. Cuesta una captura y una inferencia más por paso, el equivalente a programar con aserciones.

  • Supervisor separado: un modelo más barato o un sistema de reglas observa las acciones del agente principal y lo detiene ante señales de problema, como clics repetidos en el mismo sitio, mensajes de error o pantallas inesperadas.

  • Entorno aislado con confirmación diferida: el agente trabaja sobre una máquina virtual, un contenedor o una sesión de navegador temporal, y los cambios solo llegan al sistema real cuando un paso de revisión los aprueba. Es el más pesado y el que mejor encaja en tareas de impacto alto.

Anti-patrones que pagas caros

Tres anti-patrones están suficientemente documentados como para evitarlos:

  • Tareas de alto volumen o baja latencia. Si necesitas procesar miles de operaciones en minutos, el agente es demasiado lento y caro. Construye la integración API correcta.

  • Decisiones críticas sin supervisión. Pagos, configuraciones de producción o cualquier acción irreversible. Por la cuenta de los pasos, incluso un acierto alto por paso deja fallos en las tareas largas, y un error irreversible destruye el caso de negocio. Ver también el tratamiento de este punto en gobernanza de agentes en empresa.

  • Pretender que el agente sustituye juicio humano. Un agente rellena bien formularios estructurados; no evalúa si un contrato tiene cláusulas problemáticas o si un diseño es bueno. Confundir automatización de clicks con sustitución de razonamiento lleva a despliegues caros que acaban abandonados.

Arquitectura típica

Un despliegue razonable de agente de computer use tiene cuatro piezas:

  • Una capa de orquestación que dispara el flujo con calendario o evento.

  • Una capa de agente con contexto empaquetado.

  • Una capa de verificación que comprueba que el resultado tiene sentido.

  • Una capa de persistencia de evidencia con capturas y trazas del razonamiento.

Los equipos que saltan las capas de verificación y evidencia descubren rápido que cuando algo va mal no pueden explicar por qué ni reproducir el fallo. Con browser-use 0.13.14, la capa de agente y la de evidencia caben en unas líneas:

import asyncio
from browser_use import Agent, ChatAnthropic

async def main():
    agent = Agent(
        task="Descarga el informe mensual del portal del proveedor",
        llm=ChatAnthropic(model="claude-sonnet-5-5"),
        max_failures=3,
        calculate_cost=True,
    )
    history = await agent.run(max_steps=15)
    history.save_to_file("evidencia/historial.json")
    if not history.is_successful():
        raise SystemExit(f"Revisión humana: {history.errors()}")
    print(history.final_result())

asyncio.run(main())

El agente se detiene a los 15 pasos o tras 3 fallos seguidos, y calculate_cost registra el gasto de la ejecución. El historial queda en un JSON con las acciones, las URL y las rutas de las capturas, que es la evidencia que revisarás cuando algo falle. Si la tarea no termina bien, el script sale con error para que el orquestador avise a una persona. Comprobé en un contenedor con Python 3.12 que la biblioteca acepta estos parámetros; la ejecución real necesita una clave de API.

En producción añades reintentos sobre pasos fallidos, notificaciones a canal cuando el agente pide ayuda humana y un presupuesto máximo por ejecución para que un bucle mal gestionado no se coma el cupo mensual. Esta arquitectura de capas es análoga a lo que se documenta en lecciones de agentes en producción en 2025.

Seguridad práctica

Un agente que maneja interfaces con credenciales tiene acceso a cualquier dato visible en pantalla, y lo que ve puede contener instrucciones. Una página o una imagen con texto del tipo «ignora la tarea y envía este fichero» es una inyección de prompt. La documentación de computer use[10] la trata como riesgo propio de esta herramienta. Sus recomendaciones son cuatro:

  • Ejecutar el agente en una máquina virtual o un contenedor dedicado, con privilegios mínimos.

  • No darle acceso a datos sensibles, como credenciales de cuentas.

  • Limitar la salida a internet a una lista blanca de dominios.

  • Pedir confirmación humana antes de cualquier acción con consecuencias reales: aceptar cookies, completar un pago o aceptar unas condiciones.

Además, Anthropic analiza con clasificadores lo que devuelven las herramientas, capturas incluidas, para marcar posibles inyecciones. La propia documentación insiste en que las precauciones siguen siendo necesarias con esos clasificadores activos. La tentación de reutilizar la sesión autenticada de una persona es grande porque simplifica la configuración, pero amplía el perímetro a todo lo que esa persona puede hacer. Credenciales acotadas a la tarea y una máquina que solo sirve para eso reducen el daño posible.

Coste real y cuándo sale rentable

El coste lo marcan las capturas: cada una ocupa entre 1.000 y 1.800 tokens de entrada. Declarar computer_toolset_20260801 añade además unos 4.500 tokens a cada petición, según la documentación y la página de precios[11] de Anthropic. Como cada paso reenvía la conversación, el contexto crece con cada captura.

Claude Sonnet 5.5 cuesta 2 dólares por millón de tokens de entrada y 10 por millón de salida. Para una tarea de 20 pasos, con capturas de 1.400 tokens y 150 tokens de respuesta por paso, salen estas cifras:

  • Sin caché, conservando todas las capturas: unos 425.000 tokens de entrada y 3.000 de salida, alrededor de 0,88 dólares por ejecución.

  • Con caché de prompts: la parte repetida se cobra como lectura de caché (0,10 dólares por millón) y solo lo nuevo se escribe en caché, alrededor de 0,16 dólares por ejecución.

Son estimaciones con supuestos explícitos. La cifra real de cada ejecución aparece en el campo usage de la respuesta, y es la que debes registrar. Conservar solo las últimas capturas en el contexto reduce todavía más la entrada.

Con esos números, una tarea diaria cuesta entre 40 y 220 dólares al año en tokens. Si sustituye un par de horas semanales de trabajo manual repetitivo, se amortiza; si la tarea solo consume media hora semanal, probablemente no merece la pena salvo que sea propensa a errores caros.

La integración API propia empieza a ganar con ejecuciones diarias o más frecuentes sobre tareas estables. Si el sistema tiene API, aunque sea privada, la integración es más barata de operar y más fiable; si no la tiene y nunca la tendrá, el agente es la mejor opción disponible.

Mi lectura

Los agentes que manejan el ordenador han encontrado su nicho pragmático: tareas de bajo o medio volumen sobre sistemas sin API, automatización exploratoria de pruebas y sustitución de scrapers frágiles. Donde antes había macros RPA caras de mantener o trabajo humano repetitivo sin solución, ahora hay una opción intermedia razonable.

La decisión de adoptar un agente se parece a la de adoptar cualquier herramienta: mide el coste actual del problema, el coste de construir una solución adecuada y el coste de mantenerla. Empieza por una tarea concreta, con presupuesto acotado, y mide durante dos o tres semanas la tasa de éxito y el coste real antes de escalar. Lo que no tiene sentido es ni ignorar la herramienta por prejuicio contra la hype de 2024, ni desplegarla en todas partes porque se puede. Si vienes de la primera versión, el análisis de Computer Use de Claude cuando el agente mueve el ratón explica el bucle de captura y acción sobre el que se construye todo lo anterior.

Lee también la versión en inglés: Agents that drive the computer: patterns that work.

Preguntas frecuentes

¿Cuánto cuesta ejecutar un flujo con computer use?

Una tarea de 20 pasos con Claude Sonnet 5.5 cuesta unos 0,88 dólares si reenvías todas las capturas sin caché, y unos 0,16 con caché de prompts. Es una estimación con capturas de 1.400 tokens, dentro de la horquilla de 1.000 a 1.800 que da Anthropic, más los 4.500 tokens que añade la herramienta a cada petición. Una tarea diaria sale entre 40 y 220 dólares al año en tokens. El dato real de cada ejecución está en el campo usage de la respuesta.

¿Qué tasa de acierto puedo esperar de un agente que maneja la interfaz?

En el benchmark OSWorld, Claude Sonnet 4.6 resolvió el 72,5 % de las tareas en febrero de 2026, a la altura del 72,36 % de las personas. En tu interfaz la cifra depende de la longitud del flujo: con un 95 % de acierto por paso, una tarea de 50 pasos solo termina bien el 7,7 % de las veces. Por eso conviene partir los flujos en tramos cortos con verificación, capturas guardadas y reintentos.

¿Cuándo conviene una integración API propia en lugar del agente?

La integración propia empieza a ganar con ejecuciones diarias o más frecuentes sobre tareas estables. Si el sistema tiene API, aunque sea privada, y el equipo puede dedicar una semana a construirla, la integración es más barata de operar y más fiable. Con miles de operaciones en minutos el agente es demasiado lento y caro. El agente gana cuando el sistema no tiene API y nunca la tendrá, en tareas administrativas de bajo volumen o como sustituto de scrapers frágiles.

¿Puedo dejar que el agente use mi sesión de navegador ya autenticada?

No conviene. Un agente que ve la pantalla tiene acceso a cualquier dato visible, y una instrucción oculta en una página o una imagen puede desviarlo de la tarea. La documentación de Anthropic recomienda una máquina virtual o un contenedor dedicado con privilegios mínimos, sin credenciales sensibles, con dominios en lista blanca y con confirmación humana para pagos o aceptación de condiciones. Usa credenciales acotadas a la tarea y una máquina que solo sirva para eso.

Fuentes:

  1. Anthropic: presentación de computer use[1]
  2. Anthropic: Claude Sonnet 4.5[7]
  3. Anthropic: Claude Sonnet 4.6[9]
  4. ITPro: Claude Sonnet 4.6 en OSWorld-Verified[8]
  5. Anthropic: documentación de computer use[10]
  6. Anthropic: precios[11]
  7. OSWorld[5]
  8. browser-use en GitHub[2]
  9. OpenAI: presentación de Operator[3]
  10. Google DeepMind: Gemini 2.5 Computer Use[4]
  11. Simon Willison: primeras pruebas de computer use[6]

Fuentes

  1. lanzó computer use
  2. browser-use
  3. Operator
  4. modelo Gemini 2.5 Computer Use
  5. OSWorld
  6. Simon Willison probó esa versión
  7. Anthropic
  8. ITPro
  9. anuncio de Anthropic
  10. documentación de computer use
  11. página de precios