Fair point. You do still need one agent, since it’s what talks to the model. For local I’d use OpenCode (free, no account); Codex works too. Set Default brain to OpenCode in Settings, install it, and pick your llama.cpp model in a chat. No need for Claude Code, that step only shows because it’s the default agent. Thanks for trying it 🙂
It’s not in the first-run setup, it’s in Settings → API keys → Add API key. Pick Ollama, LM Studio or llama.cpp from the Service menu (or Custom for any other OpenAI-compatible address), put in your server’s address and leave the key empty. Then use it in an OpenCode chat. The 2.3.1 on F-Droid has it. More here: https://github.com/ghorbelhamdi/buddy-android#local-models
@Shatur@discuss.tchncs.de as promised: Buddy is on F-Droid now 🙂 https://f-droid.org/packages/app.buddy.assistant/ It’s at 2.3.1 there for now, newer versions follow as F-Droid builds them.
English isn’t my first language so I use AI to clean up my writing. It just rephrases my ideas, the meaning stays the same, and the 3 points I posted are from my own experience.
Voice Access works, but saying “scroll down” forty times gets old fast. With Buddy you just say what you want done. And it still asks before sending, paying or deleting.
Good call. Qwen3.6 35B-A3B runs fine split between my 8 GB card and RAM, and gets the task right. Flash Next is too big for 32 GB. The latest Buddy (2.2.27) also fixes local models with Codex, which your suggestion helped me find.
Update: you were right. Qwen3.8 27B (unsloth UD-IQ3_XXS) did the calculator task correctly (1234×5678 = 7,006,652), but took 18 minutes on my 8 GB card, almost all of it reading the prompt and screen on the CPU.
Qwen3.5 9B is the interesting one: one run typed the wrong numbers and claimed success, the next did it right in about 2 minutes. So small models can do it, just not reliably yet.
It doesn’t match the model’s text. The check runs in the accessibility service on the actual button the tap would land on: its label, icon description and view id, as the app reports them. The model can write D E L E T E all it wants, the button still says Delete. It also can’t tap Buddy’s own approval card to approve itself.
Where it can miss: a button with an odd or blank label, and apps you mark as trusted, where asking is left to the agent. And agreed, it’s one guard, not the whole risk picture. Prompt injection from what’s on screen is the bigger open problem, and the approval card is the backstop there.
I did appeal. Google’s answer, word for word: “the app utilizes the accessibility API for performing autonomous actions… The accessibility API is not designed and cannot be requested for performing autonomous tasks.” So the problem was the agent acting on its own, not which AI services it uses.
The accessibility-tool exception is only for apps built mainly for people with disabilities. Buddy can help there, but it does a lot more, so claiming that wouldn’t be honest. If anyone has gotten an agent app like this through review, I’m open to trying again.
Curious too. In my tests Qwen3 4B and 8B handled one-step requests but fumbled multi-step ones (tapped the wrong buttons, then said it worked). gpt-oss 20B did better but was inconsistent: one run got a 2-step task right, the next claimed a tool didn’t exist. I haven’t tried a 27B yet, and I don’t know if it’ll even run usably on my RTX 2060 Super (8 GB). If anyone runs one through Ollama or llama.cpp, I’d love to hear how it does.
I’m not your friend, pal 😄
Fair to be skeptical, but it isn’t the model being asked nicely. Buddy checks every tap itself: when the button is Send, Post, Buy, Pay, Delete and similar (by its label or id, in several languages), Buddy stops and shows an approval card, whatever the model wants. It’s a word list, so an oddly named button can slip through; it’s all in Guard.java if you want to look: https://github.com/ghorbelhamdi/buddy-android/blob/main/app/src/main/java/app/buddy/assistant/Guard.java
It can now: since 2.2.25 it works with your own model server (Ollama, LM Studio or llama.cpp) on your network or over Tailscale, with no key, and nothing goes to an AI company. Honest caveat: small models (4–8B) handle simple requests but fumble multi-step tasks on the screen, so you’d want a bigger model for real use.
Done: 2.2.25 makes this easy. Ollama, LM Studio and llama.cpp are in the service list, plain http works on your own network and over Tailscale, and no key is needed. README has a section now: https://github.com/ghorbelhamdi/buddy-android#local-models
Honest results so far, on a PC with an RTX 2060 Super: Qwen3 8B and 4B handle simple one-step requests (battery, phone status), but multi-step tasks on the screen failed. The 4B tapped the wrong buttons in the calculator and then claimed it worked. So for real tasks you’ll want a bigger model; I’m trying gpt-oss 20B next.
Update: it’s now submitted to F-Droid, with reproducible builds, so the F-Droid and GitHub versions will be the same app signed with the same key, and you can switch between them: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/56198
One: someone who can’t see the screen can just talk to it, with live voice, and it does the tapping and reads things back. For a lot of people, that’s the difference between using a phone app themselves and needing someone to do it for them.
It’s just an MCP server for the phone with an app to control it, basically computer use, but for Android. Agents using computers are already normal, so I’m not sure why phones would be different. And it runs on your own plan, or on local models if you’d rather keep it off the cloud entirely.
Fair question, so here are real ones:
It asks before anything is sent or bought and stops when you touch the screen. Not for everyone, and that’s fine.
Thanks, and thanks for the crosspost! Local models already work: in Settings you can add a custom OpenAI-compatible address (llama.cpp, Ollama or LM Studio on your network) and use it with OpenCode. It works best with models that are good at tool calling, since everything goes through phone tools.
Other devices: it’s built for phones, but someone already forked it to run on a Nintendo Switch with Android, with Joy-Con navigation: https://github.com/Lendss/buddy-switch. So other Android devices are clearly possible, I just haven’t tested watches, TVs or XR myself.
F-Droid: good timing. Buddy now builds all its native parts (proot, talloc and friends) from source in CI, with no prebuilt binaries in the repo, which was the main thing in the way. So an F-Droid build should be doable now. Until then, releases are on GitHub and the app updates itself.
You were right, so 2.3.7 has it: the setup guide now offers “Local model” from the start. It sets up OpenCode, asks for your llama.cpp / Ollama / LM Studio address and makes that the default. It’s on GitHub now, F-Droid follows in a few days.