Kai 9000: an open source AI assistant with persistent memory, built in Kotlin Multiplatform
OpenClaw alternative in your pocket
At a glance
- What is it?
- Kai 9000 ships as a native app on Android, iOS, desktop JVM and the web, with local memory promotion and an Alpine Linux sandbox on Android. Here is what the repository actually documents, and where the design forces trade-offs.
- Who is it for?
- Adopt Kai 9000 if you want a single assistant that carries memory across Android, iOS, desktop and web, and you are willing to run it from Homebrew, Winget, AUR or a GitHub release rather than build it. Do not adopt it if you need a documented rollback path for memory promotion or a stable tool-calling contract across all 29 providers; the README describes the mechanism but not the failure handling.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Kai 9000 is, and who it is for
Kai 9000 is an open source AI assistant that runs on Android, iOS, Windows, macOS, Linux and the web. The README describes it as an assistant "with persistent memory", and the topic list on the repository includes kotlin-multiplatform, jetpack-compose, litert and openai-compatible. The project is licensed Apache-2.0 and the last push to the default branch was on 2026-09-11, with releases v3.2.0, v3.1.0 and v3.0.0 published between 2026-08-02 and 2026-09-07.
The intended audience is not a developer wiring up an API. It is someone who wants a chat assistant that keeps context between sessions, on the device they already carry, without sending every conversation to a hosted service. The README lists encrypted local storage for conversations, settings export and import as a JSON file, and on-device inference on Android through LiteRT. Those three items together define the pitch: your history stays local, your configuration is portable, and on Android the model itself can run without a network.
The second audience is the tinkerer. Kai supports 29 LLM providers with automatic failover, tool execution for web search, notifications, calendar events and shell commands, and MCP server support for remote tool servers. That is a lot of surface area for an app that also ships on the App Store and Play Store. The README does not explain how provider failover is ordered or how conflicts between a local LiteRT model and a remote provider are resolved, which is the first thing a tinkerer will want to know.
Persistent memory and the hitCount promotion rule
The mechanism is shown in the README's own diagram. A user message enters the Chat component, where it is combined with the prompt and stored memories before being sent to the AI. The AI can issue tool calls, the results return to the AI, and the loop continues until the turn ends. Separately, the same flow stores and recalls entries in a Memory store that holds "facts, prefs, learnings".
The interesting part is the promotion path. The diagram shows a condition, hitCount >= 5, that moves a memory out of the store and into the System Prompt, with a delete arrow back from the promoted entry. In plain terms: a fact has to be recalled five times before it stops being a retrieved memory and becomes part of the assistant's permanent instructions. That is a sensible design. It keeps the system prompt from filling with one-off details, and it means the prompt only absorbs things the user actually repeats.
Two things are not documented. The README does not say whether hitCount is incremented per conversation or globally, and it does not describe how a promoted memory is removed if it turns out to be wrong. The diagram shows a delete arrow from the promotion box back to the Memory store, but there is no description of the UI or command that triggers it. If you care about correcting a bad memory, treat this as unverified until you read the source in composeApp.
Installing Kai 9000 and running a first conversation
The README points to app store badges for iOS and Android, an F-Droid package, and a web build at kai9000.com/app. For desktop, it lists package manager commands. On macOS with Homebrew, the README gives this cask:
brew install --cask simonschubert/tap/kaiOn Arch Linux the AUR package is kai-bin, installed with yay. On Windows the Winget package identifier is SimonSchubert.Kai:
winget install SimonSchubert.KaiIf you prefer not to use a package manager, the README's direct download table points to GitHub Releases for the Android APK, macOS DMG, Windows MSI, and Linux DEB, RPM and AppImage. There is no build-from-source instruction in the README; the repository does contain gradlew, settings.gradle.kts and a composeApp module, so a Gradle build is possible, but the README does not document it and you should not assume a supported path.
After launching, the first real use is to define the assistant's behaviour. The README calls this the "customizable soul": an editable system prompt that sets personality and behaviour. Open the settings, edit that prompt, and start a conversation. Then check two things that the README documents as features but does not walk through: whether your chosen provider is reachable, and whether memories are being written. On Android, Settings > Linux Sandbox is the second stop if you want the assistant to run commands rather than only talk.
The Linux Sandbox on Android, and what it does not cover
On Android, Kai includes a Linux userland the assistant can use to run shell commands, scripts and tools. The README states it is powered by Alpine Linux, that a roughly 3 MB download sets up the userland via proot with no root required, and that optional packages including bash, curl, wget, git, jq, python3, pip and Node.js can be installed with one tap. There is also an interactive terminal for running commands manually alongside the AI. The README says everything runs sandboxed inside the app with no access to the host system.
This is the feature that separates Kai from a chat client. An assistant that can install a package, run a Python script and inspect the output is doing work rather than describing it. The proot approach is also the pragmatic choice on Android, where root is not available to a normal app.
The limitation is scope. The sandbox is documented only for Android. The README's Linux Sandbox section is explicitly headed "(Android)", and none of the desktop or web documentation in the README claims an equivalent. If you install Kai on macOS or Linux expecting the assistant to execute shell commands locally, the README gives you no basis for that. Tool execution is listed as a general feature, but the sandboxed Linux environment is not.
Where Kai 9000 is the wrong tool
The README does not document rollback for memory promotion, and it does not describe how the 29 providers are ordered during failover. Both of those are operational gaps, not cosmetic ones. If you are deploying an assistant where an incorrect remembered fact could change a decision, or where a silent provider switch could send data to a service you did not choose, Kai 9000's documentation does not currently let you reason about either.
The second boundary is platform. On-device inference is documented for Android using LiteRT only. On iOS, desktop and web, the README does not claim local model execution, so those builds depend on a provider you configure. That makes Kai a poor fit if your requirement is a fully offline assistant on a laptop.
The third is the sandbox. It is an Android feature, and the README describes it as sandboxed with no host access. That is the right default, but it also means the assistant cannot touch files outside the app. If your workflow is "read this file from my Downloads folder and summarise it", the README does not describe a path for that on any platform.
Finally, the README lists no build instructions. If your organisation requires building from source to audit what you run, you are working from gradlew and the module layout without documented steps.
How Kai 9000 differs from OpenClaw and from a plain API client
The repository description calls Kai an "OpenClaw alternative in your pocket", and openclaw is one of the listed topics. The difference the README supports is packaging and reach. Kai ships as a signed app through the App Store, Play Store, F-Droid, Homebrew, AUR, Winget and GitHub release artefacts, and it runs the same codebase across Android, iOS, JVM desktop and web through Kotlin Multiplatform. An OpenClaw user working from a terminal is not getting that, and does not need it.
The more useful comparison is against a plain API client or a hosted chat app. Those give you a model and a text box. Kai adds three layers on top: a memory store with a promotion rule, a tool loop with an MCP client, and on Android a Linux userland. The cost of those layers is that you now have state. Conversations are stored encrypted, memories accumulate, and the system prompt changes as memories are promoted. A hosted chat app keeps that state on someone else's servers and you never audit it. Kai keeps it on your device and you can export settings as JSON, but the README does not document exporting memories.
If you want a stateless assistant, Kai is more machinery than you need. If you want an assistant that remembers, the machinery is the point.
Maintenance, licensing and upgrade cost
The repository is not archived, and the last push was on 2026-09-11. Three releases landed in the five weeks before that: v3.0.0 on 2026-08-02, v3.1.0 on 2026-08-30 and v3.2.0 on 2026-09-07. A major version bump followed by two minor bumps in five weeks is a fast cadence, and it means you should expect to upgrade rather than pin and forget.
Upgrade cost depends on your install channel. Homebrew, Winget and AUR users get the package manager's update path, and the README does not describe any migration step between versions. Users on direct downloads from GitHub Releases have to fetch new artefacts themselves. The README documents settings export and import as a JSON file, which is the only backup mechanism it mentions, and it does not state whether settings files are forward-compatible across major versions. Export before you upgrade from v3.x, and keep the file.
Kai is licensed Apache-2.0, and the repository carries a THIRD_PARTY_LICENSES.md file alongside LICENSE.txt. Apache-2.0 permits commercial use and modification and includes a patent grant. It also requires that you preserve notices and state changes. The Alpine userland and the optional packages installed inside the sandbox carry their own licences, and THIRD_PARTY_LICENSES.md is where the repository collects them. Read that file before redistributing anything. This is a description of the licence text, not legal advice.
Editorial conclusion
Adopt Kai 9000 if you want a single assistant that carries memory across Android, iOS, desktop and web, and you are willing to run it from Homebrew, Winget, AUR or a GitHub release rather than build it. Do not adopt it if you need a documented rollback path for memory promotion or a stable tool-calling contract across all 29 providers; the README describes the mechanism but not the failure handling. Before installing, check that the AI provider you intend to use is reachable from your network, then open Settings > Linux Sandbox on Android to confirm the Alpine userland downloads and the terminal accepts a command.
Frequently asked questions
What is Kai 9000?
Kai 9000 is an open source AI assistant with persistent memory that runs on Android, iOS, Windows, macOS, Linux and the web. It is written primarily in Kotlin and licensed Apache-2.0.
How do I install Kai 9000 on desktop?
The README gives package manager commands: brew install --cask simonschubert/tap/kai on macOS, yay -S kai-bin on Arch Linux, and winget install SimonSchubert.Kai on Windows. Direct DMG, MSI, DEB, RPM and AppImage artefacts are linked from GitHub Releases.
Does Kai 9000 run AI models on the device?
The README lists on-device inference on Android using LiteRT, described as running models locally with no internet needed. It does not claim local model execution for iOS, desktop or web.
Community notes