ARTEMIS de Google publica como código abierto la automatización de Android: qué cubre realmente la afirmación del 99 % de AndroidWorld

El commit más reciente de google/artemis no es una función. Es una línea de atribución — "fix: completar el README y los encabezados de archivos relevantes según los requisitos de Apache 2.0", subido el 12 de septiembre de 2026, tres días después de que Minitap publicara una publicación titulada Esperaba más de Google. ARTEMIS de Google es el agente de automatización para Android recién publicado como código abierto por la empresa: convierte una instrucción en inglés sencillo en toques, deslizamientos, escritura y verificación reales en un dispositivo Android físico o en un emulador, captura los registros y las capturas de pantalla a lo largo del proceso, y reporta una tasa de finalización de tareas superior al 99 % en el benchmark AndroidWorld de Google Research. Fue publicado este agosto por el equipo Pixel Test Engineering Fusion de Google bajo Apache 2.0, y realmente vale la pena dedicarle la tarde. También es, a mediados de septiembre, el centro de una disputa de atribución de código abierto que dice más sobre cómo se construyen los agentes móviles que la cifra del benchmark. Ambas historias son reales. Solo una de ellas es la razón por la que el último commit del repositorio fue una corrección de licencia.

Lo que realmente se envió

ARTEMIS no es un modelo ni un envoltorio de chatbot. Es un arnés de control: un sistema Python 3.12+ que vive entre un modelo de visión-lenguaje y un teléfono real. Le das una tarea en inglés; observa la pantalla, decide una acción, la ejecuta a través de ADB, comprueba qué ocurrió y sigue adelante. Cinco cosas venían en la caja:

• Una CLI y un SDK de Python. code>./start.sh/code> inicializa ADB, scrcpy, FFmpeg y el entorno de uv; code>uv run artemis run "…" --profile flash/code> ejecuta una tarea sin interfaz gráfica; el code>artemis-client/code> SDK envuelve la misma llamada para pytest y CI, y devuelve code>succeeded/code>, code>status/code>, code>device_serial/code> y un code>trace_id/code> que puedes seguir más tarde.

• Una consola web. code>uv run artemis ui/code> sirve una consola de prueba visual en code>localhost:8000/code>, donde puedes observar el bucle paso a paso.

• Un servidor MCP nativo. Esta es la parte que hizo que despegara. code>uv run artemis mcp --install all/code> expone code>mobile_run_task/code>, code>mobile_manage_task/code>, code>mobile_get_device_state/code>, code>mobile_inspect_trace/code> y code>mobile_diagnose/code> a cualquier asistente compatible con MCP, con rutas de instalación de primera clase para Antigravity, Claude Code y Codex, además de generación de configuración para Cursor, Windsurf, VS Code y Cline/Roo. Desde un asistente que tiene el servidor conectado, "compila el APK, instálalo, abre los ajustes, activa el modo avión y captura el resultado" deja de ser un script y se convierte en una frase.

• Un asistente de accesibilidad. La primera tarea instala el Artemis Accessibility Helper, que lee el diseño de la pantalla sin mantener la conexión de UiAutomation —deliberadamente, para que no se supriman otras herramientas basadas en UiAutomator en el mismo dispositivo. Se ejecuta en el teléfono y no envía nada fuera de él, y recurre a UIAutomator2 cuando no puede conectarse, con el recurso alternativo mostrado en la línea de tiempo de la tarea.

• Captura de registros y trazas.Las pilas de fallos, las capturas de fotogramas clave y un informe de diagnóstico se recopilan automáticamente en lugar de añadirse a posteriori por parte del llamador: la razón por la que resulta utilizable como conjunto de pruebas de regresión y no solo como una demostración.

Flash y Pro son dos productos diferentes que comparten un mismo nombre.

Lo más importante que hay que entender antes de comparar ARTEMIS con cualquier cosa es que code>--profile flash/code> y code>--profile pro/code> no son un ajuste de velocidad en un solo agente. Son dos agentes.

• Flash — un bucle reactivo de observar y actuar de aproximadamente 3–5 segundos por paso, sin plan, sin notas, sin comprobación de seguridad previa a la ejecución, sin verificación de puntos de control, sin informe final y sin ADB shell. El bucle no tiene límites por defecto porque el historial se comprime en lugar de acumularse.

• Pro — un grafo multiagente de aproximadamente 15–40 segundos por paso, construido a partir de un Planificador que mantiene un plan Markdown vivo con elementos explícitos code>verify/code> y code>assert/code>, un Operador con el conjunto completo de herramientas y un Verificador de solo lectura que valida los puntos de control y ejecuta una revisión de salida. code>--verification-level/code> acepta code>off/code>, code>final/code> (el valor predeterminado), code>checkpoints/code> o code>strict/code>.

