Zhou-Shilin/Aether: a Pi-framework AI agent for Android, iOS and macOS

The gap Aether targets: an agent that lives on the device, not in a browser tab

Most agent tooling assumes a terminal on a laptop. Aether aims at the opposite end: a general-purpose agent packaged as a native app for Android, iOS and macOS, with a UI that the README describes as minimalist and polished, in deliberate contrast to the idea that open source interfaces look unfinished. The audience is people who already use Pi extensions or Claude Code style workflows and want the same model on a phone, plus users who want tool calling and shell access without opening a terminal.

The repository is Kotlin-first, licensed GPL-3.0, and the last push was on 2026-09-06. The most recent release listed is 2.1.6 on 2026-09-04. The README says the project is developed sporadically by a 15-year-old student in their spare time, which is a useful signal about release cadence: recent tags exist, but the maintainer describes the effort as intermittent.

How the Pi harness, the extension API and the Alpine VM fit together

Aether is built on top of a framework called Pi, which the README credits with LLM provider compatibility and the agent execution engine itself. Aether's own contribution sits above that kernel: a mobile and desktop UI, a proprietary extension layer, and device integration. The README describes two extension mechanisms, Script Extensions and Native Mods, that let extensions inject settings cards, composer widgets, overlay transcript viewers, prompt interceptors and semantic tool titles. That list matters because it is the part a TUI-oriented Pi extension cannot do by itself: a terminal extension has no concept of a settings card or a composer widget, so Aether defines an API surface for those.

Standard Pi extensions load natively. The README names three official adaptations maintained under the AetherExtensions organisation: pi-web-access for web search across providers plus repository cloning, PDF extraction and video understanding; pi-mcp-adapter as a Model Context Protocol gateway with Stdio, Streamable HTTP, SSE and Unix domain socket transports; and pi-subagents for parallel background sub-agents with `@handle` prompt mentions. Extensions install as zip packages through Settings, Extensions, Import extension.

The built-in Alpine Linux VM is the second mechanism. The README states it is installed automatically and runs shell commands and tools out of the box, which is how an agent on a phone gets a POSIX environment without depending on the host OS. On Android only, Aether also supports optional Shizuku and Termux integration for direct device manipulation. Those are three separate trust boundaries: the LLM provider, the extension code, and the shell environment.

Installing Aether and importing your first extension

The README does not carry install steps. It points at the quickstart page instead, so treat that URL as the authoritative source for your platform. The only path the README spells out is the in-app one: Settings, then Extensions, then Import extension, which takes a zip package. There is no documented CLI equivalent and no documented rollback if an imported extension misbehaves, so keep the zip you imported if you want to reproduce the state.

For people writing their own extension rather than consuming one, the repository ships two worked examples you can read before the API docs. Their directory names, as they appear in the repository, are `examples/aether-extension/` and `examples/global-skills-mod/`, and the README sends extension developers to the overview page under aether.baimoqilin.com/docs/extensions.

The README does not describe the build process for the apps themselves. The top-level entries include `gradlew`, `build.gradle.kts` and `settings.gradle.kts`, plus `iosApp/`, `shared/`, `pi-bridge/` and `packages/`, so a source build is clearly a Gradle and multi-module affair, but no build command is given in the README. If you need to compile from source rather than install a release, that is the first thing the documentation has to answer for you.

Where Aether is the wrong tool

The extension API is the clearest limitation. It is described as Aether's own, and the README does not state a stability guarantee, a versioning scheme, or a deprecation policy for it. An extension that injects composer widgets or intercepts prompts is coupled to the app version it was written against. If you are building a plugin you intend to keep working across releases, that contract is the risk, not the agent loop.

Device control is the second. Shizuku and Termux integration gives an agent the ability to manipulate the device directly. The README lists it as optional and Android only, and does not document a permission model, an audit log, or a sandbox around what the Alpine VM and the host integration can reach. On iOS and macOS the README mentions no equivalent, so the automation story is asymmetric across platforms.

Finally, the project's own framing works against production use. Sporadic development by a single student means the release history is real but the support expectation should be low. If you need a vendor-backed SLA, a security review process, or a roadmap you can plan a quarter around, Aether is not that, and the repository does not claim otherwise.

How Aether differs from running Pi directly or using a desktop agent CLI

The honest comparison is with Pi itself, since Aether is built on it. Pi is the harness: provider compatibility, the agent loop, the extension model. Running Pi gives you the terminal-oriented experience its extensions were written for. Aether keeps the kernel and replaces the surface, adding the settings cards, composer widgets and transcript overlays that a touchscreen needs, plus the Alpine VM and the optional Android device control. The trade is that you inherit a second project's API on top of Pi's, and the extensions you care about may exist in one form and not the other.

The other comparison is with hosted assistant apps. Those ship a fixed toolset. Aether's pitch is the opposite: the toolset is whatever extensions you import, and the model is whatever provider Pi supports. That is more work for you and more surface to reason about, which is the actual cost of the flexibility.

Licence and the cost of staying current

Aether is GPL-3.0. For anyone distributing a modified Aether, that carries the usual copyleft obligations, and the repository includes a THIRD_PARTY_NOTICES.md file plus a `third_party/` directory, which suggests bundled components with their own terms. The README does not summarise those terms, so read the notices file before you ship anything. This is a description of what the repository contains, not legal advice.

Upgrade cost depends on how deeply you use the extension layer. Releases listed here run 2.1.4, 2.1.5 and 2.1.6 across August and early September 2026, roughly a two-week cadence in that window. If you only use built-in features, upgrading is an app update. If you maintain an extension against the Aether Extension API, each release is a chance that an injected widget or a prompt interceptor needs attention, and the README does not promise otherwise. Budget for reading the diff, not for a migration guide.

Editorial conclusion

Adopt Aether if you want an agent you can run on a phone or a Mac and you are comfortable reading the Pi and Aether extension docs before trusting a tool with device control. Do not adopt it if you need a documented, stable plugin contract, a non-GPL licence for a closed product, or a build you can reproduce from the README alone. Verify first: that your target platform has a published build, that the Alpine VM and the Shizuku or Termux integration behave the way you expect on your device, and that the extension API in the version you install matches the docs at aether.baimoqilin.com, because the README points there for the quickstart rather than spelling it out.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. Zhou-Shilin/Aether on GitHub