ChatterUI: an Android frontend for on-device GGUF models and remote LLM APIs

What problem ChatterUI solves, and for whom

Most LLM chat clients assume a desktop or a browser. ChatterUI takes the opposite position: it is a native mobile frontend, and the phone is the whole runtime. The README describes two modes. In Local Mode the app runs gguf files on the device through llama.cpp; in Remote Mode it connects to commercial and open source APIs. The same interface covers both, so a user can start a conversation against a local model and later point the same character at a hosted endpoint without switching apps.

The intended user is someone who already has a model file or an API key and wants a mobile client with control over chat structure. That control is explicit in the feature list: customizable sampler fields, instruct formatting, the Character Card v2 specification, multiple chats per character, and integration with the device text-to-speech engine. This is not a hosted product with an account system. There is no homepage field in the repository, and the README points users to the releases page for the APK. If you want a managed service, this is the wrong shape of software.

Local Mode: llama.cpp behind a React Native adapter

The mechanism is stated plainly in the README: ChatterUI uses llama.cpp under the hood to run gguf files on device, and a custom adapter named cui-llama.rn integrates it with react-native. The repository layout is consistent with that description. The package.json lists patch scripts for expo-sqlite, expo and expo-file-system, and a postinstall hook that runs patch-package, which tells you the native layer is being adjusted rather than used untouched.

Importing a model offers two paths, and the trade-off is documented. Import Model copies the model file into ChatterUI and may speed up startup. Use External Model reads the file from device storage directly, avoiding the copy of a large file but adding a slight delay in load times. Both paths require the model to fit in the device's memory, which is the hard constraint of on-device inference. The README adds a hardware note: on Snapdragon 8 Gen 1 and above, or Exynos 2200 and above, Q4_0 quantization is recommended for optimized performance. That is a recommendation about quantization format, not a guarantee about any particular model size.

Remote Mode and the custom API template system

Remote Mode covers three groups. Open source backends are koboldcpp, text-generation-webui and Ollama. Dedicated APIs are OpenAI, Claude (with the ability to use a proxy), Cohere, Open Router, Mancer and AI Horde. Generic backends are Generic Text Completions and Generic Chat Completions, which the README says should be compliant with any Text Completion or Chat Completion backend such as Groq or Infermatic.

The interesting part is what happens when a provider is missing. ChatterUI lets users define APIs through a template system, and the README links to a GitHub discussion for the details. That design choice matters: it means provider coverage is not limited to the built-in list, but it also means the burden of describing a new API falls on the user. The README does not document the template fields itself; it defers to the discussion thread. Anyone evaluating the app for an unusual or internal endpoint should read that thread before assuming the integration will be quick.

The Claude entry deserves attention because it names a proxy option. Proxies are usually a workaround for regional or network restrictions, and the fact that it is called out separately suggests the direct path is not always available.

Installing the APK and running a first model

The README gives one installation route: download and install the latest APK from the releases page. There is no Play Store listing described in the README, and no package manager command for end users. The releases listed in the repository are v0.10.0, v0.10.0-beta5 and v0.10.0-beta4, with v0.10.0 dated 2026-09-22.

After installing, the first real task is getting a model onto the device. The README says to enable Local Mode, then go to Models, then choose Import Model or Use External Model, and pick a gguf model that fits the device's memory. The two options behave differently:

Import Model: copies the model file into ChatterUI, potentially speeding up startup time.
Use External Model: uses a model from device storage directly, removing the need to copy
large files into ChatterUI but with a slight delay in load times.

Once the file is in place, the README says to load the model and begin chatting. There is no step in the README that describes downloading a model from inside the app, so the file has to come from somewhere else first.

For developers who want to build rather than install, the README requires a Java 17 or 21 SDK and an Android SDK installed via Android Studio, then cloning the repository and running the Expo commands:

git clone https://github.com/Vali-98/ChatterUI.git
npm install
npx expo run:android

Building an APK yourself requires Node.js, a Java 17 or 21 SDK and the Android SDK. The README notes that Expo uses EAS, which requires a Linux environment. The steps are to clone the repo, rename eas.json.example to eas.json, modify ANDROID_SDK_ROOT to the directory of your Android SDK, and then run:

npm install
eas build --platform android --local