Esa es una diferencia de latencia de cinco a diez veces para la misma descripción de tarea, y es la diferencia entre una prueba de humo y una ejecución exploratoria de más de 100 pasos. El propio planteamiento de Google es que Pro es para trabajo de largo horizonte y continua code>[Loop:continuous]/code> monitorización; Flash es para tareas rutinarias y deterministas de UI. Si lees una reseña que cita tiempos de pasos sin decirte qué perfil los produjo, no te está diciendo nada.

La estrategia de localización es la verdadera ingeniería.

La mayoría de los frameworks de automatización móvil fallan con los selectores. ARTEMIS se construyó con un enfoque dinámico como prioridad: cuando existe un índice de elementos de accesibilidad, lo usa; cuando no existe —un Canvas, una superficie de Compose, una vista de Flutter, un juego—, recurre a coordenadas y visión. No hay una capa de XPath que mantener ni un ID que quede obsoleto, lo cual importa porque las aplicaciones que más quieres probar son las que publican nuevas compilaciones cada semana.

El perfil Pro añade una Red de seguridad: cada acción pasa por una comprobación previa a la ejecución, primero XML, con un respaldo de píxeles, que atrapa la ventana emergente del sistema que está a punto de comerse tu toque. Los fallos abren un «incidente de ejecución» que permanece en el contexto hasta que un éxito posterior lo resuelve, en lugar de generar un agente de reparación independiente. Las sesiones largas se comprimen — las capturas de pantalla antiguas se convierten en resúmenes visuales, los pasos completados se agrupan en eras recuperables que code>search_history/code> y code>replay_steps/code> pueden recuperar — lo cual es lo que evita que un contexto de 100 pasos se vuelva demasiado costoso.

99,1 % en la tabla de clasificación, y la salvedad que omiten las publicaciones de lanzamiento

La afirmación principal de ARTEMIS es una tasa de finalización superior al 99% en AndroidWorld, el benchmark de Google Research de 116 tareas realistas en una veintena de apps, puntuado como Pass@1. A 11 de septiembre de 2026, la tabla de clasificación de AndroidWorld situaba a ARTEMIS en el 99,1% frente al mobile-use de Minitap en el 91,4%, con el rendimiento humano en el 80%. En la tabla, eso es el estado del arte entre los resultados reportados públicamente.

Dos cosas deben acompañar a esa cifra. En primer lugar, la tabla de clasificación de AndroidWorld no verifica de forma independiente las presentaciones —todas las cifras que aparecen en ella, incluidas las de ARTEMIS, son autoinformadas por el equipo que las produjo—, y un análisis de robustez ha demostrado que las variaciones en las tareas por sí solas pueden alterar sustancialmente la puntuación de un agente. Considera el 99,1 % como una afirmación sólida de un proveedor sobre un benchmark público y verificable, lo cual es algo real y útil, y no como una medición auditada, que no lo es. En segundo lugar, la forma de la comparación importa: el benchmark es un conjunto fijo de tareas, y el gráfico comparativo publicado por ARTEMIS, según se informa, omitió el uso móvil mientras incluía otras entradas. Un benchmark en el que falta en el gráfico el resultado previo más sólido es una afirmación más débil de lo que sugiere el porcentaje bruto.

La disputa, que es la verdadera noticia este mes

En su blog y en un issue público en el repositorio, Minitap —una startup de pruebas móviles cuyo proyecto de código abierto mobile-use hace lo mismo para Android e iOS— alegó que 228 de los 229 archivos de ARTEMIS eran idénticos a los suyos. Los detalles que publicó son inusualmente concretos: código de conexión de dispositivos Android que coincide con su implementación, la reutilización literal de instrucciones pertenecientes a un agente llamado "Hopper", y un ejemplo de WhatsApp que envía mensajes de Año Nuevo a Alice, Bob y Charlie, reproducido con los mismos comentarios, los mismos pasos de limpieza y el mismo error. Además, alega que un archivo que llevaba los nombres de tres autores de Minitap —Pierre-Louis Favreau, Jean-Pierre Lo y Nicolas Dehandschoewercker— fue reemplazado mediante force-push en agosto, con los nombres eliminados y un autor diferente en su lugar.

La cuestión de la licencia no es turbia. mobile-use es Apache 2.0, y Apache 2.0 permite exactamente este tipo de reutilización —comercial, derivada, cerrada— siempre que se conserven los avisos de derechos de autor y se indique qué se ha modificado. Lo que no permite es distribuir el código con los avisos eliminados. Desde que surgieron las acusaciones, el repositorio incluye la línea «Este proyecto incluye código fuente desarrollado por Minitap, Inc.» y enlaces a minitap-ai/mobile-use, y el commit del 12 de septiembre que completa esa atribución es, en el momento de escribir esto, el cambio más reciente en code>main/code>. Minitap no ha publicado ninguna prueba que vincule la eliminación de la atribución con sus propias entregas sin respuesta en la tabla de clasificación, y Google no ha emitido una respuesta pública detallada. La lectura honesta: el código que se comparte es legítimo y siempre estuvo permitido; el papeleo, durante un periodo, no lo estuvo, y ahora se ha corregido.

La parte que nadie calcula en costos: la factura del modelo

