kai 9000: four names for one app, and a Flatpak nobody documents

Four names for one app, one of them inherited from something else

The same application carries a different name in every distribution channel.

The repository is `Kai` under one owner. The heading on the page is Kai 9000. The website is at a domain with the number in it, and every documentation link uses that domain. The Android application identifier is `com.inspiredandroid.kai`, and the F-Droid entry uses the same identifier. The iOS listing sits under the same reverse-domain prefix.

Then the package managers, which use a third and fourth set of names: a Homebrew cask called kai from a tap owned by the same user, an Arch package called kai-bin, and a Winget identifier of `SimonSchubert.Kai`.

The odd one out is the Android identifier. A package name beginning with a different product's domain is not something you choose fresh; you inherit it, because the store listing and the update key are tied to it. So the Android app carries a vendor prefix from an earlier application, and renaming it would break upgrades for everyone who installed it.

None of that is a problem for a user. It matters for anyone writing an issue, an automation script or a reverse proxy rule, because none of those will guess which name you meant.

The competitive claim lives in the repository description and nowhere else

The repository description is two words long and they position the project against a named competitor: an OpenClaw alternative in your pocket.

The README never mentions that name. It opens with what the assistant is, an open-source application with persistent memory running on six platforms, then goes straight to installation.

So the differentiator a visitor sees in search results is one the documentation never develops. Nothing on the page explains what the alternative does differently, what was left out, or under what conditions one is the better choice. If you arrived from that description, the README answers none of the questions it raises.

What the page does establish is the scope. Six platforms: Android, iOS, Windows, Mac, Linux and a web build. And the list of what it can reach is long: web search, notifications, calendar events, shell commands, images as attachments, text to speech, an MCP client, and an autonomous heartbeat.

Two features distinguish it from a chat wrapper. The first is on-device inference on Android through LiteRT, with no internet required. The second is the sandbox described below, where the assistant can install packages and run scripts rather than only answering questions.

A Flatpak directory exists and the download table does not mention it

The install table covers six direct download formats and four package managers, and there is a seventh format on disk.

Direct downloads are an APK for Android, a DMG for macOS, an MSI for Windows, and a DEB, an RPM and an AppImage for Linux. All six come from the release page.

The package managers are the Homebrew cask for macOS, the Arch package for Linux, and Winget for Windows:

brew install --cask simonschubert/tap/kai

yay -S kai-bin

winget install SimonSchubert.Kai

The mobile stores are the App Store, Google Play and F-Droid, plus a web application.

The repository top level includes a `flatpak/` directory. No Flatpak appears in the install instructions or the download table.

So a Linux user has two documented package formats, a DEB and an RPM, plus an AppImage, and one undocumented one. Given that the Linux desktop target is new enough that the AppImage was added recently, a Flatpak may be a newer addition not yet documented, or an abandoned attempt. The page does not say which.

The three Linux formats also differ in what they assume. A DEB or RPM integrates with a system package manager and expects libraries already present. An AppImage assumes nothing and carries its own. A Flatpak assumes a sandboxing runtime and carries its own libraries but not its own kernel interfaces, which matters for an application that wants to run shell commands inside a sandbox.

That last point is worth checking before choosing the Flatpak: the two sandbox mechanisms on offer in this project are not the same kind of thing.

The Android sandbox is proot, and the architecture diagram stops mid-word

The sandbox is the feature most worth understanding precisely, because the security claim and the mechanism are not the same kind of statement.

What runs is Alpine Linux in a userland of roughly three megabytes, set up through proot, with no root required. Optional packages install with one tap and include bash, curl, wget, git, jq, python3, pip and Node.js. There is also a built-in terminal so you can run the same commands by hand as the assistant does.

The claim is that everything runs sandboxed inside the application with no access to the host system. Proot provides that isolation by intercepting system calls in user space rather than by using a kernel feature. The practical consequences are the ordinary ones for that approach: it is portable and needs no root, and it is not a boundary the kernel enforces.

Enabling it is a settings toggle, and the build script for the image sits at the repository root.

