LastChat: a RikkaHub fork with a rebuilt Android UI and RAG memory

What LastChat solves, and for whom

Hosted chat apps keep the conversation and the model choice on the vendor's side. LastChat takes the opposite position. It is an Android application that talks to AI providers you configure yourself, and the README states that chat history and vector memory are stored locally on your device. The topics list on the repository includes byok, meaning bring your own key, so the intended user already has an API key or a self-hosted endpoint rather than a subscription.

The second audience is narrower: people who want a personal assistant with a persistent memory of past conversations. The README describes a RAG-based memory system where assistants "remember" details from past conversations using embeddings. That is a different promise from a long context window. It means the app stores embedded fragments and retrieves relevant ones later, which is why the same README lists retrieval-augmented-generation among the project's topics.

It is a fork of RikkaHub, and the README says so twice, including a closing note that the fork "may contain modifications or features not present in the original RikkaHub repository." That sentence is the honest framing of the whole project: the feature list is a delta, and you cannot assume parity with the upstream app in either direction.

The architecture visible in the repository

LastChat is Kotlin and Jetpack Compose, and the README names the supporting stack: Koin for dependency injection, Room and DataStore for persistence, WorkManager and AlarmManager for background tasks, and QuickJS for JavaScript. The top-level directory listing backs this up with separate modules for the pieces you would expect from that description: app, shared, ui-core, i18n, highlight, search, speech, tts, local-llm, workspace and web-ui.

Data flow follows the local-first claim. Provider configuration, chat history and vector memory live in Room and DataStore on the device; the network call goes from the app to whichever provider you configured. There is no account layer described in the README, and no server component in the repository listing. The only sync path named is WebDAV, which the README describes as syncing and backing up data to any WebDAV-compatible server. That is a backup target, not a hosted backend.

The execution features are the unusual part. The README describes a built-in Python engine powered by Workspaces and PRoot-based Linux environments, and a built-in JavaScript engine on QuickJS. The workspace directory in the repository listing is consistent with the first. Both engines run on the device, which is what makes them possible in an app with no server, and also what limits them.

Installing LastChat and configuring a first provider

The README does not contain installation instructions. It shows the app, lists features, names the libraries and credits the upstream project, and stops there. There is no download link, no F-Droid or Play listing, and no build command. The releases page is the place to look: the most recent release listed is LastChat 1.4.5 from 2026-07-02, preceded by 1.4.4 and 1.4.3. Fetch the artifact from there rather than trusting a mirror.

If you prefer to build it yourself, the repository is a Gradle project with a Kotlin DSL build script and a checked-in wrapper. The repository listing shows gradlew and gradlew.bat at the top level alongside settings.gradle.kts and build.gradle.kts. The README does not state which JDK or Android SDK version the build expects, and it does not give a build command, so treat a failing build as an environment problem before assuming a source problem.

Once the app is running, the first real task is adding a provider. The README says provider presets make it easier to get up and running, and that custom providers are supported too. The providers page is shown in the gallery as docs/1.3.4_providers_use.gif, which is the only documentation of that screen. The workflow implied by the README is: open the providers screen, pick a preset or define a custom endpoint, and enter the credential for that provider. The README does not document the individual fields, so the screen itself is the reference.

After a provider is configured, create an assistant. The README describes unlimited custom assistants with a tagging system and import/export of assistant configurations. Import/export matters here: it is the only documented way to move a persona between installs without going through WebDAV.

Where the local-first design costs you

Local storage is the selling point and the constraint. Chat history and vector memory sit on one device. WebDAV can back that up, but the README does not describe conflict resolution or multi-device merge behavior, so syncing the same data from two phones is an open question rather than a documented feature. Treat WebDAV as backup first.

The embedded engines are the other trade-off. A PRoot-based Linux environment and a QuickJS runtime inside an Android app are heavier than calling a remote code execution API, and the README gives no memory, storage or battery figures for either. On a low-end device, enabling both alongside local embeddings for memory is the configuration most likely to cause trouble, and nothing in the documentation tells you where the ceiling is.

The fork relationship is a real consideration too. The README explicitly warns that this project may contain modifications not present in RikkaHub. That cuts both ways: features arrive here that upstream lacks, and upstream fixes may not reach this tree. If you need the original's behavior, the original is a click away in the credits section.

Finally, the README does not document rollback. There is no statement about database migrations between releases, so if you install 1.4.5 and later want to return to 1.4.3, the documentation is silent on whether your stored data survives.

How LastChat differs from RikkaHub and from Kelivo

The honest alternative is the project LastChat forked. RikkaHub is the upstream Android client, and the README's closing note is the entire documented difference: this fork may carry changes the original does not. What the README does establish is that the UI was overhauled, that the app is designed around Material You 3 Expressive, and that the project was modified using AI agents. If you want the smaller, upstream surface area and do not need the added modules, RikkaHub is the conservative choice; if you want the Python and JavaScript engines plus the memory module as described here, the fork is the one that lists them.

Kelivo appears in the related searches people run around this project, and it is worth being precise about what can and cannot be said. The README does not mention Kelivo, so nothing about that project's architecture or feature set can be asserted from this material. The only defensible statement is that both names come up in the same searches, which tells you they occupy the same mental slot for Android users choosing an AI client, not that they work the same way.

A third comparison is the hosted assistant app on your phone. Those win on setup: no provider configuration, no key management, no build. LastChat wins on control: your key, your endpoint, your stored history. The choice is between convenience and custody, and the README is clear about which side it takes.

Maintenance, licence and what a fork costs you

The repository is not archived, and the last push was on 2026-09-05. Releases are frequent rather than annual: 1.4.3 on 2026-06-12, 1.4.4 on 2026-06-30, and 1.4.5 on 2026-07-02. That cadence matters for a client that talks to third-party APIs, because provider endpoints and model names change without warning, and a client that is not updated stops working through no fault of its own.

Upgrade cost is where the documentation is thinnest. The README describes import and export for assistant configurations and WebDAV for backup, but says nothing about database schema changes between 1.4.3 and 1.4.5. For a fork maintained in bursts, that is the risk to price in: back up before upgrading, and keep the previous release artifact so you can go back.

The licence is AGPL-3.0, which is stated in the repository and is the same family of licence used by many self-hosted projects. The practical implication, without giving legal advice, is that the copyleft applies to the application and to modified versions you distribute, not to the API keys you paste into it or the conversations you store. If you plan to ship a modified LastChat build, read the LICENSE file in the repository and get proper advice; if you are an individual installing an APK, the licence mostly affects the people who redistribute it.

The AI-agent provenance is worth noting for a different reason. The README credits Claude, Codex and Antigravity, and the repository carries configuration directories for those tools. That is a development-style disclosure, not a quality signal in either direction, but it does explain why the feature list reads as long and the build documentation reads as short.

Editorial conclusion

Adopt LastChat if you are on Android, want to bring your own API keys, and care that chat history and vector memory stay on the device rather than in someone else's account. Skip it if you need an iOS client today: the repository carries an iosApp directory, but the README describes an Android application only. Before installing, check the releases page for a 1.4.5 artifact matching your device, and read the LICENSE file in the repository to see what AGPL-3.0 asks of anyone who redistributes a modified build.

Frequently asked questions

Official sources

1. Cocolalilal/LastChat on GitHub
2. Issues
3. License: AGPL-3.0
4. README
5. Releases