2,007 stars on your phone, but no free commercial use

Last month this site tore down a phone agent on the iPhone side: phone-harness, where Claude Code on a Mac drives a real iPhone and the Mac is the whole transport layer. This time we take the other side, where no computer is the host because the agent lives inside your Android phone. The project is omnimind-ai/OmniBot. Its README calls itself OpenOmniBot in several places while the repository is named OmniBot, an inconsistency we report as-is.

Its one-line definition: an on-device AI agent running directly on Android, combining chat, agent tools, a local workspace, and system integration in one app. But the first thing to read is not the capability list. It is the license, which is what most secondhand summaries get wrong.

Repo Facts: 2,007 Stars, and It Was Still Committing That Day

Every number below comes from the GitHub API, snapshot taken 2026-09-23. Stars, forks, and issue counts move daily, so read this as a same-day cross-section rather than a standing conclusion, and treat no star count as proof of quality.

The primary language reads Dart because the Flutter UI dominates by line count; the stack is really Kotlin, Flutter, and a React and TypeScript WebUI.

What It Actually Is: An On-Device Agent, Not Another Chat Box

OmniBot calls itself an on-device AI agent, and the argument sits in those two words. Its difference from a cloud SaaS agent is that the execution loop, not just the inference, happens on the phone. It has its own workspace, terminal, and file permissions instead of forwarding your instructions to some server. Not a consumer app, not a cloud SaaS, not an iOS solution (that is sibling project ViaVera's domain), it is a local agent runtime that ships execution capability inside an Android phone.

The README draws a line against ordinary AI chat: what it cares about is not a single round of question and answer, but the full loop from understanding to decision to execution to feedback. OmniBot claims to absorb execution and feedback too, not just understanding and decision. That makes it necessarily a permission-heavy application, since tapping, screen reading, and system control require accessibility and system-level permissions - the inherent cost of the approach, which we return to below.

Core Capabilities: Four Groups

An extensible tool ecosystem. Skills, an Alpine environment, browser access, MCP, and Android system-level tools. The heaviest item is the Alpine environment: not a simulated terminal pane, but genuine Alpine Linux running on the phone. With Skills and MCP as extension channels, the toolkit can be injected from outside instead of hardcoded at build time.

System-level abilities. Scheduled tasks, alarms, calendar creation, query and update, and audio playback control. The README is precise about division of labor: scheduled tasks execute subagent flows, while alarms are reminder-only. Hand a complete task to a subagent and it executes like a full agent.

A memory system. Short-term and long-term memory with embedding support. Long-term memory is embedded into local storage, the precondition for keeping data on device.

Productivity tools. Read and write files, browse the workspace, use the browser, and access the terminal - not phone-app abilities but something close to a miniature workstation: a filesystem, a working directory, a browser, and a shell.

Three Technical Highlights

One: on-device integration, so the phone needs no computer as host. This is the sharpest divide from most phone automation schemes, which are in substance "a computer runs the agent, the phone is the peripheral" - phone-harness being the archetype. OmniBot inverts that: orchestration, system abilities, MCP, and foreground services all execute on the phone. The upside is needing neither the same LAN nor a powered-on computer; the downside is that the phone's performance, battery, and background survival policy become the bottlenecks.

Two: Alpine plus terminal plus ReTerminal gives the phone a real command-line workspace. The architecture listing includes a ReTerminal/core/ module for embedded terminal components, acknowledging RohitKushvaha01/ReTerminal upstream. The point is not the novelty of typing commands on a phone; it is that the agent's work surface and the human's work surface are unified. The agent works in the same filesystem you can open at any moment. Auditability is the most solid advantage a local agent holds over a cloud one.

Three: the Remote Codex bridge, which pipes a computer's Codex into the phone. On a computer where the Codex CLI is installed and logged in, start the bridge.

npx @thuocean/codex-bridge

Choose the LAN address and token mode in the terminal UI, then scan the QR code from the app's Codex settings. Nothing reruns Codex on the phone; the bridge attaches the computer's existing execution capability to the phone as a front end.

The bridge runs over the LAN and authenticates through a token mode, fitting my-computer-plus-my-phone on one trusted network, not the public internet. Mapping it outward hangs a computer's code execution capability on an address others can reach, and it is not worth it.

Getting It Running: From Settings to Skills

1. From the left sidebar's settings page, configure AI capabilities and the provider, then the scenario models.
2. Memory embedding must use an embedding model, with no substitute; other scenarios prefer multimodal or vision-capable models.
3. The Alpine environment usually initializes automatically at startup and is manageable from settings; no manual Linux install.
4. Skills: send a skills repo link to the assistant and let it install. The README recommends https://github.com/OpenMinis/MinisSkills.

Two more details. The app exposes a local service under Settings, Local Service, giving an address and a Token, with a default port of 8899 (use the address the app actually shows); WebUI development points VITE_WEBCHAT_PROXY_TARGET at the device's LAN address. The module layout reads fastest straight from the official listing:

OpenOmniBot/
├── app/                        # Android host app: entry point, agent orchestration, system abilities, MCP, services
├── ui/                         # Flutter Android UI: chat, settings, tasks, and memory
├── webchat/                    # React + TypeScript WebUI; Vite builds the static bundle packaged by Android
├── baselib/                    # Shared core libraries: database, storage, networking, model config, permissions
├── assists/                    # Shared task lifecycle and chat/model coordination
├── uikit/                      # Native overlay UI: floating ball, overlay panels, half-screen surfaces
└── ReTerminal/core/            # Embedded terminal experience modules

To build it you need Flutter SDK 3.47.2+, JDK 17+, Node.js 20.19+ or 22.12+, and pnpm 10.28.0 (the last two for the WebUI). The main build and install command is:

./gradlew :app:installDevelopStandardDebug -Ptarget=lib/main_standard.dart

The version bar is not low: with Flutter 3.47 and JDK 17, an unaligned toolchain stalls at flutter pub get. This is held to an engineering project's standard, not download-an-APK-and-play.

The License Red Line: AGPL v3 Covers Non-Commercial Only, and Commercial Use Requires a Signed License

OmniBot is not a "just use it" open-source project. The repository-root LICENSE (592 characters) states that the project uses Segmented Dual Licensing.

The open-source side is GNU AGPL v3, free only under specific conditions: the use case is non-commercial, or the use is for personal, educational, or research purposes, and in that case use by any organization is prohibited. An organization doing research does not qualify, and inside AGPL v3 you still carry the source-code obligation.

The commercial side is a Commercial License, signed in advance. Two triggers apply, either sufficient: use for commercial purposes (any service or product that directly or indirectly generates commercial benefit), or a wish to avoid the AGPL v3 source-code disclosure obligation. So a company wanting internal use without publishing its own modifications still needs a license. The application entry point is https://omnimind.com.cn, and the maintainers reserve the right to update the licensing policy through official channels.

A decision table makes it clearer:

Three conclusions matter. First, do not compress it into "AGPL open-source software" and stop there; everything outside the AGPL preconditions belongs to the commercial license. Second, do not call it free for commercial use, since a signed license is a direct requirement of the text. Third, an organization is outside the free scope even when doing research.

One detail trips up automated compliance checks: the GitHub API's license field is NOASSERTION, and that value is unreliable, since the recognizer could not map this license onto an SPDX identifier. Any tool screening licenses from API fields fails here; the LICENSE text is the authority.

Our Take: The Phone Turns From Client Into Execution Host

OmniBot's claim compresses into one sentence: it turns the phone from a client into an execution host, and the value lies in keeping data and execution local. Files, workspace, memory embeddings, and terminal operations stay on one device, without handing data to a cloud service just to use an agent. That is the one irreplaceable argument for on-device.

The costs are equally clear. The first is highly concentrated permissions: reading and writing files, calling a terminal, controlling calendar and audio, and operating the interface all demand substantial system permissions, including accessibility and system-level abilities - inherent to any on-device design. The question is whether you will hand those permissions to an application, and if uncertain, start on a spare phone. The second is that running an agent on a phone has not been validated at scale for stability: Android background survival policies, vendor battery management, and the treatment of foreground services all affect whether long tasks finish. 2,007 stars and 27 open issues show an active project, not one proven across the device fleet. Test it on a secondary device; do not drop it into production.

The division of labor with our earlier article matters: our phone-harness teardown of 2026-08-22 covers an iPhone driven by a Mac harness, with the computer as host. This article covers a native on-device Android agent, with the phone as host. Different platform, architecture, and licensing; read them side by side.

To place this class of capability against its peers, compare our five-way comparison of mobile GUI agents. For movement upstream in models and platforms, Alibaba's Qwen Intelligence release covers another thread. And to turn an Android phone into an agent host yourself, walk through our SOP for running an agent on Android.

Closing thought: OmniBot proves that a phone can serve as an agent's host. It does not prove that phone agents are mature enough to use casually. The first is a capability claim, the second an engineering claim, and between them sits your own acceptance testing.

FAQ

Q1: Is OmniBot free and open source? Can I use it commercially? A1: It uses segmented dual licensing. The free scope covers non-commercial use or personal, educational, and research purposes only, and use by any organization is prohibited. Commercial use, or avoiding the AGPL v3 disclosure obligation, requires a signed license in advance (omnimind.com.cn).

Q2: Can I trust the license label on the GitHub page? A2: No. The API's license field is NOASSERTION, because this license is not in the recognizer's identifier set. Use the repository-root LICENSE (592 characters).

Q3: Is this the same kind of thing as phone-harness? A3: No. phone-harness has an iPhone driven by a harness on a Mac, with the computer as host; OmniBot is a native on-device Android agent running on the phone. Platform, architecture, and licensing all differ.

Q4: Is phone compute enough, and why is the Remote Codex bridge needed? A4: They are complementary. On-device handles orchestration, the workspace, the terminal, and system abilities; the Codex bridge attaches a Codex CLI already installed and logged in on a computer, over the LAN with token mode and a QR code. Keep it on the trusted LAN.

Q5: For a local setup, where does it usually get stuck? A5: Two places. Model configuration, where Memory embedding must use an embedding model while other scenarios prefer multimodal or vision models. And the environment: Flutter SDK 3.47.2+, JDK 17+, plus Node 20.19+ or 22.12+ and pnpm 10.28.0.

Sources

• GitHub repository omnimind-ai/OmniBot: README and the repository-root LICENSE (592 characters)
• Repository facts from the GitHub API, snapshot 2026-09-23: 2,007 stars / 144 forks / Dart / created 2026-03-18 / last push 2026-09-23 / 27 open issues
• Licensing conclusions drawn from the LICENSE text, not the API's NOASSERTION value
• Related reading: phone-harness teardown, five-way comparison of mobile GUI agents, SOP for running an agent on Android, Alibaba's Qwen Intelligence release

Based on the README and LICENSE texts as of 2026-09-23; star counts are a same-day API snapshot and change daily.