On October 21, 2026, Reval Labs published the implementation and performance results for the AI model that runs on Android devices in Opposable, an AI that reads a smartphone screen and taps and types on the user's behalf. It uses a compact model of about 2 billion parameters and can operate a phone without connecting to an external AI service. On the Galaxy S25's NPU, the image-processing step reportedly ran in 236 milliseconds. However, that figure covers only image processing and does not represent the time needed for a full operation. For delegating phone control to AI, what matters is not just screen-recognition speed, but whether the AI reliably completes the tasks it is given and whether the owner's approval for things like payments is properly protected.
About 40 routine tasks are handled without AI
Opposable uses Android's accessibility service to read the screens of other apps and perform actions such as tapping buttons and entering text. Because it can obtain a numbered list of on-screen elements with their labels and positions, an external AI agent does not need to guess button coordinates from an image and can specify the element it wants to operate directly. When visual information is needed, such as for photos or maps, it also uses screenshots.
It works with AI agents such as Claude Code and Codex through MCP (Model Context Protocol), a standard for connecting AI to external tools. It supports devices running Android 11 or later, and requires installing an APK app and granting access to the accessibility service. It is free to use when the phone and computer are connected over the same Wi-Fi network or via USB, but the remote relay feature requires a Pro subscription once the 14-day trial ends. When an external AI service is used, that service's terms and fees apply separately.
However, Opposable does not have an AI model decide every action. According to the developer, about 40 routine tasks, such as setting an alarm, sending a message to a contact, or toggling Wi-Fi, are handled by pre-written code, and the result is verified by checking the screen at the end. In addition, once an external AI agent has performed an operation, it can be saved as a procedure tied to the text shown on screen. When the same task is repeated, the saved procedure is replayed, so the AI model does not need to be called each time.
The on-device screen-recognition model handles tasks that these routines and saved procedures cannot. The model adopted is "GUI-Owl 1.5 2B," developed by Alibaba's Mobile-Agent team, which runs using llama.cpp's multimodal capabilities. GUI-Owl 1.5 2B is a model further trained from Qwen3-VL; the 4-bit quantized language model portion is 1.05GB and the image encoder is 445MB. The image encoder converts screenshots into information the language model can process.
The advantage of this design is that handing repetitive operations to fixed code or saved procedures reduces how often the AI model must be called. The benefit may be hard to see for one-off tasks such as setting a timer, but it could prove more useful for work that repeats the same operations many times and for testing app behavior on real devices. The official website also introduces a developer use case in which the AI operates your own app like a real user to find bugs.
iPhone support takes a different approach from Android. It connects to the iPhone as a Bluetooth keyboard and pointer through a beta Mac app, while screen information is obtained via USB or via AirPlay, as described on the current official website. Enabling AssistiveTouch on the iPhone lets mouse actions be passed along as screen taps. The on-device AI model for Android therefore does not run directly on the iPhone. The developer also says this method cannot pass Face ID authentication and cannot handle the side-button press required to approve Apple Pay.
The "16x faster" figure is for image processing only
In a technical article, Reval Labs describes the optimizations it made to speed up on-device AI and their effects. On a Mac with Apple M2 using four CPU threads, the time to read a screen and output a single action fell from 10.6 seconds before optimization to 7.3 seconds. In terms of accuracy, it reportedly maintained a result of selecting the correct action on 27 of the 36 screens in the evaluation.
The optimizations first cut unneeded parts from the top and bottom of the screen to reduce the image data the model processes. They also reduce image tokens for plain background areas and use caching for the instruction text that is common to every request. In addition, when an action intent output by the model, such as "press the Files app," maps uniquely to a screen element obtained from the accessibility service, the system operates that element directly and ends generation. This skips the step in which the model generates on-screen coordinates to the end.
On the Galaxy S25, only the image encoder is moved to the NPU to speed up processing further. According to the developer, in measurements on real devices in a lab via Qualcomm AI Hub, processing a 416×960-pixel image in half-precision floating point (FP16) took 236 milliseconds. The same processing took 3.9 seconds on the M2 CPU used for comparison, which amounts to a speedup of about 16x for the image encoder alone.
The main evaluation results published by the developer, organized by what was measured, are as follows.
| What was evaluated | Environment and result | What the result shows |
|---|---|---|
| Outputting one action from a screen | On M2 CPU with 4 threads, reduced from 10.6 to 7.3 seconds. 27 of 36 screens correct | Processing time per action on a CPU. Not a completion rate for whole tasks |
| Image encoder alone | 236 ms on the Galaxy S25 NPU; 3.9 seconds on the M2 CPU used for comparison | Image processing is about 16x faster. Does not include reading instructions or generating answers |
| Evaluation of completing 8 untuned tasks | On an Android emulator, each method run twice. Giving all instructions at once succeeded on 4 and 3; combining task splitting with result checking succeeded on 6 both times | A small-scale evaluation showing the effect of splitting into subgoals and checking results. Cannot be applied to success rates on real devices in general |
It is important to note that the roughly 16x speed difference measured for the image encoder alone does not mean the whole phone operation is 16x faster. In actual operation, in addition to image processing, the language model must also read the input and generate a response. In another technical article, the developer also explains that it has not yet measured end-to-end processing time on a real device. In addition, the NPU implementation is currently limited to Snapdragon; devices with Google Tensor, MediaTek, or Exynos use the GPU or CPU.
The demo videos on the official website also need to be evaluated separately from the on-device model's performance. In an example that connects Claude Code via MCP to switch to dark theme and set a five-minute timer, processing took 50 seconds with 17 tool calls. Another demo, a Wikipedia search, took 118 seconds, with an external AI cost of $0.44. Both are individual run records using an external AI; they do not measure the on-device model's processing speed alone or the time taken for routine tasks handled by fixed code. Nor are they performance metrics applicable to every operation in the current version.
Meanwhile, in the evaluation of 8 tasks on an Android emulator, what proved effective was not the model's inference speed but the method of splitting work into small goals and checking the results. Instead of having the model complete everything from a single instruction, the approach was changed to give subgoals step by step and cross-check the model's own claim of success against accessibility tree information; with this, it completed 6 tasks in both of two trials. The accessibility tree is information representing the structure of on-screen buttons, text, and so on, and can be used to check the screen state after an action. The result suggests that an AI's ability to output actions quickly and whether the instructed task has actually been completed need to be evaluated separately.
Can final approval for payments and authentication be separated from the AI?
When delegating phone operation to AI, permission management is as important as processing performance. The developer has also disclosed bugs found while testing Opposable's built-in payment protection feature. Initially, payment actions were identified only by the label text of the button being tapped, so it failed to detect a plain "Confirm" button below an amount display or buttons with no label. In response, it has been changed to consider the whole screen's content and app information, not just the button text.
In the course of verifying this fix, three problems related to approval handling were further found. The first was that the AI itself could open the notification panel and press the "Approve" button for a payment it had initiated. The second was a case where the automatic popup handler mistakenly pressed the "Deny" button shown on a pending approval request. The third was that, when connected via USB, it switched to a debugging input path, allowing a money-transfer test to run without the approval confirmation that should have been required.
The developer says it has fixed all three problems. From version 0.4.3 onward, it reportedly introduced a mechanism that rejects taps by the AI agent on the relevant screen while an approval request is displayed. However, this is the developer's own report of a fix and does not mean its safety has been confirmed by a third-party security audit.
What these bugs bring into focus is that an AI faithfully following instructions and properly protecting the owner's approval are separate issues. Even if a confirmation screen is shown at payment time, it fails to serve as identity verification if the AI can press the approval button via the notification panel or another input path. Likewise, even if restrictions work on the normal input path, protections may be bypassed if the same operation can be performed via another route such as USB debugging. To reliably protect the owner's final approval, permissions must be restricted across every input path available to the AI.
The official Opposable FAQ also cautions about the strength of its permissions. The developer asks users to manage the access token as carefully as a password, because anyone holding it can operate the device. The ability to read screens and tap and type across apps allows correspondingly broad actions. Not only how much to entrust to the AI, but also who can use that operating authority, is an important thing to manage.
Running an AI model on the device is also not the same as all screen information staying on the device. According to the developer's privacy explanation, inference by the on-device model does not send screen data outside. However, when the remote relay feature is used, requests and responses that may include screen content pass through a server. The developer says it does not store screen content on the relay server, but it would be inaccurate to assume that everything is processed on the device, including setups where an external AI handles operation.
Opposable's distinguishing feature is not only running a compact model of about 2 billion parameters on a smartphone. It also aims to reduce processing time and dependence on external services by combining routine processing and saved operation procedures and limiting the AI model to the situations where it is needed. However, the performance evaluations published so far are limited, and how reliably it can complete complex tasks on real devices will require further verification. At the same time, it must also be confirmed that the AI cannot stand in for the owner's approval through any input path, including notifications and debugging features. Whether it can balance efficiency in repetitive tasks with protection of the final decision will determine how practical such phone-control AI becomes.