LastChat: An Android AI Client Forked from RikkaHub, With RAG Memory and a Local Python Sandbox
A Fork of Rikkahub with an overhauled UI and feature additions
At a glance
- What is it?
- LastChat is an AGPL-3.0 Kotlin app that keeps chat history and vector memory on the device while adding a PRoot-based Python engine, QuickJS, and MCP support. The interesting question is not the feature list but what a fork maintained by AI agents implies for upgrades and trust.
- Who is it for?
- Adopt LastChat if you want a local-first Android client with RAG memory, MCP, and a Python sandbox, and you accept that upstream fixes from RikkaHub will not arrive automatically. Do not adopt it if you need a stable API surface, a documented upgrade path, or a project with a published roadmap.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 3 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
The Problem LastChat Targets: Cloud Chat Clients That Keep Your Context
Most Android chat front ends for hosted models behave like thin clients. Your conversation history lives in someone else's account, your assistant personas are recreated by hand on every device, and any memory feature is whatever the provider ships. LastChat takes the opposite position: the README states the project aims to provide a privacy-focused and highly personalized AI chat experience on Android, and that chat history and vector memory are stored locally on your device. That second clause is the substantive one. A local vector store means the embeddings used for retrieval never leave the phone, which is a different privacy claim from merely not sending the raw transcript.
The target user is narrower than "anyone who chats with an LLM." LastChat assumes you already have API keys, because it is a BYOK client: the topics list includes byok and api-client alongside multi-provider-ai-support and openrouter. It also assumes you want to author assistants rather than pick from a catalogue, given the unlimited custom assistants, the tagging system, and the import/export of assistant configurations. If you want a single polished chat window pointed at one vendor, the local-first architecture is overhead you will pay for in setup time and never recover.
How LastChat Is Put Together: Compose, Room, Koin, and Two Embedded Runtimes
The README lists the stack directly: Kotlin and Jetpack Compose for the interface, Koin for dependency injection, Room and DataStore for persistence, WorkManager and AlarmManager for background tasks, and QuickJS for JavaScript. The persistence split matters. Room is the structured store, which is where chat history and the vector memory would plausibly live, while DataStore holds the key-value settings such as provider credentials and assistant configuration. WorkManager and AlarmManager together suggest that scheduled work (backup runs, background fetches) is meant to survive the app being killed, though the README does not say which jobs are scheduled or how often.
The two embedded runtimes are the part that distinguishes LastChat from a conventional client. The Python engine is described as built-in and powered by Workspaces and PRoot-based Linux environments. PRoot is a user-space construct: it emulates enough of a Linux filesystem and syscall layer to run a distribution without root, which is why this is viable on a stock Android device. The cost is that PRoot is not a container and not a VM. It shares the host kernel, and its isolation properties differ from what the word "sandbox" usually implies. The README does not describe what the Python environment can reach on the filesystem or network, and that omission is the single largest gap in the documentation.
QuickJS handles JavaScript, a much smaller commitment: an embeddable interpreter without a browser engine behind it. Web search, MCP servers, image generation, and TTS are listed as integrations but the README gives no protocol detail for any of them. Treat the feature list as a map of intent, not a specification.
RAG Memory in LastChat: Embeddings, Retrieval, and What the README Does Not Say
The README describes RAG Memory as a system where assistants can remember details from past conversations using embeddings, and the topics list retrieval-augmented-generation and conversational-memory. The screenshot set includes a memory settings screen, which implies the behaviour is configurable rather than fixed. What is not stated: which embedding model is used, whether embeddings are computed on-device or through a provider API, how chunks are sized, when retrieval is triggered, and whether the user can inspect or delete individual memory entries.
That last point is the one to press on. A local vector store is a privacy advantage only relative to the alternative, not in absolute terms. If embeddings are produced by a remote embedding endpoint, then fragments of your conversations are still leaving the device, just in a different form. The README's local-first claim is about where the store lives, not about where the vectors are computed, and those are separate questions. Anyone evaluating LastChat for sensitive material should resolve that before trusting the framing.
The memory feature also interacts with the assistant model. Because memory is scoped to assistants and assistants are user-created, a poorly tagged set of personas can cross-contaminate retrieval. The README mentions a tagging system for organizing assistants but does not say whether tags partition the memory index or are purely cosmetic.
Building and Running LastChat from the Repository
The README does not include a build or install section, so there is no documented command sequence to quote. What can be stated from the repository metadata: the project is Kotlin, the default branch is named LastChat, and the three most recent releases are tagged 1.4.5 (2026-07-02), 1.4.4 (2026-06-30), and 1.4.3 (2026-06-12). A Gradle wrapper is the conventional entry point for a Kotlin Android project of this shape, but since the README does not name the tasks, the honest position is that the build path is unverified here.
Configuration is likewise undocumented at the key level. The README says provider presets exist to make setup easier and that custom providers are supported, which means somewhere in the app there is a form for a base URL, an API key, and a model identifier. It does not name the config keys, and it does not say whether credentials are stored in DataStore in plaintext or behind Android's keystore. For a BYOK client, that distinction is worth checking in the source before you paste a key for a paid provider.
Backup is the one operational path the README does describe: WebDAV backup lets you sync and back up your data to any WebDAV-compatible server. It does not say whether the backup includes the vector memory store, the assistant configurations, or only the message history, and that scope determines whether a restore actually returns you to a working state.
Where LastChat Is the Wrong Choice: Fork Drift and an Undocumented Sandbox
LastChat is a fork of RikkaHub, and the README closes with a note that the project may contain modifications or features not present in the original. That is a maintenance statement disguised as a disclaimer. A fork that diverges in the UI layer, which this one does by its own description of an overhauled interface, accumulates merge conflicts against upstream. Bug fixes and provider-compatibility patches landing in RikkaHub do not arrive here automatically. If your reason for choosing LastChat over RikkaHub is the RAG memory and the Python engine, you are trading upstream velocity for those features, and the trade should be made deliberately.
The second limitation is the Python engine's unspecified boundary. PRoot gives you a Linux userland without root, which is genuinely useful for running scripts that need a real interpreter and pip-installable packages. It is not a security boundary in the way a container is. The README does not describe resource limits, network policy, or filesystem scope for that environment. Running model-generated Python inside it is a materially different risk posture from running model-generated Python in a hosted sandbox with a documented policy, and the documentation here does not let you assess which one you are getting.
The third is the development model itself. The README states the project was modified using AI agents and credits Claude, Codex, and Antigravity. That is not disqualifying, but it changes what you should expect from commit messages and issue triage. If you need a maintainer who can explain why a retrieval heuristic was chosen, that explanation may not exist in the repository.
RikkaHub vs LastChat: What the Fork Actually Changes
RikkaHub is the upstream project, and LastChat's own description frames the difference as an overhauled UI plus feature additions. That is the honest comparison to make, because everything else in LastChat inherits from RikkaHub: the Kotlin and Compose foundation, the multi-provider client model, and the general shape of the assistant system.
The divergence is concentrated in three areas. First, the interface: LastChat targets Material You 3 Expressive, and its gallery screenshots are versioned separately from the app releases (1.4.3 chat and stats screens, a 1.3.4 providers animation), which suggests the UI is under active revision. Second, the execution features: the PRoot-backed Python engine and the QuickJS JavaScript engine are the additions that turn the app from a chat client into something closer to an agent host. Third, the memory system, which the README presents as a headline capability rather than an inherited one.
The practical difference for a prospective user is upgrade behaviour. RikkaHub is the trunk; LastChat is a branch that has to be rebased by hand. If the features you need are the RAG memory and the embedded runtimes, the fork is the only one of the two that has them. If you mainly want a maintained Android client for multiple providers, upstream is the lower-risk place to be, and the fork's advantages are ones you would not be using.
Licence and the Cost of Keeping a Fork Current
LastChat is AGPL-3.0. The practical consequence for anyone distributing a modified build, including an internal APK handed to colleagues, is that the copyleft terms attach to the whole work and the source has to be made available under the same licence. This is not legal advice, and the specific obligations depend on how you distribute; if you plan to ship a modified LastChat, read the licence text rather than a summary. For individual users installing the app on a personal device, the licence is mostly a fact about the project rather than an obligation on you.
The maintenance cost is the recurring one. Three releases landed between 2026-06-12 and 2026-07-02, roughly a three-week window, which indicates an active cadence rather than a dormant fork. Active is good for feature velocity and bad for stability: a project moving that fast is unlikely to hold a configuration format or a database schema still across minor versions. The README documents WebDAV backup as the migration mechanism, but it does not describe schema migration on upgrade, so the safe assumption is that in-place upgrades are the supported path and that backup is your fallback rather than your primary strategy.
There is also the upstream-rebase cost, which falls on the maintainer rather than the user but shows up as delay. Every RikkaHub release that touches shared code is a potential conflict for this fork. That is the price of the overhauled UI and the added engines, and it is paid continuously, not once.
Who Should Install LastChat, and What to Check First
LastChat fits a specific profile: an Android user who already holds API keys for one or more providers, wants assistant personas they control, and values having the vector memory store on the device. The combination of MCP support, a local Python environment, and RAG memory is unusual for a mobile client, and if you are building small agent workflows that need a real interpreter on a phone, there is not much else in this category to compare against.
It does not fit someone who wants a set-and-forget chat app, or a team that needs a documented API surface, a published roadmap, and a predictable upgrade path. The README is a feature list, not an operator's manual. Build instructions, config key names, the embedding model, the scope of the Python sandbox, and the contents of a WebDAV backup are all absent.
Three things to verify before you commit. Check whether the repository carries the AGPL-3.0 LICENSE file and whether it is intact, since a fork can drift on licensing without meaning to. Read the 1.4.5 release notes against the 1.4.4 notes to see whether changes are described in terms of behaviour or only in terms of version bumps. And confirm in the source whether the RAG memory store is included in the WebDAV backup payload, because if it is not, moving to a new device means losing the memory that motivated choosing this app over RikkaHub in the first place.
Editorial conclusion
Adopt LastChat if you want a local-first Android client with RAG memory, MCP, and a Python sandbox, and you accept that upstream fixes from RikkaHub will not arrive automatically. Do not adopt it if you need a stable API surface, a documented upgrade path, or a project with a published roadmap. Before installing, verify three things in the repository: whether the AGPL-3.0 LICENSE file is present and unmodified, whether the 1.4.5 release notes list the changes made since RikkaHub, and whether the RAG memory store can be exported through WebDAV or only the chat history.
Community notes