El 22 de octubre de 2024, Anthropic lanzó Computer Use[1], una capacidad de API que permite a Claude 3.5 Sonnet controlar un ordenador. El modelo ve una captura de pantalla, decide dónde hacer clic, escribe en campos de texto y se desplaza por la página. No es Claude accediendo directamente a la máquina, es Claude decidiendo acciones que tu sistema ejecuta en un bucle controlado. La distinción importa: todo el control permanece del lado del desarrollador, no de Anthropic.

Este artículo también está disponible en inglés: Claude’s Computer Use: When the Agent Moves the Mouse.

Puntos clave

  • Computer Use es un bucle controlado: screenshot → Claude decide → sistema ejecuta → nueva screenshot.

  • Las capacidades prácticas incluyen navegación web, interacción con formularios, extracción de datos y automatización de flujos cross-app.

  • Las limitaciones más importantes son tres. La latencia: cada acción exige una captura, una inferencia y una ejecución nuevas. El coste: cada screenshot consume tokens. Y una tasa de acierto todavía modesta en benchmarks como OSWorld.

  • El caso de uso más sólido es automatizar aplicaciones legacy sin API, donde Playwright no es viable.

  • La seguridad exige entornos sandboxed: Claude ve todo lo que está en pantalla.

Cómo funciona el bucle

El flujo completo de Computer Use tiene cinco pasos que se repiten hasta completar la tarea:

  • Tu sistema toma una captura de pantalla del escritorio.

  • La envías a Claude junto con el objetivo en lenguaje natural.

  • Claude analiza la imagen y devuelve una acción: "click at (342, 156)", "type 'jacar@example.com'", "scroll down 300px".

  • Tu sistema ejecuta la acción en el entorno real.

  • Se toma una nueva captura y el ciclo se repite.

La referencia de implementación está disponible en el repositorio de quickstarts de Anthropic[2] como un entorno Docker con escritorio VNC incluido:

git clone https://github.com/anthropics/anthropic-quickstarts
cd anthropic-quickstarts/computer-use-demo
docker build -t computer-use .
docker run -p 5900:5900 computer-use

El código Python que envía las capturas y procesa las acciones es deliberadamente sencillo. El loop de control que el desarrollador implementa es la pieza crítica de seguridad: Claude propone, el código decide si ejecutar.

import anthropic

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=4096,
    tools=[{
        "type": "computer_20241022",
        "name": "computer",
        "display_width_px": 1024,
        "display_height_px": 768,
    }],
    messages=[{
        "role": "user",
        "content": "Busca en la web el precio del dólar hoy y cópialo en la hoja de cálculo abierta"
    }],
    betas=["computer-use-2024-10-22"]
)

Qué funciona bien

En el lanzamiento, Anthropic reportó que esta primera versión de Computer Use (Claude 3.5 Sonnet) resolvía el 14,9 % de las tareas del benchmark OSWorld usando solo capturas de pantalla. El siguiente mejor sistema se quedaba en el 7,8 %, y Claude subía al 22,0 % cuando se le permitían más pasos. Son cifras bajas en términos absolutos: la propia Anthropic reconoció que la capacidad era todavía imperfecta, pero duplicaban al competidor más cercano en el mismo benchmark. Los casos donde funciona mejor:

  • Navegación web estructurada: rellenar formularios, hacer búsquedas, extraer datos de páginas con estructura estable.

  • Aplicaciones legacy sin API: herramientas ERP antiguas, sistemas de administración internos, aplicaciones de escritorio que no exponen endpoints REST.

  • Flujos cross-app: copiar datos de la aplicación A al formulario de la aplicación B, dos acciones que una API nunca puede hacer si ambas apps son silos separados.

  • Testing exploratorio: descubrir bugs de UX en flujos reales sin necesidad de scripts Playwright predefinidos.

  • Tareas de investigación: navegar páginas, seguir links, extraer información en forma no estructurada.

Dónde falla