The package.json shows a version field of 0.8.8 while the latest release is v0.10.0, so the manifest version and the release tag are not kept in lockstep. Do not read the package.json version as the shipped version.

Where ChatterUI is the wrong tool

The clearest limitation is platform. The README states that iOS is currently unavailable due to lacking iOS hardware for development, and the development section lists iOS as currently in development. If your team is on iPhones, this project does not serve you today, regardless of how the rest of the feature set looks.

On-device inference has a second, harder boundary. A gguf model must fit on the device's memory, and the app does not change that arithmetic. Large models that run comfortably on a laptop will not load on a phone. The README's quantization note points in the same direction: Q4_0 is recommended for newer Snapdragon and Exynos chips, which implies that higher-precision or larger files are a performance problem rather than a supported default.

There is also a structural cost to the native approach. The package.json runs patch-package after install and carries dedicated patch scripts for expo, expo-sqlite and expo-file-system. Patching upstream packages is a normal technique, but it means upgrades of Expo or those modules can conflict with the patches, and the maintainer has to re-apply them. Anyone forking the project inherits that maintenance work.

Finally, the AGPL-3.0 licence is a real constraint for some adopters. If you modify ChatterUI and let users interact with it over a network, the licence's network clause is the part to read carefully. This is not legal advice, but it is a reason some commercial teams will rule the project out before evaluating features.

How ChatterUI differs from PocketPal and similar mobile clients

PocketPal is the comparison users search for, and the difference is in scope rather than polish. PocketPal is oriented around running models locally on the phone. ChatterUI keeps local inference as one of two modes and puts equal weight on remote providers: the README lists koboldcpp, text-generation-webui, Ollama, OpenAI, Claude, Cohere, Open Router, Mancer, AI Horde, and generic Text and Chat Completion backends, plus a template system for anything else. If your workflow is a local gguf only, that breadth is unused surface. If your workflow mixes a local model with a hosted endpoint, or you need to reach an internal completion server, the remote side is the reason to pick ChatterUI over a local-only client.

The character layer is the second difference. ChatterUI supports the Character Card v2 specification, manages multiple chats per character, and includes a separate user profile editor, which the README's screenshots label Personalize Yourself. A client that only stores a system prompt and a message list does not give you that structure. Whether the extra structure is useful depends on whether you actually share or import character cards; if you do not, it is configuration you will scroll past.

Maintenance, upgrades and licence obligations

The repository is not archived, and the last push was on 2026-09-22, the same day as the v0.10.0 release. Two betas preceded it in the same cycle, v0.10.0-beta4 on 2026-08-19 and v0.10.0-beta5 on 2026-08-28, so the release cadence in this window includes pre-release builds before the stable tag. For an app distributed as an APK rather than through a store, upgrading means downloading a new APK from the releases page. The README does not document an in-app update mechanism or a rollback path, so a user who installs a bad build has to find an older release themselves.

For contributors, the upgrade cost is concentrated in the native layer. The patch scripts in package.json target expo, expo-sqlite and expo-file-system, and the postinstall hook applies them automatically. Any bump of those dependencies has to be checked against the patches. The lint and test scripts exist (eslint over app, db and lib, and jest with the jest-expo preset), but the README does not describe a CI pipeline that gates releases.

The licence is AGPL-3.0, which the repository states in its LICENSE file. AGPL-3.0 requires that modified versions offered to users over a network make their source available. That is a stronger obligation than permissive licences, and it applies to the app itself. Teams planning to embed ChatterUI in a product should have someone read the licence rather than assume it behaves like MIT.

Editorial conclusion

Adopt ChatterUI if you want a single Android app that can both load a GGUF model locally and switch to a remote provider without changing tools, and if you accept a Character Card v2 character model and AGPL-3.0 terms. Do not adopt it if you need iOS, a web interface, or a server-side deployment; the README states iOS is unavailable because the developer lacks iOS hardware, and the web script is only an Expo development target. Before committing, verify three things: whether the gguf you intend to use fits your device's memory, whether your provider is covered by the built-in list or needs a custom API template, and whether AGPL-3.0 obligations are compatible with how you plan to distribute anything built on the code.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. README
4. Releases
5. Vali-98/ChatterUI on GitHub