Clousd-Android/clousd-sdk

The pitch, in one breath
Every agent framework can tap a phone. Almost none has a phone worth tapping.
**Clousd is the phone.** Each device is a full Android system built as a specific real model, Pixel to Galaxy to
Xiaomi, with the hardware identity, Google Play, cameras, sensors and network of the handset in a user's pocket. Your
agent, your script or your test suite drives it over HTTPS: look at the screen, act on it, check the result, reset to
a saved state, clone it a hundred times. Apps see a phone, not an emulator, so the agent sees the screens a person
sees.
This repository is the public side of it: the OpenAPI description, the Python client, the MCP server and the agent
loop. Early access: keys on request at clousd.com/agents.
Mix and match
Pick one from each column. They all compose.
| Pick a phone | Pick a brain | Pick a driver |
|---|---|---|
| **Pixel** 6 to 11, Android 12 to 17 | Any **MCP client**: Cursor, Windsurf, Zed, desktop assistants, agent frameworks | **MCP server** clousd-mcp, local (stdio) or hosted at https://api.clousd.com/mcp |
| **Galaxy** S, A, M, Z series | Any **OpenAI-compatible model**: hosted APIs, OpenRouter, Ollama, vLLM on your GPU | **Python client** clousd + clousd.agent task loop |
| **Xiaomi, Redmi, POCO, Motorola, OnePlus, realme, OPPO, vivo, Sony, TECNO, Infinix** and more, 150+ models | No model at all: **recipes** replay a recorded flow in seconds | **CLI** clousd run "book a table" --device dev_04f2 |
| Network exit in the country you choose: residential, mobile, ISP, datacenter | A person in the browser: the dashboard streams the screen live | **REST API** (openapi.yaml, reference) |
The phone stays the same whatever you plug in. A new model release is a free upgrade to your phone agent.
What it does
**The phone taps what you'd tap**
- observe: a fresh screenshot with every element numbered, the app in front, and the UI tree with text, ids and bounds
- act: tap by element number or point, long press, swipe, scroll, type in any language, keys, open apps and links,
intents, settings pages, clipboard, notification shade; the server waits until the screen settles and refuses an
action taken on a stale screen (409 stale)
- inspect: notifications, clipboard, app versions, crashes and ANRs from the log, health, without touching the screen
- ADB over a relay when a check has to go deeper than the screen: one-time code, IP allow-list, expiry
**A phone that apps believe**
- Built from a snapshot of the real handset: build fingerprint, properties, sensors, cameras, codecs, GPU strings,
audio, screen; Google Play and Play services inside
- Its own network exit, SIM profile, time zone and locale that follow the exit; a kill-switch below Android so
nothing leaves the phone outside that exit
- Snapshots: save a prepared state, restore it before every run in seconds, clone it into ten or a hundred phones with
their own identities
**Teach it once, replay for free**
- Recipes: scripted flows per app (login, warm-up, publish, delete) that wait for the right screen at each step and
deal with popups; built-in recipes for the big social apps, yours in JSON
- Record a recipe from what is done on the phone (through the API or by a person in the live view), then replay it on
any number of phones without a model
- App packs: named elements with a selector chain per app version, popups handled once per app
**Scale the fleet**
- Start with one phone, run hundreds; stopped phones cost nothing
- One call runs a recipe or a chain of steps on up to 32 phones in parallel (POST /groups, c.run_recipe(...), MCP
fleet), each phone with its own login or caption, starts spread so the phones do not act in lockstep
- Groups and schedules in the dashboard, jobs and webhooks in the API
- Benchmark harness: run AndroidWorld-style task sets on real device models with any model behind the loop
Why it is built this way
**Emulators are the first thing an app checks for.** Goldfish hardware, emulator builds, no SIM, a datacenter IP: the