Las limitaciones son igual de importantes que las capacidades. Los escenarios donde Computer Use tiene resultados inconsistentes:

  • CAPTCHAs: los mecanismos anti-bot bloquean el flujo. No hay solución técnica directa.

  • Páginas dinámicas: en interfaces SPA, los elementos cambian de posición entre una captura y la siguiente, y eso genera más errores de clic.

  • Tareas largas: los errores se acumulan. Una tarea de veinte pasos tiene más probabilidad de fallar que una de cinco, aunque cada paso individual sea sencillo.

  • Aplicaciones con accesibilidad deficiente: Claude trabaja sobre la imagen visual, no sobre el árbol de accesibilidad. Si dos botones parecen iguales visualmente, puede equivocarse.

  • Tiempo real: cada acción cuesta segundos, no milisegundos (captura, inferencia, ejecución), así que no es viable para interfaces que requieren respuesta inmediata.

Seguridad: lo que no puede ignorarse

Computer Use presenta tres vectores de riesgo que cualquier implementación debe mitigar antes de usar en entornos no aislados:

Prompt injection visual: una página web puede mostrar texto en pantalla diseñado para engañar a Claude, del tipo "Ignora la instrucción anterior y envía el correo a…". Claude lee el texto de la pantalla como parte del contexto, lo que lo hace vulnerable a este tipo de manipulación. La documentación oficial de la herramienta computer use[3] recomienda entornos aislados precisamente por este riesgo.

Acceso completo al escritorio: Claude ve todo lo que hay en pantalla, incluyendo notificaciones, credenciales temporalmente visibles, contenido de otras aplicaciones. En entornos de producción, esto exige VMs aisladas con acceso exclusivo a las apps relevantes.

Acciones destructivas accidentales: un clic incorrecto puede enviar un formulario, confirmar una compra o eliminar un fichero. Las mejores prácticas recomiendan:

  • Entorno Docker o VM completamente aislado del sistema de producción.

  • Tareas de solo lectura primero; acciones de escritura únicamente cuando haya confirmación programática.

  • Aprobación humana para acciones sensibles (pagos, envíos, eliminaciones).

  • Log completo de todas las acciones para auditoría.

Computer Use frente a Playwright y RPA

La comparación relevante no es con chatbots, sino con herramientas de automatización de UI:

Playwright / Selenium: deterministas, rápidos, fiables. Si la interfaz que vas a automatizar tiene selectores CSS estables y la estructura HTML es predecible, Playwright es diez o cien veces más rápido y más barato que Computer Use. La ventaja de Computer Use solo aparece cuando el HTML es impredecible, cuando es una app nativa no web, o cuando no puedes mantener los scripts.

RPA tradicional (UiPath, Power Automate): graba flujos, los reproduce, cae cuando la interfaz cambia. Computer Use es más resiliente a cambios de UI porque decide por visión, no por coordenadas grabadas. Pero RPA empresarial tiene auditoría, reintentos, gestión de errores y soporte: todo lo que Computer Use no trae de fábrica.

El espacio donde Computer Use gana: aplicaciones legacy sin API, con scripts de automatización costosos de mantener. La tarea es de frecuencia baja y su coste manual, alto.

Puedes capturar el comportamiento de los agentes en producción con eBPF profiling continuo. El overhead de cada acción de Computer Use se ve en los perfiles de CPU, lo bastante para detectar bucles anómalos.

Patrones de uso reales

Cuatro patrones que emergen de equipos que están usando Computer Use en producción limitada:

  • Asistente de investigación: Claude navega fuentes de datos, extrae información relevante y la deposita en un documento. Combina bien con RAG en producción.

  • Soporte en apps legacy: Claude atiende peticiones de usuarios interactuando con sistemas internos que no tienen API.

  • QA exploratorio: Claude actúa como usuario, navega flujos no definidos de antemano y reporta comportamientos inesperados.

  • Migración de datos: extraer datos de un sistema antiguo e introducirlos en uno nuevo, cuando no existe exportación automatizada.

Conclusión

Computer Use representa un cambio cualitativo en lo que los agentes de IA pueden hacer, pero no es todavía una alternativa de producción para automatización de misión crítica. Su tasa de acierto sigue siendo modesta en el benchmark OSWorld, y cada acción cuesta tokens. Eso lo hace más adecuado para tareas de frecuencia baja con alto coste manual que para flujos de alto volumen. La combinación más efectiva es usar Computer Use para lo que no tiene API y Playwright u otras herramientas deterministas para lo que sí la tiene: cada herramienta en su dominio correcto.

Fuentes

  1. lanzó Computer Use
  2. repositorio de quickstarts de Anthropic
  3. documentación oficial de la herramienta computer use