Aether: a Pi-based AI agent that runs on Android, iOS and macOS

The gap Aether is trying to fill: Pi extensions on a touchscreen

Pi is a TUI-oriented agent framework. Aether's README states it is built on top of Pi and natively supports loading standard Pi Extensions, then adds that to bring those extensions to mobile touchscreens it exposes its own Extension API. That sentence is the whole product thesis. The target user is someone who already has Pi extensions working in a terminal and wants the same tool-calling behaviour on a phone or a Mac without rewriting the extension. The README names three official adaptations: pi-web-access for web search across 20+ providers plus GitHub cloning, PDF extraction and video understanding; pi-mcp-adapter as an MCP gateway over Stdio, Streamable HTTP, SSE and Unix domain sockets; and pi-subagents for parallel background sub-agents with `@handle` prompt mentions. Those three extension descriptions are the most concrete evidence in the repository of what the agent is expected to do. Everything else in the README is positioning.

What the Pi harness and the Alpine VM actually contribute

Two mechanisms are named. The first is the Pi Harness Kernel, described as providing LLM provider compatibility and the agent execution loop. The second is a built-in Alpine VM, described as an automatically installed Alpine Linux environment to run shell commands and tools out of the box. Put together, the data flow implied by the README is: the app collects a prompt, the Pi harness runs the model loop and dispatches tool calls, and shell-level tools execute inside the Alpine environment rather than on the host. That is a meaningful design choice on mobile, where a raw shell is not normally available to an app. It also means the first run likely depends on fetching an Alpine image, though the README does not say how large it is, where it is downloaded from, or whether it can be pre-seeded offline. On Android there is a second path: optional Shizuku and Termux integration for direct device manipulation and automation. Shizuku is a well-known way to grant apps elevated permissions without root, and Termux provides a userland. The README marks this Android only, so the host-control story on iOS and macOS is the Alpine VM alone.

Installing it: what the README gives you and what it does not

The README's Quick Start section is one line: a link to aether.baimoqilin.com/docs/quickstart. There is no `git clone` command, no Gradle invocation, no build variant, no signing instructions in the repository text supplied. For a Kotlin project the expectation would be a Gradle wrapper, but the README does not show one and the repository layout is not included in the material, so any build command here would be a guess and is therefore omitted. What the README does specify concretely is extension installation: extensions are installed as zip packages through Settings, then Extensions, then Import extension. That is the only UI path documented end to end. Extension authors are pointed at aether.baimoqilin.com/docs/extensions/overview.md, and the README says the Extension API lets extensions inject custom settings cards, interactive composer widgets, overlay transcript viewers, prompt interceptors and semantic tool titles. Those five injection points are the real interface surface, and they are the thing to read before writing an extension.

The extension API is a mobile shim, and that is a constraint

A Pi extension written for a terminal has no concept of a composer widget or a settings card. Aether's API adds those, which is what makes porting possible, but it also means an extension that wants a rich mobile presence has to be modified rather than dropped in unchanged. The README is honest about this in one direction: it says Aether provides a rich Extension API so that TUI-oriented extensions can come to touchscreens. It is less clear in the other direction. If an extension injects a composer widget, what happens on macOS where the window is a desktop window, not a phone screen? The README does not say whether the API is uniform across the three platforms or whether macOS gets a different rendering. Similarly, prompt interceptors and semantic tool titles are described as capabilities, not as contracts. There is no schema, no version number and no compatibility statement in the supplied material. Anyone planning to depend on this API should read the overview document first and treat the five injection points as the boundary of what is promised.

Where Aether is the wrong choice

Three cases stand out. First, if you need a reproducible build from source, the README does not provide one; the quickstart is external, and the material contains no build commands, dependency list or CI description. Second, if you need a documented list of supported LLM providers, the README claims the widest LLM provider compatibility via Pi but never enumerates a single provider for the core agent. The extension table lists search providers (OpenAI, Brave, Exa, Tavily, Perplexity, Gemini, SearXNG) but those belong to pi-web-access, not to the harness. Third, if you are on iOS and expect the same host-control features as Android, the README explicitly scopes Shizuku and Termux to Android only, leaving the Alpine VM as the sole execution route, and it does not describe how that VM behaves under iOS sandbox rules. There is also a maintenance signal that should be read literally rather than charitably: the README states the project is developed sporadically by a 15-year-old student during spare time and is still actively iterating. Release cadence in the supplied data is consistent with that (2.1.4 on 2026-08-21, 2.1.5 on 2026-08-23, 2.1.6 on 2026-09-04), but cadence is not the same as support.

GPL-3.0, and what that means for extension authors

Aether is licensed GPL-3.0. The README states this plainly and offers no dual-licensing option, no contributor licence agreement and no exception for linking. For someone using the app on their own device this is unremarkable. For someone distributing an extension, the question of whether their code is a derivative work depends on how the Extension API is loaded and what it links against, and the repository text supplied does not answer that. The three official extensions live in a separate GitHub organisation (AetherExtensions) rather than in the main repository, which suggests they are maintained as separate projects, but the README does not state their licences. If you intend to ship a commercial extension, read the Pi Extensions repository and the Aether extension overview before writing code, and get your own legal read on the boundary. This article is not legal advice. The practical point is narrower: GPL-3.0 is a copyleft licence, and the README does not carve out an extension exception.

The alternative: run Pi in a terminal instead

The obvious comparison is Pi itself, at github.com/earendil-works/pi, which Aether's README links as the source of the extension standard. The difference in approach is not features, it is where the agent lives. Pi is TUI-oriented: it runs in a terminal, on a desktop OS, with the shell and filesystem directly available. Aether reimplements that experience as a native Kotlin app on Android, iOS and macOS, adds a GUI, and replaces direct shell access with an Alpine VM plus, on Android, optional Shizuku and Termux bridges. If your work happens on a laptop with a terminal open, Pi is the shorter path and Aether's mobile UI work buys you nothing. If your work happens on a phone, Pi has no answer, because there is no terminal to run it in. That is the honest split. Aether is not a better Pi; it is Pi's extension model relocated to a platform Pi does not target, at the cost of an extra virtualisation layer and a UI-shaped API that extensions must opt into.

What to check before you install

Start with the quickstart at aether.baimoqilin.com/docs/quickstart, since the README delegates the entire setup path there and the repository text alone is not enough to build or install. Then read aether.baimoqilin.com/docs/extensions/overview.md before assuming an existing Pi extension will work unmodified; the five documented injection points (settings cards, composer widgets, overlay transcript viewers, prompt interceptors, semantic tool titles) are additions, not a compatibility layer. Then check the release page for 2.1.6 and confirm there is an artifact for your platform, because the README names three platforms and the material does not show per-platform packaging. Finally, decide whether you are comfortable with a single-maintainer, spare-time project under GPL-3.0 before you build a workflow on it. The three official extensions are the strongest signal that the extension model is real rather than aspirational; the absence of a build recipe in the README is the strongest signal that the project is still optimised for its author's own workflow.

Editorial conclusion

Adopt Aether if you already run Pi extensions and want them on a phone or Mac, and you accept that the quickstart lives off-repository at aether.baimoqilin.com/docs/quickstart rather than in the README. Do not adopt it if you need an iOS build path, a documented provider list, or a project with more than one maintainer, since the README states it is developed sporadically by a 15-year-old student in spare time. Before installing, verify three things: whether the release you want ships a signed artifact for your platform, what the Pi Extensions repository at github.com/earendil-works/pi actually defines, and whether the Alpine VM download happens at first launch, because the README says the environment is installed automatically but does not say when or from where.

Official sources

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