Google's artemis gives your coding assistant a real Android phone, and it also gives that assistant a rulebook. The file is mcp_server/rules.md, a testing mindset that the README marks as highly recommended for your AI IDE's rule configuration. The README presents that guidance as part of setup.
That file is a useful lens for reading the rest of the README.
What the calling agent gets
Artemis exposes an Android device or emulator to AI IDEs through a native Model Context Protocol server. The Antigravity config in the README registers five tools: mobile_run_task, mobile_manage_task, mobile_get_device_state, mobile_inspect_trace, and mobile_diagnose. Through the MCP integration, clients like Antigravity, Claude Code, and Windsurf can drive a test device and collect Logcat output and screenshots.
The sample prompt in the README shows how much gets handed over in one message. The assistant is asked to build the current changes into an APK, install it on the connected device, open the login screen with a test account, check for unexpected popups after login, and return screenshots of the final page. Compiling, installing, logging in and checking the result all sit inside a single chat request.
On the runtime side, the README reports 99%+ task completion on Google Research's AndroidWorld benchmark, which it describes as 100+ multi-step tasks. That result describes ARTEMIS on the benchmark. The rules file is a separate piece, aimed at the assistant making the calls.
The rules file is part of the install
The README says rules.md covers active exploration before coding, a routing strategy between the Flash and Pro profiles, latency and timing compensation, and a "Dynamic-First, Coordinate-Fallback" locator pattern. The startup script (./start.sh on macOS and Linux, .\start.bat in PowerShell) detects and installs ADB, scrcpy, FFmpeg and the Python dependencies through uv, then offers to write both the MCP configuration and these rules into your AI IDEs. The list covers Antigravity, Cursor, Claude Code, Codex, Windsurf, VS Code, Cline/Roo and OpenClaw.
The Claude Code instructions address duplicate rule loading. The install puts the rules at ~/.claude/rules/artemis.md, and the README tells you to install them in exactly one location, because Claude Code loads both ~/.claude/CLAUDE.md and ~/.claude/rules/*.md. A second copy wastes context. Codex users add the contents to ~/.codex/AGENTS.md, and Cursor users copy them into .cursorrules or a rule file under .cursor/rules/.
Each rule points at a mechanism
The rules line up with runtime behaviors described in the README.
The locator pattern matches how artemis targets the screen. It uses element indices when they are available and falls back to coordinates and visual locating for custom interfaces. As I read it, that order puts element indices first and keeps coordinate and visual locating for custom interfaces.
The routing strategy maps onto the two execution profiles. Flash runs a reactive observe-and-act loop with asynchronous history summaries, and the README puts a typical step at 3 to 5 seconds. Pro checks targets before individual actions and returns blocked actions to the Operator for recovery, and the README positions it for long-running exploratory and stability tests. Choosing between them is a trade between a quick reactive loop and one that inspects before it acts. The rules file covers how the assistant should choose between those profiles.
Latency and timing compensation gets its own topic too, which fits a tool whose fast mode still measures steps in seconds.
Using it without an assistant
Artemis also supports direct terminal use. uv run artemis run takes a natural language instruction from the terminal, such as opening Settings and reading the battery level, with the profile chosen on the command line. uv run artemis ui runs the web visual test console with real-time screen projection, natural language test dispatch, live reasoning telemetry, action trajectories and execution replay, while restart, stop and status subcommands manage the server.
For existing test suites, the artemis-client package is described as having zero runtime dependencies. ADB, agents, models and image processing stay on the device host, while the development machine runs the client. The SDK example builds an ArtemisClient from a host address, an optional device serial, and a default profile of flash or pro. It then awaits client.run with a plain-English test, asserts on result.succeeded, and prints the device serial and a trace_id. The README describes the outputs as strongly typed Pydantic models meant for frameworks like pytest or CI/CD pipelines.
The project requires Python 3.12 or newer and is licensed under Apache 2.0. If you plan to point an assistant at a real phone, read rules.md before the tool list. It tells you how the maintainers expect the agent on your side to behave.
GitHub: https://github.com/google/artemis
Curated by Agent Palisade — practical AI for small and mid-sized businesses.
Top comments (0)