What happened
Mika released version 0.1.13 on GitHub. The release adds a “Start from a computer” path for launching Mika’s phone helper when an Android phone is connected to a computer by USB cable. The stated purpose is to avoid wireless-debugging pairing, particularly when pairing repeatedly fails. After a phone restart, the release says the command must be run again unless wireless debugging is paired so that startup can recover automatically.
The project also added an Install section at the top of its README. Its proposed workflow is unusual but concrete: a user can send a one-sentence request to an AI agent on their computer that is able to execute commands. That agent can follow Mika’s installation documentation to check the phone, download and install Mika, and enable the required permissions. The release is explicit that the user, rather than the desktop agent, enters the API key inside Mika.
A second set of changes concerns how Mika operates apps. Text entry now happens progressively rather than all at once, and pauses between actions vary in length. For apps that are described as prone to bot detection, the release applies a slower pace and limits the number of screens browsed during one task. Users can select Fast, Standard, or Human-like under Settings, then While working, then Operating pace; Standard is the default. The release names Xiaohongshu, WeChat, and Douyin as examples of apps where this slower behavior matters.
Mika also broadens custom-provider configuration. Users can give custom providers names, which lets two API keys associated with the same endpoint be stored separately. Custom providers may now use the OpenAI Responses API. For Anthropic models, the release says conversation history is cached as well, so long tasks do not pay the full price again at every step. Finally, it says that some systems will no longer classify Mika as a game and restrict its refresh rate. Existing users can install the release over an older version while retaining chats and settings.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
No supplied pattern is a genuinely direct fit. The release is implementation evidence about one Android agent, rather than evidence sufficient to establish a broader product or infrastructure shift.
Why now
The release frames USB startup as a response to a specific deployment failure: wireless-debugging pairing can fail repeatedly. It also addresses the operational reality that a phone restart changes the startup path unless wireless debugging is configured for automatic recovery. These are adoption details, not merely new model options.
Why it matters
Teams experimenting with agents that act through consumer mobile apps often focus first on the model and its prompts. Mika’s release emphasizes other constraints that can determine whether a workflow is usable: connecting a physical device, granting permissions, restarting reliably, supporting different provider interfaces, and controlling the pace of visible actions.
The provider changes matter because model choice need not force a different phone-agent surface. Responses API support expands the set of custom configurations the app can address, while cached Anthropic conversation history is specifically aimed at reducing repeated cost in longer sessions. The pacing controls are equally consequential: they turn execution behavior into a user-facing setting, with a default, a slower mode, and task-level browsing limits rather than leaving timing entirely implicit.
Limits and uncertainty
The release notes describe features and intended behavior, but do not provide benchmark results, reliability rates, cost figures, or comparisons with alternative Android automation systems. They do not establish whether USB startup works across Android versions, device vendors, or enterprise-managed phones. The note also says that slower pacing is intended to make apps less likely to flag activity as automated, but it does not demonstrate success rates or address platform terms, account risk, or policy compliance. OpenAI Responses API support is stated, yet the release does not enumerate supported models, provider-specific limits, or authentication details.
Skill to build now
Treat device connection and recovery as part of an agent’s runbook. This week, take one mobile-agent workflow and write down the full sequence: initial connection, permissions required, model credential ownership, what happens after a phone restart, and how an operator confirms that the agent is ready. Then separate configurable execution behavior—such as speed, pauses, and task bounds—from the task prompt. That exercise makes the operational contract inspectable before a team tries to scale the workflow.
Reader takeaway
Mika 0.1.13 is not chiefly a model release. It is a reminder that usable phone agents depend on the surrounding operating system: reliable device startup, permissioned installation, portable provider configuration, predictable session cost, and explicit controls over how actions are carried out.
Open question
Will Mika publish evidence that its pacing controls improve task completion or reduce automated-activity flags across the apps and devices it targets?