5.0 KiB
title, source, author, published, created, description, tags
| title | source | author | published | created | description | tags | ||
|---|---|---|---|---|---|---|---|---|
| You should host OpenClaw on an old Android Phone | https://x.com/itsPaulAi/status/2028213201519640823 |
|
2026-02-23 | 2026-03-02 | I'm one of those people who like movies 📽️ and sports 🏏 |
|
You don't need a Mac Mini to run your AI agent.
I got PicoClaw (a lighter alternative to OpenClaw) running on an old Android phone, inside Termux, and it was surprisingly straightforward:
Not "easy" in the polished YouTube-demo sense. More like: annoying for an hour, then solid.
- Way cheaper than a Mac Mini
- Always available through Telegram
- Surprisingly faster than OpenClaw
2月23日
No. You don't need a Mac Mini for OpenClaw. You can actually host everything you need on an old Android phone. And you'll have a setup which is: - Much faster - Way cheaper - With the same features Even a $25 phone can do the job.
Here’s the setup that actually worked.
Start with Termux, not shortcuts
Make sure to install the Termux app either from F-Droid or using the apk from the official GitHub repo.
First, give Termux storage access and install the boring stuff:
termux-setup-storage
pkg update && pkg upgrade -y
pkg install -y wget proot ca-certificates openssl nano jq
That `ca-certificates` line matters more than people think. If you skip it, you can end up with the classic TLS error where the agent can’t verify the API certificate and everything looks broken even though your key is fine.
Then check your phone architecture:
uname -m
If it says `aarch64`, you want the ARM64 PicoClaw binary. That’s most Android phones.
Put the binary somewhere sane
Keep the real binary in your home directory, not on shared storage.
Android loves making `/sdcard` feel convenient right up until it blocks execution.
I used a simple layout like this:
mkdir -p ~/bin && cd ~/bin
wget -O picoclaw https://github.com/sipeed/picoclaw/releases/download/v0.2.0/picoclaw-linux-arm64
chmod +x picoclaw
Then initialize PicoClaw:
termux-chroot ~/picoclaw-linux-arm64 onboard
That creates the config and workspace so you’re not editing random files that don’t exist yet.
The one change that actually matters: use MiniMax M2.5 through OpenRouter
This is where a lot of people stay on Claude Opus which is waaay more expensive.
The clean way to do it is to point PicoClaw at OpenRouter, then choose MiniMax M2.5 there.
Open `~/.picoclaw/config.json` and use this as the core model setup:
nano ~/.picoclaw/config.json
{
"agents": {
"defaults": {
"model": "minimax/minimax-m2.5"
}
},
"providers": {
"openrouter": {
"api_key": "sk-or-v1-..."
}
}
}
That’s the piece most people miss.
Not because it’s complicated.
Because old examples floating around still steer people into legacy provider configs, and then they wonder why the agent keeps calling the wrong backend.
If you specifically want MiniMax M2.5, this is the switch.
Fix the TLS problem once, not every time
If you ever saw the certificate error, do not keep pasting one-off environment variables forever.
Wrap it properly.
Create a small launcher script:
mkdir -p ~/bin
cat > ~/bin/picoclaw <<'EOF'
#!/data/data/com.termux/files/usr/bin/sh
export SSL_CERT_FILE=/etc/tls/cert.pem
export REQUESTS_CA_BUNDLE=/etc/tls/cert.pem
exec termux-chroot "$HOME/picoclaw-linux-arm64" "$@"
EOF
chmod +x ~/bin/picoclaw
Then make sure `~/bin` is on your PATH:
echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
That was the other tiny thing that tripped me up. The script existed. The shell just couldn’t see it.
Once that’s done, you can use PicoClaw like a normal command:
picoclaw agent -m "Hello there!"
And yes, it feels much better when the fix is permanent.
Test the agent before you get fancy
Before trying to make it "always on," just make sure the core loop works:
picoclaw agent -m "Write a tiny hello-world in Python and explain it."
If you want chat access all the time, run the gateway
Once the agent works, the next step is the gateway:
picoclaw gateway
I’d test it manually first. Always.
There’s no point trying to daemonize a broken setup. Get one clean session working, confirm it stays up, then automate it.
That order saves a lot of frustration.
What surprised me most
The weirdest part of this whole thing is how normal it feels once it’s running.
An old Android phone. A terminal app. A lightweight agent binary. One decent model choice.
That’s it.
No glossy setup. No expensive box humming on a desk. No overbuilt stack just to prove you’re "serious."
Just a phone doing real work.
And honestly, I think that’s the part people are still underestimating.
The gap between "AI demo" and "useful personal agent" is getting smaller fast.
Sometimes it’s small enough to fit in your pocket!