1. Why we tested this at all
Through most of last year the question I heard most was a simple one. How much labour can AI phone control actually replace.
It is hard to answer directly, because the answer depends on which jobs you hand over. The same software saves one person a hire and gives another person a new thing to watch every day. The difference is not in the software.
So in June I ran a controlled comparison. Twenty-two iPhones, one set of tasks, half on the existing Apple cluster control scripts and half on an AI layer, for three weeks, logging time taken, failure count and minutes of human intervention every day.
The conclusion first. Three kinds of job clearly gained from AI, and two kinds went backwards. Overall the pure operating time fell from five hours forty minutes a day to around one hour fifty, but that figure only holds if the jobs were chosen well. The work we forced in ran slower than before.
iOS cluster control has changed far more at the task layer than at the device layer in recent years. Here is the setup and the three weeks of records.
2. How the test was set up
The conditions matter, otherwise the numbers mean nothing.
Twenty-two iPhones from one batch, same model, same OS version. Connected by cable, split across three powered hubs on two USB controllers. Cable was chosen for a plain reason: the devices sit on a rack and never move, so no Bluetooth or OTG board was needed, and no pairing to maintain. If the phones do need to move, or you would rather not run one cable per device, an iPhone can also connect over the local network, covered further down.
Three account tiers: four primary accounts run by hand, sixteen matrix accounts for batch work, two probe accounts for testing new flows. The task list came from the previous month of real work, eleven items covering content publishing, order patrol, comment replies, asset syncing and data logging.
The comparison duplicated that list. Group A ran on the existing scripts, group B ran on the AI layer, with accounts and devices split evenly. Three numbers were logged daily: time to completion, failures, and minutes of human intervention.
One caveat first. This is not a study, it is a comparison inside one business. The sample is small and the conclusions are worth treating as reference rather than general data.
3. Five indicators, three of them went to AI
After three weeks, both sides were scored across five dimensions.
| Indicator | Scripts | AI | Note |
|---|---|---|---|
| Survives an interface change | 2/5 | 5/5 | Scripts must be re-recorded, AI works from screen content |
| Time to build the first flow | 4/5 | 2/5 | Three scripts in half a day, but describing a job takes longer |
| Failure rate on fixed flows | 5/5 | 4/5 | Scripts steadier on fixed work, AI slightly behind but acceptable |
| Handling one-off jobs | 1/5 | 5/5 | Writing a script for a one-off does not pay |
| How readable the records are | 3/5 | 4/5 | AI writes down the reasoning behind each step |
The second one was the surprise. We assumed AI would be faster, and the first week went almost entirely into describing jobs properly. The third was better than expected: AI’s failure rate on fixed flows was not as high as we feared, as long as the flow itself was described clearly.
4. Week one: time went into saying things clearly
The first week produced almost nothing. It went into rewriting instructions.
One concrete example. Our first version of a task read handle the after-sales messages, and half the output was wrong. The reason is easy to see: it did not know which messages counted as after-sales, at what refund amount to escalate, or whether a shipping enquiry should get a reply. Those rules were obvious to us and had never been written down.
The second version took the accuracy from half to the low eighties. A third version added two fallbacks, including mark anything uncertain for a human, and that pushed it past ninety percent.
The lesson from that week: the cost of an AI layer is not the software, it is the time you spend writing your business rules out in words. Pay it once and it keeps paying back. Scripts had an easy first week, three flows recorded and debugged in a day. Then in week two two apps updated their layouts, one flow broke completely, and it had to be recorded again.
5. Week two: only three kinds of job paid off
After two weeks we sorted the eleven tasks into three tiers.
The first tier was worth handing over, three items: publishing for the matrix accounts, comment replies, and syncing assets from cloud storage into the phone’s photo library. All three take one or two minutes, happen dozens of times a day, and sit in different places each time.
On the AI side these three handled more than double the volume of the script side, and most of the gap came from retries. Comment replies hit constant exceptions: spam, repeated posting, questions with no answer in the knowledge base. Scripts skip those. AI classifies and handles them by rule. Where the line falls between the two is set out in more detail in this division of labour.
The second tier worked either way, four items: scheduled publishing, order patrol, data logging, and batch actions on set keywords. Fixed positions, fixed steps. Scripts ran them well and so did AI, with little difference. We kept the scripts because they were already tuned.
The third tier should not be handed over, four items: refund approval involving money, after-sales that requires reading an image, cross-platform price comparison, and any conversation needing judgement in the moment. Forcing those in produced more human intervention, because somebody had to clear up the mislabelled ones every day.
6. Week three: the labour numbers
By week three the data had settled, and the three tiers could be costed together.
| Task | By hand | Scripts | AI |
|---|---|---|---|
| Publishing across sixteen accounts | 3h 20m | 40m | 25m |
| Comment replies across sixteen accounts | 1h 40m | 55m (exceptions skipped) | 35m |
| Asset syncing | 40m | 15m | 12m |
| Total | 5h 40m | 1h 50m | 1h 12m |
Two things about that table matter.
The first is that the gap between scripts and AI is smaller than expected. What took five hours forty down to one hour fifty was automation, not AI. The extra thirty-eight minutes AI saved came mostly from exceptions and one-off jobs.
The second is that the table excludes maintenance. Over three weeks the script side re-recorded twice, around three hours in total. The AI side re-recorded nothing, but spent about an hour writing extra rules. Spread across the three weeks, that is a ten-minute daily difference in each direction.
So the more accurate statement is this: the value of an AI layer is not the absolute minutes saved each day, but that a layout change no longer means starting over, and a one-off job no longer needs a dedicated script.
7. What not to hand over
The worst experience in the test involved money.
We tried handing refund approval to AI with rules written out carefully. After a week we stopped. Every mislabelled order needed a human check, and the checking took longer than approving directly. The psychological cost mattered too, since knowing a step might be wrong made everyone more anxious rather than less.
The second category was after-sales requiring an image. Crushed packaging, wrong item, and similar cases where the evidence is in a photo. AI can describe a photo but cannot decide whether a particular scratch counts as a defect. We split that job: AI sorts, a human judges. The wider account-level risks that come with batch operations are covered in the three-month review.
The third was anything touching account security. Password changes, rebinding, logging in from a new location. Getting those wrong does not cost a rerun, it costs the account. However automated everything else becomes, keep these manual.
8. Cutting the cables: the Wi-Fi route
All twenty-two devices in this test ran over cables, because those phones sit on a rack and the cables were run once and then forgotten. That arrangement has a precondition: somewhere to put a rack, and a willingness to live with twenty-two cables and three hubs.
An iPhone can also connect over the local network. Once it is set up, the computer and the phones talk across the same Wi-Fi and daily jobs need no cable plugged in. Installation still requires one USB connection, for the phone-side program, the developer image and the licence binding. After that the cable comes out.
The effect on cost is bigger than it looks. Cables and powered hubs are the two items in a matrix that fail most often and cause the most troubleshooting. Less work on that layer means less equipment in the room.
A few things are worth knowing before the first install.
Devices no longer have to sit in one place, which is the main gain. Phones can be in different rooms or on different floors as long as they share a network with the computer. The only reason this test did not use it is that those phones never move.
Pick the right licence type. The wireless build binds a device licence, a different type from the one the USB build uses. Choosing the wrong one leaves the device detected but unable to run properly.
Watch the naming. In the downloader the option is the offline iOS version, the control side installs as the offline wireless cluster control and mirroring build, and the workstation scan option is labelled the offline iOS build. One thing under three names, and it is where most first installs stall. The labels themselves are in Chinese.
Keep the network solid. Cables fail by coming loose, wireless fails by being weak. Two walls between a phone and the router will stop the scan from finding it. Move the phone closer to test, then put it back.
9. Three bills, not two
The first is devices and hardware. Twenty-two used phones plus cables, hubs and a rack, paid once. This has nothing to do with AI. It is the entry cost of automation itself. On the wireless route described above, cables and hubs largely disappear from that bill, and the rack no longer has to be sized per device.
The second is software and licensing. Device licensing is charged per phone and comes in two separate types, device authorisation and mirroring authorisation, so do not buy the wrong one. The software itself can be free, with the model API key yours to supply and pay for. Group B in this test ran on iEasyRun, whose terms work the same way: free workstation, a USB device licence required to automate, and models running against a service you provide.
The third is model calls, and it is the most overestimated. Repeated runs of a saved workflow do not consume model calls. The model is only used when it has to plan on the spot. Our three-week model spend was low, because most of what ran were fixed flows.
The mistake to avoid is counting two bills instead of three. The first two are fixed. The third is the one you actually control.
10. Conclusion: worth it or not
Back to the question. How much labour can AI phone control replace.
On this test: if your work is mostly fixed flows, the AI layer adds roughly half an hour to an hour a day, and most of that is maintenance time, the part you no longer spend re-recording after a layout change.
If you have a lot of work whose positions move and that needs judgement on the spot, comment replies, message sorting, exception handling, the gain is much larger, because that work could not be automated at all before and had to be done by hand.
The test compresses to one question. Do you have repeated work where the steps are hard to describe and the positions keep moving. If you do, this layer earns its place. If you do not, getting the automation you already have running steadily is enough.
11. Questions that came up
Does the AI layer conflict with the existing cluster control scripts? No, the two kinds of job run separately. We kept fixed flows on scripts and moving work on AI, both running across the twenty-two devices at once, with no interference.
Does it need an internet connection? Tasks are scheduled locally, devices connect to your own computer, and the records stay on the machine. Model inference goes to whichever service you configure, and that part needs a connection.
What does re-running a saved flow cost? Nothing. Repeated runs of a saved workflow do not consume model calls. Only on-the-spot planning does.
Where did most failures happen? Exception messages in comment replies. Spam, repeated posting and questions outside the knowledge base were over sixty percent of the failure log, and extra rules brought them down.
Did it need a dedicated person? Not in this test. Writing extra rules and reading the records took the existing operators about twenty minutes a day. At larger scale that would probably need somebody.
Was twenty-two devices stable? Yes, given power. Early on, a hub without its own power supply dropped devices several times. Once it was replaced with a powered one, three weeks passed without a recurrence. Heat matters too, so leave gaps between devices on the rack.
What changed most compared with the script setup? No re-recording after an interface change. Scripts were re-recorded twice in three weeks, over an hour each time, while the AI side only spent time adding rules.
Can a small team use it? Yes. Every rule in this test was written by the existing operators, none of whom wrote code.
12. In closing
The most useful thing this test produced was not five hours forty becoming one hour fifty. It was a clear picture of which jobs should never be automated.
We started out intending to automate all eleven items. The four in the third tier all came back to manual, and the detour cost nearly a week. Choosing the jobs matters far more than choosing the tool.
If you want to try, start with one platform, one phone and one small job. Once it runs you will know what belongs next. Connecting twenty devices straight away usually ends in giving up within the first week.
To see how this AI layer is put together, start with phone automation without writing code, and the illustrated installation steps are in the iEasyRun iOS USB guide. To cost your own scale, the figures in the labour and cost breakdown apply directly, and the selection criteria are in the Apple cluster control selection guide.
About EasyClick: A phone automation AI-agent platform covering Android no-root, iOS no-jailbreak and HarmonyOS Next, offering script development, Apple cluster control, local central control & mirroring, and cloud control systems. → Explore all products
Ready to build it for real?
Every approach in this article can be built on the EasyClick phone automation platform — full documentation, developer tools and cluster/cloud-control products, free to try.