What happened
Mika is an open-source Android project presented as a private AI assistant that operates apps, browses the web, and completes tasks on a user’s behalf. The repository’s public history describes version 0.1.0 as its first public beta. The latest visible commit is labeled version 0.1.13, following releases 0.1.11 through 0.1.13 on October 30.
Its central design choice is a hidden virtual background screen. Rather than taking over the foreground display, Mika can perform actions there while the phone remains usable. The project says it can work in apps, use an embedded browser, and run scripts in a local Linux sandbox. The result is a phone-focused computer-use loop whose execution is separated from the screen the person is actively using.
Mika does not describe a hosted Mika service. The initial public-beta commit says users bring their own model API key; the project materials also describe a ChatGPT sign-in option. Setup uses wireless debugging and does not require root access. The repository’s installation documentation also describes connecting the phone to a computer by USB so a desktop AI assistant can help check the device, install the app, enable notification and accessibility permissions, exempt it from battery restrictions, and start the phone assistant through wireless debugging or USB.
The project includes a live task view and defines situations where control should return to the person: logins, verification steps, and payment. Recent repository changes make its approval policy narrower: the cited change says confirmation is requested for spending money, with the amount shown on screen, while other actions may proceed without confirmation. The project also offers an autonomous mode described as allowing even payment actions without prior confirmation.
Mika is still explicitly early. The supplied project description calls it an early public beta mainly tested on one Android 14 phone. Its built-in app knowledge is written in Chinese. A recent change also adds pacing controls—fast, standard, and human-like—and limits screen changes for apps that restrict rapid actions. These are implementation details, not evidence that the agent is reliable across phones, apps, locales, or high-risk workflows.
What the archive adds
This is a new fact on a related mobile-agent thread. nanoMuse framed its cross-device proposition around one shared agent identity across phone, desktop, and web. Mika instead foregrounds how an Android agent executes tasks in the background on the phone itself.
Trend signal
Mika weakly supports Agent-ready software exposes capabilities. It does not make third-party apps agent-ready through formal integrations; it works through the existing phone interface. But its explicit execution modes, sandbox, live task view, and payment handoff illustrate how a mobile agent must expose bounded operational capabilities rather than only present a chat prompt.
Why now
The timing is the project’s first public beta and rapid follow-on revisions. The repository identifies 0.1.0 as the first public test release, while the visible history already shows version 0.1.13. That makes this less a mature product launch than an observable reference implementation whose safety and interaction policies are changing quickly.
Connections to other events
The closest related Field Note is nanoMuse, another open-source personal-agent project spanning devices. The contrast is substantive: nanoMuse emphasizes a shared identity across surfaces, while Mika’s supplied materials emphasize phone execution, background operation, and intervention at risky UI moments.
Why it matters
Mobile agents face a harder product problem than desktop chat: the device contains communications, payments, account flows, and apps that often have no clean API for an agent. Mika makes several concrete architectural choices worth examining: it runs work away from the foreground display, keeps a live task view, uses a local sandbox for scripts, and identifies takeover points around authentication, verification, and money.
For builders, the lesson is not that UI automation is ready to replace dependable integrations. The source does not establish that. It is that a usable mobile agent needs an execution model and an intervention policy as much as it needs a capable model. A background screen may preserve device usability; an explicit payment boundary may make risk legible. Both are product decisions that can be tested independently of model quality.
What happens next
- Mika will continue to revise interaction and approval behavior during its public-beta phase (3 months, 70%). Watch for: tagged releases that change confirmation, autonomy, or execution controls.
- The project will document or test a broader set of devices and app environments (6 months, 55%). Watch for: expanded compatibility claims or evaluation material beyond one Android 14 phone.
Limits and uncertainty
The source is a project repository, not an independent evaluation. It does not provide success rates, benchmark results, supported-app coverage, security review, privacy assessment, model costs, or evidence of reliable operation outside the stated early testing context. The hidden-screen design and local sandbox are architectural descriptions, not proof of isolation or safety. The current materials also show fast-moving behavior around approvals and autonomy, so teams should not infer a stable risk policy from a single version.
Skill to build now
Map a mobile agent workflow into explicit action classes before automating it. This week, choose one low-risk task and label every step as read, navigation, data entry, external submission, authentication, verification, or payment. Decide which classes can run unattended, which require a live task view, and which always hand back to a person. That exercise produces a concrete approval boundary before a model is given control of a device.
Reader takeaway
Mika is an early open-source reference for Android computer use, not evidence that phone agents are production-ready. Its notable contribution is operational: background execution lets the person keep using the phone, while task visibility and takeover points acknowledge that UI automation needs clear boundaries.
Open question
Can the project demonstrate reliable task completion across varied Android devices and apps without widening its autonomy faster than its verification and permission controls?