Operit AI: an Android AI agent that runs tools, terminals and UI automation on your phone
The most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent
At a glance
- What is it?
- Operit AI is an LGPL-3.0 Kotlin app that turns an ARM64 Android device into an agent workbench with tool calling, a PRoot Ubuntu user space and optional local GGUF inference. The design is unusually broad, and the permission model is where you should look first.
- Who is it for?
- Adopt Operit AI if you want an on-device agent that can touch the file system, a terminal and app UIs, and you are willing to work through the permission model on a spare ARM64 phone. Do not adopt it if you need iOS, x86 or an audited multi-tenant deployment, and do not enable Web Chat or the HTTP API until you have configured the Bearer Token and decided the LAN exposure is acceptable.
- Can I use it commercially?
- Yes, with conditions. LGPL-3.0 is a weak copyleft licence: you can use it inside commercial and closed-source software, but if you distribute changes to its own files, you must publish those changes under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Operit AI is for, and who it is not for
The README describes Operit AI as an open source AI agent platform that runs on Android, connects to cloud or local models, and links those models to the Android system, a terminal, a browser, files and project workspaces. That list is the point. Most Android chat clients stop at conversation. Operit adds tool execution, so a model can read a page, edit a file, run a command or drive an app UI, and the app shows the execution process and file diffs.
The intended user is someone who wants agent behaviour on a phone rather than a laptop: a developer checking a project from a handset, or a user automating an app that has no API. The README's own framing is a task-oriented agent workbench with attachments, workspace context and multi-turn task management.
It is not for everyone. The system requirements are Android 8.0 (API 26) or higher and ARM64 only (arm64-v8a). No x86 build is documented, and the README points people who want other platforms at Operit 2, a separate second-generation repository built around a Rust shared runtime, a Flutter client and an operit2 CLI/TUI, with Android, iOS, Windows, macOS, Linux and Web paths. If you need iOS today, this repository is the wrong one.
How the agent actually reaches the device
The architecture visible in the README is a layered one. At the top, a chat or task binds to a workspace and a model configuration. Below that, a tool layer exposes file, network, search, media, system, software management and development tools. At the bottom sit the actual channels into Android: accessibility services, Shizuku (which the README describes as providing ADB-level debugging rights), and Root.
That layering matters because capability is not uniform. UI automation through accessibility needs no special grant beyond the accessibility permission, but the README states that PhoneAgent and AutoGLM screen-vision operation, and virtual display features, require the corresponding permissions and device support. Shizuku and Root are separate paths with their own setup. Tool permissions have three settings, automatic allow, ask every time, and deny, and the default is ask. That default is the right one, and it is also the main friction: an agent that must ask before every filesystem write is not autonomous, and an agent set to automatic allow is running with your device's rights.
The extension layer is where the project gets its breadth. ToolPkg packages can supply tools, UI, model providers, hooks and runtime capabilities. MCP is supported both locally and remotely, including uvx and npx launch styles. Skills and a unified marketplace handle search and installation. Workflows are a visual node graph with triggers, conditions, logic and data-extraction nodes, and the README lists manual, scheduled, Tasker, Intent, voice and app-launch triggers.
Installing the Operit AI APK on ARM64 Android
There is no package manager route here. The README's quick-start table says to download the latest APK from the Releases page, and the official site at operit.app carries the tutorials and examples. The stated flow is: download the APK, install and launch it, then follow the onboarding to configure a model and permissions.
The README adds an explicit warning that you should only download from the official Releases page or operit.app, because installers from unknown channels may have been modified. Treat that as the install instruction, not boilerplate.
Before you install, check the ABI and the API level. Android 8.0 (API 26) is the floor and only arm64-v8a is supported. The repository does not document an install command, so this check is the one step you perform yourself, using the platform properties Android exposes.
After launching, the onboarding asks for a model. You can point it at a cloud provider or a compatible endpoint, or run locally. The README lists built-in MNN inference and llama.cpp for GGUF models, plus connections to Ollama and LM Studio. Model configurations can be assigned per task, so chat, memory, summarisation and UI control can each use a different model.
Once a model answers, the first real use is a workspace task. Create a project from one of the templates (the README lists Web, Android, Flutter, Node.js, TypeScript, Python, Java and Go), bind the chat to it, and ask the agent to read a file. The workspace supports internal app directories, SAF, SFTP and SSH file systems, so the same flow works against a remote tree. Watch the tool permission prompts on this first run; that is where you learn what the agent is actually reaching for.
The terminal is a PRoot user space, not a container
The headline capability is a built-in Ubuntu 24.04 ARM64 user space. The README states it runs through PRoot by default, with chroot available when conditions allow. This is worth reading carefully. PRoot is a user-space mechanism that intercepts system calls; it is not a kernel-isolated container, and chroot changes the visible root without providing the isolation a container runtime would. The README itself frames chroot as conditional on the device.
Practical consequences follow. Resource use depends on the terminal environment, installed toolkits and local models, and the README tells you to reserve space according to each model's instructions before downloading. On a phone with limited storage, a full Ubuntu user space plus a GGUF model is a real budget decision, not a footnote.
The terminal supports multiple sessions, Python, Node.js, vim, SSH, tmux, custom key bindings and configurable software sources. Development tools include Logcat, SQLite, Git, APKTool and HTML packaging. If your goal is a pocket Linux environment with an agent attached, this is the most concrete part of the project. If your goal is hardened sandboxing, PRoot is not that, and the README does not claim otherwise.
Data boundaries, Web Chat and the HTTP API
The README is more explicit about data flow than many projects of this scope. Chats, characters, memory and model configuration are stored locally by the app. When you use a cloud model, requests go from the device to the provider you configured, and the README states that Operit does not host chat inference.
That last sentence is the important one. Operit is a client. Your prompts leave the device only along the path you set up, but they do leave it.
The README also notes that the marketplace, MCP, Skills, voice and drawing features may connect to third-party services. Each of those is a separate trust decision, and the README does not enumerate what each service receives.
The optional LAN Web Chat and HTTP API are off by default. Enabling them requires configuring a Bearer Token, and the README asks you to assess the LAN exposure risk first. Android Intent and broadcast integration is likewise described as something to give only to trusted apps. If you enable the HTTP API on a shared network without a token, you have exposed an agent with filesystem tools; the README's default of off is the safe state, and it stays safe only if you leave it there or configure it deliberately.
Where Operit AI is the wrong tool
Three cases stand out.
First, non-ARM64 and non-Android. There is no documented x86 build, and iOS is not in this repository. The README directs cross-platform interest to Operit 2, which is a separate implementation, so switching platforms means switching codebases.
Second, anything that needs a stable, scriptable interface. The README documents a Web Chat and an HTTP API, but both are off by default and gated behind a Bearer Token, and no API reference appears in the repository's own documentation. If you want to call an agent from CI, the CLI story here is thin; the operit2 CLI/TUI belongs to the other repository.
Third, unattended automation on a device you also use. The three-level tool permission model exists precisely because automatic allow is risky. The README's own note about PhoneAgent and AutoGLM needing device support and permissions means UI automation is not guaranteed on every handset. An agent that half-works on your specific ROM is worse than no agent, because you will not know which failures were the model and which were the device.
How it compares with a hosted agent runtime
The obvious alternative shape is a hosted or desktop agent runtime that drives a device over ADB, keeping the reasoning and the tool execution off the phone. The difference in approach is where the trust boundary sits. A hosted runtime centralises logs and credentials on a server you control, and the phone becomes a target rather than a host. Operit inverts that: the agent, the model configuration, the memory and the tool execution all live on the handset, and the phone's own permissions are the security boundary.
That inversion is the reason Operit needs accessibility, Shizuku or Root at all. A desktop runtime driving ADB does not need an accessibility service, because it is already on the other side of the debug bridge. Operit has to earn the same reach from inside the device, which is why the README spends space on permission tiers and download-channel warnings.
The trade-off is maintenance and observability. On-device execution means no central audit log unless you export one, and no way to revoke a session from a server. It also means the agent keeps working when the network to your desktop does not. For a single user automating their own phone, that is a reasonable trade. For a fleet, it is not.
Licence, releases and the cost of keeping up
Operit is licensed under LGPL-3.0. That is a copyleft licence with a linking exception, and it is stricter than the MIT or Apache-2.0 terms common in this space. If you plan to ship a modified Operit or link it into a proprietary app, the licence terms are the first thing to read, and this article is not legal advice. The repository also carries a package.json whose own license field says ISC, which is a discrepancy worth resolving with the maintainers before you rely on either statement.
On maintenance, the last push to the default branch was on 2026-09-09, and the most recent release listed is v1.12.1 on 2026-08-08, following v1.12.0 on 2026-07-01 and v1.11.0 on 2026-05-16. The release cadence through 2026 has been roughly monthly, and the README's version summary shows each release bundling several subsystems rather than one fix. That is a lot of surface area moving at once, and it is the real upgrade cost: a release that touches the marketplace, the workspace and the ToolPkg runtime at the same time is harder to regression-test than a narrow one.
Backup matters here. The README lists automatic backup, chat export and import, and role-card export with QR sharing, so there are documented paths for getting your data out before an upgrade. Use them. The README does not document a rollback procedure for a failed upgrade, so the export is your fallback.
Editorial conclusion
Adopt Operit AI if you want an on-device agent that can touch the file system, a terminal and app UIs, and you are willing to work through the permission model on a spare ARM64 phone. Do not adopt it if you need iOS, x86 or an audited multi-tenant deployment, and do not enable Web Chat or the HTTP API until you have configured the Bearer Token and decided the LAN exposure is acceptable. Verify first that your device is arm64-v8a and on Android 8.0 or higher, that you downloaded the APK from the Releases page or operit.app, and that the tool permission setting is on the ask mode you expect before you let an agent run unattended.
Frequently asked questions
Which Android versions and devices can run Operit AI?
The README states Android 8.0 (API 26) or higher, and ARM64 only (arm64-v8a). There is no documented x86 build, so check your device ABI before downloading the APK.
Does Operit AI need Root or Shizuku to automate other apps?
No single path is required. The README lists accessibility, Shizuku (described as ADB-level debugging rights) and Root as separate UI automation channels, and notes that PhoneAgent/AutoGLM screen-vision features and virtual display need the corresponding permissions and device support.
Can Operit AI run models locally without a cloud provider?
Yes. The README lists built-in MNN inference, llama.cpp for GGUF models, and connections to local services such as Ollama and LM Studio. It also warns that memory and storage use depends on the terminal environment and installed models, so reserve space per the model's instructions.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/aaswordman-operit)