GPT Mobile: A Multi-Provider Android Client That Keeps Your API Keys Local
Chat app for Android that supports answers from multiple LLMs at once. Bring your own API key AI client. Supports OpenAI, Anthropic, Google, and Ollama. Designed with Material3 & Compose.
At a glance
- What is it?
- Taewan-P/gpt_mobile is a Kotlin and Jetpack Compose Android chat app that queries OpenAI, Anthropic, Google, Groq, and Ollama from one screen, with optional per-profile agent tools. It is a bring-your-own-key client, not a hosted service, and its GPL-3.0 licence shapes what you can do with a fork.
- Who is it for?
- Adopt GPT Mobile if you already pay for one or more provider API keys, want them stored under Android Keystore rather than in a vendor account, and use Android 13 or later. Skip it if you need a web client, iOS, or a shared workspace with server-side history, since the README is explicit that chat history is only saved locally.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 1 day 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: one question, five browser tabs
Comparing model answers normally means keeping several provider dashboards open and pasting the same prompt into each. GPT Mobile collapses that into a single Android chat screen. The README lists OpenAI GPT, Anthropic Claude, Google Gemini, Groq, and Ollama as supported platforms, and the feature list says the app uses the official API for each one rather than scraping a web interface. That distinction matters: official endpoints mean your key is the only credential involved, and there is no intermediary server relaying prompts. The intended user is someone who already holds API keys and wants a native client on a phone or tablet. It is not a free tier, and it is not a proxy that hides billing from you. Every message you send is billed by whichever provider you selected, at that provider's rates. The repository topics include ollama-app and ollama-api, which points at a second audience: people running models on their own hardware who want a mobile front end that can reach a local endpoint. The custom API URL and custom model fields in the README exist for exactly that case, since a self-hosted Ollama instance rarely sits at a public address.
How a prompt reaches several providers at once
The architecture is a single-activity Jetpack Compose app written entirely in Kotlin. The README describes it as following the Modern App Architecture guidance in the Android developer documentation, which in practice means the UI layer observes state and the network calls live below it. Each provider is a profile. A profile carries a system prompt, a temperature value, and a top p (nucleus sampling) value, all of which the README says are customizable. When you send one message, the app fans it out to every selected profile, so a single turn can produce a GPT answer, a Claude answer, and a Gemini answer side by side. That fan-out is the feature the project is built around. It also defines the cost model: three profiles selected means three billed requests per turn. Agent tools sit on top of this and are assigned per provider profile, not globally. The README states that native tool calling works with OpenAI, OpenAI-compatible and Groq endpoints, Anthropic, and Gemini, and that existing and newly migrated profiles remain chat-only until tools are assigned. That default is the right one. Adding a tool changes what leaves your device, so it should be an explicit action rather than something a migration switches on for you.
Where your keys and your chat history actually live
This is the part worth reading closely. The README states that chat history is only saved locally, and that credentials are encrypted with Android Keystore and excluded from backup and export. Those two sentences are the strongest claims in the repository, and they are also the ones a prospective user should verify against the source, because the app depends on them entirely. The README also draws a boundary around network traffic: during chats, requests go only to selected model providers and assigned tools. The exception is spelled out in the same paragraph. Opening a profile's Tools dialog may contact every saved MCP server for discovery, and that contact may include the server's bearer or OAuth credential. So the privacy surface is not the chat itself but the configuration screen. A user who saves five MCP servers and opens the Tools dialog for one profile can cause the app to reach all five. That is a design decision rather than a bug, and the README documents it, but it is easy to miss. MCP support is described as Streamable HTTP with public, bearer, or OAuth authentication.
Installing it and wiring up a first profile
The README points at three distribution channels: F-Droid under the package name dev.chungjungsoo.gptmobile, Google Play under the same identifier, and GitHub Releases. It states that cross-platform updates are supported but that GitHub Releases is the fastest track because there is no verification or auditing process, with a difference of roughly one week. There is no build-from-source section in the material supplied, so this review cannot give you a Gradle command that is confirmed to work. What can be stated is the repository layout: the primary language is Kotlin, the default branch is main, and a release-build workflow exists, since the README embeds a GitHub Actions status badge for release-build.yml. Configuration happens inside the app rather than in a file. You add a provider profile, choose the platform, paste the API key, and optionally override the API URL and model name for a custom or self-hosted endpoint. The system prompt, temperature, and top p live on the same profile. Tools are assigned afterwards. The README directs readers to docs/agent-tools.md and docs/release-notes-v0.8.0.md for the agent side, which is where the MCP and web search details are documented. Those two files are the ones to read before enabling anything beyond plain chat.
The agent layer, and why it is opt-in per profile
Version 0.8.0 introduced the agent tools, and 0.9.0 followed about three weeks later. The README lists what those tools include: Firecrawl, Perplexity, or Exa for web search and what it calls hardened URL reading, plus MCP Streamable HTTP servers. It also mentions parallel runs, persistent traces, cancellation, and foreground progress. Persistent traces are worth pausing on. A trace is a record of what the agent did, and if it persists, it is stored somewhere on the device. The README does not say in the supplied material whether traces are covered by the same local-only and backup-exclusion rules as chat history. That is a gap, not a contradiction, and it is the kind of thing to confirm in docs/agent-tools.md before enabling tools on a device you share. Cancellation and foreground progress suggest the author expects long-running tool calls, which is a reasonable assumption when a model can chain a search into a page fetch. The per-profile assignment model keeps this contained: a profile without tools behaves like the earlier chat-only versions, and the README says migrated profiles stay that way until you change them.
What the app does not do
There is no web client and no iOS build in the material. The platform badge says Android, the language is Kotlin, and the UI is Compose with Material You, so the scope is Android phones and tablets. Android 13 or later gets the per-app language setting the README mentions, which implies older versions lose that particular feature. Chat history being local-only is a privacy feature and a limitation at the same time. There is no sync between devices, and there is no shared workspace where a colleague can pick up a thread. If your team needs a searchable archive of prompts and answers across devices, this app is the wrong shape for that, and no amount of configuration will change it. The multi-provider fan-out is also a cost multiplier rather than a cost saver. Selecting four profiles for a long conversation means four times the token spend, and the app does not appear to offer a way to compare answers without paying for all of them, based on the feature list. Finally, the GPL-3.0 licence is a real constraint on redistribution. If you fork the app, modify it, and ship the binary, the licence terms apply to what you distribute. That is a summary of the licence identifier, not legal advice; read LICENSE in the repository and talk to a lawyer if the distinction matters for your plans.
How it differs from a hosted multi-model chat service
A hosted aggregator such as a web-based multi-model chat product keeps your conversation on its servers and bills you through its own account. GPT Mobile inverts that. Your keys stay on the device under Android Keystore, your history stays in local storage, and requests go from the phone to the provider. The trade is operational: you manage the keys, you watch the spend at each provider, and you lose anything that depends on server-side storage, including cross-device history and team sharing. The other comparison point is a single-provider official app, for example the OpenAI or Anthropic mobile client. Those are simpler and usually better maintained, but they only talk to one vendor, so the comparison workflow that motivates this project is not available in them. Against a self-hosted web UI like a local chat front end, the difference is the platform: those run in a browser and typically assume a server you control, while this is a native Android app that can point at a local Ollama endpoint through the custom API URL field. The README's custom model and custom URL support is what makes that last case work.
Maintenance, releases, and what to check before you commit
The release cadence visible in the material is roughly monthly: v0.7.6 in June, v0.8.0 in August, v0.9.0 in September. The last push to the default branch is dated the day after the 0.9.0 tag, so the project is active rather than dormant, and the repository is not archived. Translations run through Hosted Weblate, and the README invites contributions while noting that a contribution guideline does not exist yet. That last point is a mild warning for anyone planning to send patches: without a stated process, review expectations are undefined. Upgrade cost is low if you install from F-Droid or Play, since the store handles it. It is higher if you track GitHub Releases for the roughly one-week head start, because you are then installing an unaudited build yourself. The licence implication is the one to settle early: GPL-3.0 governs redistribution of modified builds, so an internal fork that stays inside your organisation and a public fork that ships binaries are different situations. Before adopting, verify three things against the source: that Keystore encryption covers the credential storage path you care about, that agent traces fall under the same local-only rule as chat history, and that the Tools dialog really does contact every saved MCP server, since that is the one behaviour in the README most likely to surprise a user mid-setup.
Editorial conclusion
Adopt GPT Mobile if you already pay for one or more provider API keys, want them stored under Android Keystore rather than in a vendor account, and use Android 13 or later. Skip it if you need a web client, iOS, or a shared workspace with server-side history, since the README is explicit that chat history is only saved locally. Before installing, read docs/agent-tools.md and confirm the Tools dialog behaviour: opening it may contact every saved MCP server and send its bearer or OAuth credential. Then check the F-Droid build for the version you intend to run, because the README states GitHub Releases ships roughly a week ahead of the audited tracks.
Community notes