The architecture diagram on the same page is cut off mid-word. The box drawing stops at a line reading `tool cal`, which is the beginning of a tool call label, and nothing follows it. So the loop the diagram is meant to show, where the assistant calls a tool and receives a result, is described in the text beneath the diagram rather than drawn.

Memory promotion has a numeric threshold and a heartbeat that reads email

The three mechanisms behind the persistent memory claim are all specified more precisely than the marketing word suggests.

The first is storage and recall. The assistant stores facts, preferences and things it has learned, and recalls them in later conversations. The second is promotion into the system prompt. Memories that have been used enough are made permanent:

> Memories that prove useful (5+ hits) can be promoted into the system prompt permanently.

Five hits is a threshold, not a judgement, and it is a threshold you cannot change from the interface. It is also a sensible design for something that should not silently rewrite its own instructions.

The third is the heartbeat. A background self-check runs every thirty minutes. It reviews memories, pending tasks and emails, and if something needs attention it notifies the user; otherwise it stays silent.

That last clause is the important one. Silence is the default behaviour, so a heartbeat that fires every thirty minutes is not a chatty assistant; it is a periodic check that only interrupts when it has something.

Reading email is the part worth checking against your own threat model. The page does not say whether that means a local mail account the assistant was given access to, or an integration, and the phrase appears once with no further detail. The whole feature can be disabled in settings, but the documentation does not say so.

MCP support is Streamable HTTP only, with thirteen curated servers listed

The Model Context Protocol support is narrower than the phrase usually implies.

You add a server through settings, and the page says you can connect to any Streamable HTTP endpoint. That is one of the two transports the protocol defines. The other is standard input and output, which is how a local server process is normally attached, and the page does not mention it.

So if the tool you want is a local process rather than a hosted service, this client is not the integration point for it.

What is provided instead is a curated list of thirteen servers, presented as popular and free, most of which need no API key and are added with one tap:

- documentation lookup for libraries and for web platform references - a wiki generator for any GitHub repository - web search, content extraction, and a service that converts pages to markdown - stock data and crypto prices - global weather and air quality - flight search and domain availability across more than a thousand top-level domains - a link, phone and email scam checker - a diagram and whiteboard tool - real-time transit information for one city

That is a strong starting set and it is honestly labelled as a convenience list rather than a capability claim. The important limitation is the transport, not the list.

The sponsor is also the first provider in the list, with campaign parameters attached

One commercial service appears in three places on the page, and in the first position each time.

It is the sponsor, placed above the installation instructions, linked with three campaign parameters in the URL. It is the first entry in the supported services list, also with those parameters. And it heads the feature list entry for multi-service fallback, which is described as thirty providers with automatic failover.

The provider list itself is worth reading for what it tells you about coverage: the major western model providers, several aggregators, two hardware-accelerated inference services, a cloud-hosted Ollama, a Chinese set of providers, an AI Horde instance, and a compatibility option for any OpenAI-shaped endpoint. It also lists an on-device option through LiteRT on Android and a free tier that needs no API key.

Automatic failover across thirty providers is the design decision that matters most for anyone depending on this. It means a model outage is not your problem, and it also means the request may be routed to a provider you did not choose and have no relationship with. The page does not say whether failover is ordered, whether it is configurable, or whether it can be disabled.

That is the question to ask before relying on it. A provider list is easy to publish and a failover policy is a design commitment, and only one of the two is on the page.

Editorial conclusion

Kai 9000 suits someone who wants an assistant on a phone with real local capability rather than a wrapper around a web chat, and the Android sandbox plus on-device inference are the parts that are genuinely unusual. Three things to check before you commit. Read the security note on the sandbox with the mechanism in mind, because the isolation is userspace interception rather than a kernel facility. Check that the provider you want is on the list before you install, since failover across thirty providers is the design rather than a fallback you configure. And if you are on Linux, note that a Flatpak exists in the repository but not on the download page, so you are choosing between formats the documentation does not compare.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. SimonSchubert/Kai on GitHub