Test results
Measured on the live system.
ERIUS PHONE is virtual phone infrastructure for AI agents: cloud Android phones and tablets that an agent drives over an HTTP API and MCP. This page shows what the production system did when we measured it, and how each number was taken.
- 0Errors in 520 calls to 5 phones driven at the same time
- 41msMedian screenshot over the public API (JPEG, half size)
- 8/8Devices that kept their apps and storage when their container was replaced
- 403The only answer a key gets for another account's phone
1 · Stable API
The API over eight days.
From the production request log and the production health check, 2 to 10 October 2026.
| Measure | Result | How it was taken |
|---|---|---|
| Requests served | 53,819 logged, 46,779 of them with a valid key | API request log, 2 Oct 14:00 to 10 Oct 18:14 UTC |
| Server errors (5xx) | 10 of 46,779 requests with a valid key (0.02%) | Same log, status codes 500 to 504 |
| API health check | 5,756 of 5,757 checks passed (99.98%) | GET /healthz over public HTTPS every 2 minutes, 2 Oct 16:21 to 10 Oct 18:14 UTC |
| Website and dashboard health check | 5,756 of 5,757 checks passed each | Same check, same period |
| Round trip to the API | 2 ms median, 7 ms slowest of 100 | GET /healthz and GET /whoami, 100 calls each, from a test machine in the same region |
The health check runs on the same server as the API, so it shows that the service answered, not that every network path to it was open. Most of the traffic in this period was our own testing and the public demo. Availability targets and the SLA roadmap are on the Security page.
2 · Speed
How long one action takes.
Sequential calls over the public HTTPS API to two phones, 10 October 2026. Time is from request sent to the full response read.
| Call | Median | 90th percentile | Response size | Calls |
|---|---|---|---|---|
POST /press (a key press) | 5 to 6 ms | 6 to 8 ms | 30 per phone | |
GET /snapshot?format=text (the screen as a tree) | 5 to 6 ms | 7 to 8 ms | under 1 KB | 30 per phone |
GET /foreground | 26 to 28 ms | 28 to 31 ms | 30 per phone | |
GET /observe?image=0 (tree plus element list) | 29 to 32 ms | 32 to 37 ms | 3 to 4 KB | 20 per phone |
GET /screenshot as JPEG, half size | 40 to 41 ms | 46 to 58 ms | 39 to 43 KB | 30 per phone |
GET /screenshot as WebP, longest side 1024 | 46 to 51 ms | 55 to 64 ms | 7 to 9 KB | 30 per phone |
GET /observe with a marked image | 214 to 228 ms | 245 to 290 ms | 76 to 86 KB | 20 per phone |
POST /launch (Settings, already started once) | 393 to 394 ms | 5 per phone | ||
GET /screenshot as full-size PNG, 1440×3120 | 1.23 to 1.27 s | 1.26 to 1.30 s | 3 MB | 12 per phone |
The home screen was showing during the read calls. A busier screen has a larger tree and takes longer to read. For an agent loop, ask for JPEG or WebP at reduced size: the full-size PNG is there for pixel-exact checks.
From the production log of the last 24 hours before the measurement, timed on the server: 1,424 taps with a median of 19 ms, 576 swipes with a median of 340 ms (the gesture itself lasts 300 ms), and 524 app launches with a median of 346 ms.
3 · Parallel devices
Five phones at once.
Five devices in three accounts, driven at the same time through the public API, 10 October 2026.
| Call | One phone at a time, median | Five phones at once, median | Errors |
|---|---|---|---|
| Screenshot (JPEG, half size) | 39 to 47 ms | 43 to 69 ms | 0 of 200 |
GET /foreground | 25 to 26 ms | 28 to 34 ms | 0 of 200 |
POST /press | 4 ms | 4 to 5 ms | 0 of 120 |
- Each phone ran 40 rounds of screenshot, foreground read and key press. In total 520 calls ran in parallel and all 520 returned
200. - The slowest single call in the parallel run took 429 ms. The slowest in the one-at-a-time run took 337 ms.
- While the five ran, we opened Settings on one phone only and read the foreground app of all five at the same moment. One phone reported Settings. The other four still reported their home screen.
- Every screenshot came back at its own phone's size: 720×1560 from the four phones and 924×1480 from the tablet.
- The server has 8 CPU cores and 32 GB of memory and runs 8 devices. Each device has its own limit of 2 CPU cores and 3 GB of memory.
We drove five of the eight devices. The other three are kept for calls and for the public demo, so they were left out. The run above was paced. Since 10 October the API limits requests per API key and per phone (60 a second for each phone, bursts to 120), so phones driven from one address no longer share one budget: the same test run flat out, with no pause, returned 200 on all 390 parallel calls.
4 · Session persistence
State that outlives the container.
A phone keeps its apps, files and accounts between API calls, between sessions and when its container is replaced.
- On 10 October 2026, between 12:55 and 13:27 UTC, the container of every one of the 8 devices was replaced with a new one. Each new container was attached to the phone's existing storage volume.
- The storage volumes were created between 2 and 9 October. None was recreated.
- Apps installed before the replacement were still installed after it. One phone still had apps first installed on 2 and 3 October. The tablet still had apps first installed on 5 and 6 October.
- A phone with Google Play still listed its signed-in accounts after the replacement. We checked that the account entries were present. We did not open each app to confirm its session.
- There is no session to open or close in the API. A key can stop calling for a day and find the phone as it left it.
How it was taken: container and volume creation times from the container runtime, and each app's first-install time read from the phone, on 10 October 2026 at 18:21 UTC. There is no backup job for phone storage; see what we do not do yet.
5 · Isolation
One account cannot reach another.
Re-checked on the production system on 10 October 2026. The design is described on the Security page.
| Test | Result |
|---|---|
| Three keys from three accounts, each asking for a screenshot of a phone in another account (6 combinations) | 403 forbidden every time |
| The same keys sending a key press to a phone in another account | 403 forbidden every time |
| A key asking for a device id that does not exist | The same 403 body as for a phone in another account |
| A wrong key, and no key | 401 unauthorized |
GET /devices with each key | Only that account's own devices |
| From inside a test phone: connect to a phone in another account | Blocked |
| From inside a test phone: connect to the server's SSH port and to the API's internal port | Blocked |
| From inside a test phone: connect to the hosting provider's metadata address | Blocked |
| From inside a test phone: connect to the internet | Open, as intended |
Each account has its own private network, with connections between phones on the same network switched off. The phones are containers on one server and share its kernel; that limit is stated on the Security page.
6 · The device
What an app sees.
Read from a production phone on 10 October 2026.
| Property | Value |
|---|---|
| Model, brand, manufacturer | SM-S938B, samsung, samsung (Galaxy S25 Ultra) |
| Screen | 1440×3120 at 505 dpi |
| Build type and tags | user, release-keys |
| Tablet | A second profile with a 1848×2960 screen |
| Underneath | An Android 13 system in a container on an x86-64 server |
| Not present | A SIM, a hardware security chip, hardware-backed attestation |
Apps that require hardware-backed attestation or a certified device may refuse to run. That is the same on every plan; the pricing FAQ says more.
7 · Integrations
Tested from a clean install.
What a developer gets today, checked on 10 October 2026.
pip install erius-phone-mcpinto a new virtual environment finished in 12.5 seconds without errors.- The MCP server started over stdio and listed 21 tools. Reading the device list, the screen tree, the foreground app, the installed apps and a screenshot all succeeded against a production phone.
- A Python script that installs an APK, launches it, reads the screen and saves a screenshot ran end to end. The install took 569 ms for a 5 MB APK.
- A Node script ran the same four-step flow on two devices at once in 2.4 seconds, and on a third account's phone in 2.6 seconds.
Both scripts are in the integration examples. The MCP server is on PyPI and on GitHub.
Method
How to read these numbers.
What these results are, and what they are not.
- Every number on this page was taken from the production system. None comes from a lab copy.
- The test machine sits about 2 ms from the API. Your own network round trip comes on top of each time.
- The phones tested were our own and those of our internal test accounts. No customer phone was used.
- ERIUS PHONE is in early access and runs on one server. These are measurements from one period on that setup.
- We will re-run the tests and change the date at the top of the page when we do.
Run your own test.
Early access: no payment, no card.
Request a device