Raspberry Pi OS is Debian on 64-bit Arm, so the user, the venv, the systemd service and the timer work as on Debian. What differs is hardware: a Pi 5 wants a 5A supply to power a USB drive, an SD card wears out under constant logging, setup is headless through the Imager, and a small model runs at about ten tokens a second.
Part of the Always-on agents series, post 24 of 33.
I should say up front that my own always-on jobs run on a Mac, and that I have never had a Pi on my desk. I wrote this guide anyway because a Pi is the answer to a question I get constantly: what is the cheapest machine that can stay on and run a small agent? So I did what I could do honestly. The service steps I ran in a fresh 64-bit Arm Debian 13 container on my Mac, which is the same operating system family and processor family as a Pi 5. The hardware facts come from Raspberry Pi's own documentation and launch notes, linked at the end, and I say which is which.
What a Pi changes, and what it does not
Raspberry Pi OS is Debian, built for Arm. The 64-bit image is the one to use for anything involving a language model. That means the whole of the Debian guide applies: apt, backports if you need a newer Python, a dedicated user, a venv, a systemd service with a restart policy, a timer with Persistent=true. I will not repeat any of it. The core steps are the same ten on every Linux in this series.
What is different is the physics. A Pi is a small board with an SD card, a USB-C power input and no fan unless you add one. Each of those changes how I would run an agent on it.
Headless setup: the Imager does the work
You will not plug a monitor into the box that runs your agent, so set it up headless from the start. Raspberry Pi Imager has a Customisation tab that writes the first-boot configuration into the image. In the documentation's own option names: Hostname (letters, numbers and hyphens; the Pi announces it over mDNS), User (a lowercase username and a password, used for the network login and for sudo), Wi-Fi (SSID and password, and Hidden SSID if yours does not broadcast), and Remote Access, where you turn on Enable SSH and choose Use public key authentication. I would pick the key option every time. An always-on box with password SSH on it is a box you will regret.
After first boot the Pi is reachable at the hostname you chose with .local on the end. From there it is a Debian machine on your network and the rest of this series takes over.
Terminal, from your laptopssh agentbox.local
# then, on the Pi:
sudo apt update && sudo apt full-upgrade -y
sudo rebootPower: buy the 5A supply
This is the one that catches people. Raspberry Pi's launch notes for the Pi 5 say that with a standard 3A (15W) USB-C adapter the board must limit downstream USB current to 600mA, and that the official 5V 5A adapter raises that USB limit to 1.6A and adds headroom for peak loads. The board's own peak draw is described as around 12W, against 8W for a Pi 4. So if your agent's storage is a USB SSD, or you hang anything else off the ports, the 3A phone charger you had in a drawer will give you an SSD that drops out under load and an agent that fails in a way no log explains. With a 3A supply, USB boot is even disabled by default; the documentation describes a usb_max_current_enable=1 line in /boot/firmware/config.txt that overrides the limit, and a PSU_MAX_CURRENT setting that tells the firmware what supply it has. I would not override; I would buy the supply.
Cooling is the other half. The launch notes offer a $5 Active Cooler for continuous heavy load without throttling, and the people who benchmark models on a Pi 5 report that without it the chip throttles within a minute or two of sustained inference and speed roughly halves. An agent that runs a model hourly for thirty seconds will be fine. One that summarises all day will not.
Storage: the SD card is the part that dies
An always-on agent writes a log line every run, and a journal, and its own state. On an SD card that is a slow way to kill the card. Two fixes, in the order I would try them.
- Move the logs into RAM with log2ram. It mounts
/var/logas a RAM folder and syncs it to the card once a day and on shutdown, so the card sees one write a day instead of thousands. The project is MIT-licensed, installs from an apt repository, and has a Debian 13 note in its README about pinning its own package. SetSystemMaxUse=20Min journald.conf first so the journal fits in the RAM folder. - Boot from an SSD instead. A USB SSD works like an SD card: flash the image to it and plug it in with no card inserted. On a Pi 5 an NVMe drive on the M.2 HAT+ is faster still; the documentation sets the boot order with
raspi-config, Advanced Options, Boot Order. Either way, see the power section first.
Terminal, on the Pi (from the log2ram README). /etc/os-release
sudo wget -O /usr/share/keyrings/azlux-archive-keyring.gpg https://azlux.fr/repo.gpg
sudo tee /etc/apt/sources.list.d/azlux.list >/dev/null <<EOF
deb [signed-by=/usr/share/keyrings/azlux-archive-keyring.gpg] http://packages.azlux.fr/debian/ $VERSION_CODENAME main
EOF
sudo apt update && sudo apt install log2ram
sudo reboot
# afterwards
systemctl status log2ram
df -hT | grep log2ramWhich models a Pi can run, and for what
Here I am relying on other people's measurements, because I have no Pi to measure. The most careful set I found is a research write-up from the Stratosphere lab, which ran Ollama on a Pi 5 and measured qwen2.5:1.5b at 9.97 tokens a second, qwen2.5:3b at 5.2 and llama3.2:3b at 4.69, all at the 4-bit quantisation Ollama ships by default. Other 2026 guides land in the same range: ten or so for a 1.5B model, four to six for a 3B one, with a 16GB board and active cooling at the top of the range.
What that means for an agent is the point. Ten tokens a second is plenty for the jobs I actually give small models: sort a message into a label, write three lines about what changed in a feed, decide whether something needs a human. It is not enough, and the models are not capable enough, for a full tool-calling loop; I measure that gap in the local models post. So the Pi agents I would build are the listening kind: the watch agent, a morning brief, a heartbeat. If you want an agent that takes actions through tools, the Pi is the wrong box, and a hosted model with the Pi as the always-on scheduler is the honest compromise.
| Model | Pi 5, tokens per second (Stratosphere, Q4) | Good for |
|---|---|---|
| qwen2.5:1.5b | 9.97 | Labels, short summaries, yes or no decisions |
| qwen2.5:3b | 5.2 | Three-line summaries, slower |
| llama3.2:3b | 4.69 | Same, with a different failure style |
| anything 7B or larger | not practical | Use a hosted model, keep the Pi as the clock |
What I tested, exactly
This Mac is arm64, so a debian:13 container on it is a 64-bit Arm Debian, the same family as Raspberry Pi OS. I booted one with systemd on 20 October 2026 and ran the ten core steps in it: dedicated user, venv, a heartbeat agent, secrets in a file only that user can read, a service with a restart policy and memory cap, a timer with catch-up, a kill and an automatic restart. The output below is from that run. What it does not test is anything a container cannot: the power supply, the SD card, the Imager, cooling. Those sections rest on the documentation.
Fresh arm64 Debian 13 container with systemd, 20 October 2026## arch and os
aarch64
Debian GNU/Linux 13 (trixie)
Python 3.13.5
## 1 dedicated user
uid=996(agent) gid=996(agent) groups=996(agent)
## 2 runtime in a venv
Python 3.13.5
## 3 a tiny agent that writes a heartbeat
## 4 secrets outside the unit
-rw------- 1 agent agent 26 Oct 20 20:38 /srv/agent/agent.env
## 5 service unit
unit verifies
## 6 enable and check
Created symlink '/etc/systemd/system/multi-user.target.wants/agent.service' -> '/etc/systemd/system/agent.service'.
active
2026-10-20T20:38:21.502294+00:00
## 7 journal
Oct 20 20:38:21 23e900155e26 systemd[1]: Started agent.service - Always-on agent.
## 8 memory and kill test
NRestarts=0
MemoryMax=536870912
active
NRestarts=1
## 9 timer instead of cron
Created symlink '/etc/systemd/system/timers.target.wants/agent-hourly.timer' -> '/etc/systemd/system/agent-hourly.timer'.
Tue 2026-10-20 21:00:26 UTC 21min - - agent-hourly.timer agent-hourly.service
## 10 what a Pi adds: log2ram would mount /var/log in RAM; here is the disk the logs sit on
overlay overlay 175G 11G 156G 7% /
DONEThe Pi checklist
- Flash the 64-bit image with the Imager's Customisation tab filled in. Hostname, user, Wi-Fi, SSH with a public key.
- Power it from the official 5A supply, and add the Active Cooler if the agent runs a model often. A 3A supply caps USB at 600mA and disables USB boot by default.
- Decide where logs and state live before the first run. log2ram for a card, or boot from an SSD. The agent's SQLite file and memory folder go on whichever it is, and into the backups.
- Follow the Debian guide for the user, the venv, the service and the timer. Nothing changes on the Pi except the architecture, which apt and pip handle for you.
- Pick a model the board can run, or none. A 1.5B model for sorting and summarising at about ten tokens a second; a hosted model for anything that takes actions.
- Give it a heartbeat. A Pi on a shelf is the easiest computer in the world to forget. A daily message that says it is alive is the cheapest insurance there is.
If you want to see what I run instead of a Pi, it is a Mac that sleeps, and the Mac guide is the one with my own plists in it. The product I sell, Leo, runs on cloud servers, because an hourly loop that edits video is not a Pi-sized job. Listening is. Start there.
Sources
- Raspberry Pi, Getting started: Raspberry Pi Imager and OS customisation (accessed October 20, 2026)
- Raspberry Pi, Introducing: Raspberry Pi 5 (power supply and USB current limits) (accessed October 20, 2026)
- Raspberry Pi, Raspberry Pi hardware documentation (usb_max_current_enable, PSU_MAX_CURRENT, NVMe boot) (accessed October 20, 2026)
- azlux on GitHub, log2ram: put /var/log into a RAM folder (accessed October 20, 2026)
- Stratosphere Laboratory, Research and analysis of performance of LLM on the Raspberry Pi 5 (accessed October 20, 2026)
Written by Lera Leonteva. I do not own a Raspberry Pi. The service steps were run in a fresh arm64 Debian 13 container; the hardware facts are the documentation's, as read on the access date.