ARTEMIS viene con una insignia que dice "Multi-Modelo — Gemini | Claude | GPT-4o | Qwen-VL", y su archivo de configuración en code>config/artemis.jsonc/code> es donde lo apuntas a cualquier modelo de visión para el que tengas credenciales. Nada en ese archivo es visible para el usuario hasta que ejecutes Pro en un flujo de trabajo real y veas lo que realmente cuesta un agente de larga duración.

Haz las cuentas de los perfiles. Una ejecución Pro de 100 pasos a 15–40 segundos por paso está entre 25 minutos y poco más de una hora de reloj, y cada uno de esos pasos es al menos una llamada a un modelo de visión que incluye una captura de pantalla. Flash es más barato por paso, pero entra en bucles con más frecuencia, y como su contexto se comprime en lugar de truncarse, se pasará sin problema del límite de turnos que asumías que era un techo. Elijas el perfil que elijas, el modelo es la partida que escala con tu suite de pruebas, no la licencia ni el hardware.

Aquí es donde una capa de enrutamiento deja de ser una abstracción. Un modelo de visión que dirige una sesión larga de Android es una carga de trabajo con dos propiedades incómodas: es de larga duración y no tolera un contratiempo de un proveedor en medio del paso 74, porque el contexto de la ejecución está en el endpoint de ese proveedor. Apuntar ARTEMIS a una única URL base compatible con OpenAI y dejar que nuestra conmutación por error mueva la ejecución a otro proveedor del mismo modelo es la diferencia entre una prueba inestable y una tarde perdida. Qwen3.8-Flash es el candidato interesante para probar primero —un MoE multimodal de 6B activos con un contexto de 1M de tokens, listado en nuestro catálogo a $0,15 por millón de tokens de entrada y $0,47 por millón de salida, con lecturas de caché a $0,018 y escrituras de caché a $0,230. Ese precio de lectura de caché es el relevante aquí, porque una ejecución Pro relee un contexto creciente en cada paso.

Sin embargo, sé preciso sobre lo que eso significa: Qwen3.8-Flash no está en la lista de backends probados de ARTEMIS, que nombra a Gemini, Claude, GPT-4o y Qwen-VL. Es un modelo que encaja de forma plausible en el arnés, y el arnés está construido explícitamente para aceptar uno. Nadie ha publicado un benchmark de ese emparejamiento, y deberías considerar que cualquiera que afirme que existe uno se lo ha inventado.

La hoja de ruta, y cuánto de ella sostiene el peso

Cuatro elementos figuran en la hoja de ruta publicada: una integración con Android Studio con depuración en el editor, grabación de pruebas y control de dispositivos; compatibilidad con iOS; modelos ligeros de visión y lenguaje en el dispositivo para un trabajo de baja latencia que prioriza la privacidad; e interacción de voz bidireccional en tiempo real.

El primero es el que hay que creer, porque es el siguiente artefacto natural de un equipo de ingeniería de pruebas de Pixel y no conlleva riesgo de investigación alguno: el agente ya controla un dispositivo, solo necesita un panel en el IDE. iOS es una afirmación mucho más ambiciosa de lo que parece desde fuera: toda la estrategia de localización se apoya en el servicio de accesibilidad de Android, y iOS no tiene una superficie equivalente con el mismo modelo de permisos, así que espera una reescritura de la capa de percepción en lugar de un port. El elemento de VLM en el dispositivo es el que vale la pena seguir de cerca, porque es el único elemento de la lista que eliminaría el costo de API por paso que actualmente domina una gran suite de pruebas, y implica un modelo pequeño, rápido y con capacidad de visión que pueda mantener unida una tarea de UI, lo cual es un objetivo mucho más acotado que «un modelo pequeño que sea bueno en el uso de herramientas».

Qué hacer con esto esta semana

Clónalo, ejecuta code>./start.sh/code> contra un emulador, y dale a Flash una tarea que tu suite de Espresso actual ya cubra. Eso te dirá en menos de una hora si el localizador dynamic-first sobrevive a las superficies Compose de tu app, que es la pregunta que decide si algo de lo demás importa. Luego, ejecuta la misma tarea en Pro y compara las dos trazas — la diferencia entre 3–5 y 15–40 segundos por paso es donde reside tu presupuesto, y no puedes razonar sobre el costo de ARTEMIS sin ella.

Mientras lees el código, lee los encabezados. El commit del 12 de septiembre que añadió la atribución de Minitap es el más reciente del repositorio, lo que significa que los encabezados de archivo que estás leyendo tienen cuatro días y que el proyecto se está reparando activamente en público. Eso no es razón para evitarlo. Es razón para comprobar qué versión de la historia tienes en tus manos antes de citar una tasa de éxito en una diapositiva.

Apuntar ARTEMIS a una única URL base compatible con OpenAI y dejar que nuestra conmutación por error traslade la ejecución a otro proveedor del mismo modelo es la diferencia entre una prueba inestable y una tarde perdida.