How to Run a Personal AI Agent on a Raspberry Pi (2027)

You want an agent that runs routines while you sleep: a 07:30 summary of today's meetings, an overnight check on failed deploys, a draft standup waiting when you sit down. You don't want a laptop open on your desk 24/7 to do it. A Raspberry Pi is the obvious host. This guide shows how to set one up with any runtime, from a cron job and a Python script to a full agent like OpenAGI, a source-available personal agent that runs as a daemon on hardware you control. The steps work with any of these options. The parts that usually go wrong are hardware, model routing, security and spend, and this guide covers each one.

What a Personal AI Agent on a Raspberry Pi Actually Is

A personal AI agent on a Raspberry Pi is a small, always-on Linux computer that runs the agent's runtime (its scheduler, memory, integrations and dashboard) and sends the actual thinking, model inference, to a model you choose. That model is usually a cloud API or a model server on a more powerful machine on your network.

The Pi is the host, not the brain. It keeps state, holds OAuth tokens and API keys, runs schedules, and calls tools such as Gmail, Google Calendar, Slack, GitHub or MCP servers. Most of that work is I/O-bound. The agent spends its time waiting on APIs, reading mail and writing logs, and a 5-watt board handles that well. Generating text is compute-bound, and a Pi does that poorly.

A Pi-hosted agent is good for:

• Scheduled summaries: today's calendar, emails that need a reply, overnight alerts.
• Triage drafts: proposed replies, ticket labels, standup notes for you to approve.
• Routine checks across Slack, GitHub, calendar and email at fixed times.
• Context across sessions: memory that persists because the host never sleeps.

It is not a guarantee of autonomous work. It is a set of capabilities you configure, test and verify over time. Treat its outputs as drafts until a routine has run cleanly for a while.

Privacy truth: storing state on the Pi does not mean your prompts stay on the Pi. If the model is a cloud API, the email subjects, calendar entries and other context in each prompt leave your network.

Why It's Harder Than It Looks: What Actually Breaks

Most failed Pi agents fail because of hardware, scheduling, credentials or cost, not the AI. The symptom is usually the same: the routine just didn't run, and nothing told you. These are the common causes.

• Running the model on the Pi. CPU-only llama.cpp on a Pi 5 (8 GB) produces roughly 5–15 tokens/s with ~1B-parameter 4-bit models and roughly 1–3 tokens/s with 7–8B models, per community benchmarks. Processing a 12k-token email digest on CPU alone can take minutes. Decide the model route before anything else.
• SD card wear. Agent state, logs and SQLite databases write constantly. SD cards wear out and corrupt after power cuts. Boot from a USB SSD, or from NVMe on a Pi 5 with the M.2 HAT+.
• Power and heat. A Pi 5 wants the official 27 W USB-C supply (5.1 V, 5 A). With a weaker supply it limits USB current, which can starve a USB SSD. A Pi 5 starts throttling around 80 °C and throttles harder at 85 °C. Run vcgencmd get_throttled: 0x0 is healthy, 0x1 means under-voltage now, 0x4 means throttled now, and values like 0x50000 mean those events happened since boot.
• Exposed dashboards. This is the biggest security risk. A port-forwarded dashboard that holds your email and calendar tokens gives your inbox to whoever finds it. In 2025, Shodan-based research, including a widely reported Cisco Talos study, counted more than 1,100 publicly exposed Ollama servers with no authentication.
• Silent OAuth expiry. Google OAuth refresh tokens for External apps left in Testing status expire after 7 days. A Gmail integration that worked on day one fails on day 8, and you only see it in the logs.
• Runaway spend. A tool-call loop, an unbounded retry storm on 429 errors, or a full inbox pasted into one prompt can burn your API budget overnight.
• Clock and timezone drift. A Pi 4 has no real-time clock and relies on NTP after boot. A Pi set to UTC sends your 7:30 summary at the wrong hour.
• A dependency on another machine. If the model server runs on a desktop that sleeps, every scheduled routine fails at the scheduled time.

The Method: 7 Steps to an Always-On Agent You Can Trust

These seven steps work with any runtime, including a cron job plus a Python script you write yourself. No product is required. Do them in order. Step 2 matters more than the rest.

Step 1 – Choose the Hardware

• Use a Raspberry Pi 4 or 5 with 4–8 GB RAM and a 64-bit (arm64) OS. Raspberry Pi OS Lite 64-bit, now on a Debian 13 "Trixie" base, is the right image for a headless agent host because it has no desktop overhead. Check current pricing first: DRAM costs pushed Raspberry Pi prices up on several models in late 2025.
• Boot from an SSD instead of SD where possible. On a Pi 4, update the bootloader EEPROM and use a USB 3 SSD. Some USB-SATA bridges have UAS quirks, so buy a known-good one. On a Pi 5, NVMe via the M.2 HAT+ is the cleanest option.
• Use the official power supply and the Active Cooler or a cooled case.
• Prefer Ethernet to Wi-Fi. Give the Pi a fixed DHCP reservation and a hostname such as agent-pi.local.
• Enable SSH with key-only auth and set PasswordAuthentication no in /etc/ssh/sshd_config.

Step 2 – Choose the Model Route

The model route determines availability, privacy and cost. The Pi's job barely changes between routes. For each option, write down what must be powered on at the scheduled time.

Option C is only for tiny, latency-tolerant jobs such as classifying a subject line. For summaries and drafts, choose A or B.

Step 3 – Install the Runtime as a Service

• Run sudo apt update && sudo apt full-upgrade, then create a dedicated non-root user: sudo adduser --disabled-password agent.
• Install your runtime as that user and keep all state in one known directory so you can back it up.
• Run it under systemd so it restarts on crash and on boot.
• Enable NTP and set the timezone: sudo timedatectl set-timezone Europe/London, then confirm System clock synchronized: yes with timedatectl.

[Unit]
Description=Personal AI agent
After=network-online.target time-sync.target
Wants=network-online.target

[Service]
User=agent
WorkingDirectory=/home/agent
ExecStart=/home/agent/bin/agent-run
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

Step 4 – Lock Down the Dashboard and API Surface

• Bind the dashboard to 127.0.0.1 only and reach it from your laptop with an SSH tunnel: ssh -L <port>:127.0.0.1:<port> user@agent-pi.local.
• Or put it behind a private VPN such as WireGuard or Tailscale.
• Never forward the port on your router. Require a token or password if the runtime supports one.
• Firewall with ufw: sudo ufw allow from 192.168.1.0/24 to any port 22, sudo ufw default deny incoming, sudo ufw enable. If you use Docker, publish ports as 127.0.0.1:PORT:PORT, because Docker's port publishing bypasses ufw rules.

Step 5 – Connect Only What the First Routine Needs

• Start read-only: calendar read and email read, not send.
• Require human approval for any write: sending email, creating events, posting to Slack.
• Use the narrowest OAuth scopes the provider allows, for example gmail.readonly and calendar.readonly. Move your Google OAuth app out of Testing status, or plan for the 7-day refresh-token expiry.
• Keep secrets in a file owned by the agent user with chmod 600.

Treat every email, invite and Slack message the agent reads as untrusted input. A crafted email can carry instructions telling the agent to forward data. Simon Willison calls this the "lethal trifecta": access to private data, exposure to untrusted content, and the ability to communicate externally. Read-only scopes plus approval for sends removes the third part.

Step 6 – Set Spend Limits Before the First Scheduled Run

• Set a hard daily cap and a per-request (per-turn) cap at the provider, in the runtime, or both. The provider cap is the backstop. The runtime cap is the circuit breaker. Some provider "caps" are only budget alerts that don't stop spending, so confirm which kind yours is.
• Use a dedicated API key or project so the agent's spend is isolated and revocable.
• Truncate inputs: sender, subject and the first N characters of each email, not full threads.
• Cap retries at two, with exponential backoff.
• Log tokens used per run.

Step 7 – Test One Scheduled Routine End to End

1. Run it manually and read the output.
2. Schedule it 5 minutes out and confirm it fires without you.
3. Reboot the Pi and confirm it still fires.
4. Revoke the token on purpose and confirm you get a visible failure notice, not silence.
5. Only then add routine #2.

For loud failures, add a dead-man's switch: ping Healthchecks.io or a self-hosted equivalent at the end of each successful run. If the ping doesn't arrive, you get alerted. This one check catches power, clock, token and network failures. Send failure notices through ntfy, Pushover or a Slack webhook.

Go-live checklist (copy into a spreadsheet):

• SSD boot, official PSU, cooling, vcgencmd get_throttled returns 0x0
• Key-only SSH, ufw enabled, dashboard bound to localhost
• Timezone set, NTP synchronized
• Runtime under systemd, survives a reboot
• Read-only scopes, approvals on all writes, secrets at chmod 600
• Daily cap + per-turn cap + dedicated key + retry limit
• Tokens logged per run, dead-man's switch ping configured
• State directory included in backups

Worked Example: A Weekday Morning Summary From Calendar and Email

The goal: at 07:30 on weekdays, send me a 10-line summary of today's meetings and the emails that need a reply. Here is each decision and the reason for it.

Hardware

A Pi 5 with 8 GB booting from a USB SSD. The reason is reliability under daily writes, not speed, because the model runs elsewhere.

Model Route

The desktop with the GPU sleeps after 30 minutes and is off overnight, so a LAN model server fails the 07:30 availability test. The scheduled routine uses a cloud API. The LAN server stays available for interactive daytime chat, where privacy matters more and the desktop is awake. If you need email content to stay off third-party servers, the alternative is to keep the desktop awake on a schedule and accept the electricity cost.

Input Sizing (Illustrative Assumptions)

• About 40 unread emails, truncated to sender + subject + first 500 characters: roughly 12k input tokens.
• Calendar: about 1k tokens.
• Output: about 500 tokens.

Cost per run = (input tokens × input price) + (output tokens × output price), using your provider's current published rates. Prices change too often to hard-code here.

Spend Caps

Set the daily cap at 2–3× one run's expected cost, so one retry succeeds but a loop gets stopped. Set the per-turn cap just above one run's expected input size, around 14k tokens, so a bug that pastes full threads fails instead of billing you.

Permissions

Gmail and Calendar are read-only. The summary goes to you only. Any "reply to this" action needs your explicit approval.

Schedule

Weekdays at 07:30 local time. With cron: CRON_TZ=Europe/London then 30 7 * * 1-5. With a systemd timer, which catches up after downtime:

[Timer]
OnCalendar=Mon..Fri 07:30 Europe/London
Persistent=true

[Install]
WantedBy=timers.target

Test Log

• Day 1: Did it fire at 07:30 local? Was the output 10 lines and accurate?
• Day 2: Reboot the night before. Did it still fire?
• Day 7: Is the OAuth token still valid? Are tokens per run stable, not creeping up?

Success means it runs unattended for a week and its cost stays inside the cap. Change the route if your privacy requirements tighten, or if you decide to keep the GPU desktop awake.

Common Mistakes (Including Ones No Agent Software Fixes)

Most Pi agent failures are configuration choices, and several of them can't be fixed by any agent software.

• Running the main model on the Pi and then deciding "agents are too slow."
• Port-forwarding the dashboard for convenience. Use an SSH tunnel or VPN.
• Assuming local storage means private inference. Check where your configured provider sends prompts and what its retention terms are.
• Granting send/write scopes on day one instead of read-only plus approvals.
• Running without a spend cap "just for testing."
• Hardware and network problems: SD card corruption, cheap power supplies, no cooling, flaky Wi-Fi (prefer Ethernet), and no backup of the state directory. Software can't fix these.
• Scheduling against a model server on a machine that sleeps.
• Adding five routines at once, so you can't tell which one broke.
• Expecting finished autonomous work. Treat outputs as drafts until the routine has a track record.

When You Need Tooling (and When a Laptop or Cron Script Is Enough)

A laptop works fine as an agent host if it is truly always on and plugged in. A Pi is cheaper to leave running, quieter, and lets the laptop sleep, travel and reboot for updates. A Pi 5 draws roughly 2.5–3.5 W at idle. At about 4 W average, that is around 35 kWh a year, or about $6 at a $0.17–0.18/kWh residential rate. Rerun it with your tariff: watts × 8.76 = kWh/year. A laptop left awake (10–30 W) costs roughly $15–45 a year, and a GPU desktop idling at 50–100 W+ costs about $75–150+.

A practical rule for script versus runtime:

• One or two fixed, read-only routines are well served by cron plus a script.
• Once you need memory across sessions, approval gates for writes, several OAuth integrations to keep alive, daily and per-turn spend tracking, or routines learned from your activity, the hand-rolled script becomes a project of its own.
• Supervising coding agents is a separate threshold. If you run several coding-agent sessions in parallel, checking each one by hand stops scaling.

Option 1: OpenAGI on a Raspberry Pi

OpenAGI is a source-available personal agent (PolyForm NC) by Spencer Shulem that runs on a computer you control, keeps context across sessions, and learns routines from activity you choose to share. It has no telemetry and no accounts, and it supports Linux and Raspberry Pi directly.

• Install: curl -fsSL openagi.sh | sh on Linux and Raspberry Pi. Docker, a Mac menu bar app (v0.0.58), and Windows from source (Node.js 22+) are also available.
• Dashboard: http://127.0.0.1:43210/. Pair it with Step 4: ssh -L 43210:127.0.0.1:43210 user@agent-pi.local.
• Model routes: cloud API, ChatGPT sign-in, a local model server, or Apple Intelligence on compatible devices.
• Connections: Gmail, Google Calendar, approved messaging contacts, reviewed skills, and MCP tools. For example, the buildbetter-mcp server can pull customer context before a meeting. Email and calendar writes require approval.
• Spend limits: daily and per-turn model caps built in.
• Tiered memory: short, medium and long-term ("Lava"), so a correction you make once stays made.
• Adaptive Scrutiny: each signal is scored on seven axes (urgency, impact, novelty, risk, confidence, specificity, conflict) before the agent chooses to act, ask, watch, ignore or propagate.
• Bounded specialists: risky or repeated tasks get scoped sub-agents with their own permissions.
• Learned routines: it can notice a weekday pattern, such as checking #incidents in Slack, pulling yesterday's deploys from GitHub and drafting a standup, then offer to save it as a skill after you approve. Opt-in screen capture applies on desktop hosts. A headless Pi learns from the integrations and conversations you connect.
• Supervisor: one view of Codex, Claude Code, Conductor and Antigravity sessions, showing whether each is working, waiting on checks, blocked, or waiting for you. It reads verification evidence instead of trusting an agent's "done." Modes are Observe, Propose and Auto, and Auto only sends bounded nudges after you explicitly enable it.
• Proactive channels: SMS, Telegram and HTTP webhooks.
• State: lives in ~/.openagi on the host, so back up that directory.

Caveats: these are capabilities to configure and verify, not a promise of autonomous work. Prompts go to whichever provider you configure. Mobile apps are source/QA builds with no public store release.

Other Options: Peer Agents and a DIY Stack

Other local-first agents and a plain DIY stack can also run a Pi-hosted routine. Hermes Agent from Nous Research is OpenAGI's closest open-source peer, with persistent memory, auto-skills, model-agnostic routing and many chat channels. OpenClaw and PicoClaw were early durable-memory, MCP-registry daemons. LittleBird.ai covers similar always-on assistant ground as a cloud SaaS Mac app. General agents such as AutoGPT, BabyAGI, AgentGPT, Cognosys, Operator, Claude.ai and Devin target different jobs than a 24/7 home host. The DIY route is cron or systemd timers, a script, a provider SDK, and optionally Ollama or llama.cpp on a LAN machine.

FAQ

Can a Raspberry Pi run a personal AI agent?

Yes. A Raspberry Pi 4 or 5 with 4–8 GB RAM running 64-bit Linux can host the agent runtime: scheduler, memory, integrations and dashboard. For good results, route model inference to a cloud API or a model server on a more powerful machine, and use the Pi as the always-on host.

Can I run the LLM directly on the Raspberry Pi?

Only small models, and slowly. CPU-only inference on a Pi 5 manages single-digit to low-double-digit tokens per second with ~1B-parameter quantized models, and processing a long prompt such as an email digest can take minutes. That's fine for tiny, latency-tolerant tasks. For summaries and drafting, use a cloud API or a LAN model server. Add-on accelerators exist, but check current model support before buying one for LLM work.

Is a self-hosted AI agent on a Raspberry Pi private?

Partly. Your state, logs and credentials stay on the Pi, but prompts go wherever your model runs. Inference stays inside your network only if the model server (for example, Ollama or llama.cpp) is on your LAN. With a cloud API, the content in each prompt goes to that provider under its data-retention terms.

How do I access the agent dashboard safely from my laptop?

Keep the dashboard bound to 127.0.0.1 on the Pi and connect with an SSH tunnel: ssh -L 43210:127.0.0.1:43210 user@agent-pi.local, then open http://127.0.0.1:43210/. You can also use WireGuard or Tailscale. Never port-forward it on your router. If you use Docker, publish the port as 127.0.0.1:PORT:PORT, because Docker bypasses ufw.

How do I stop an AI agent from running up my API bill?

Before the first scheduled run, set a hard daily cap and a per-request cap at the provider, in the runtime, or both. Use a dedicated API key, truncate inputs (sender, subject and the first N characters rather than full threads), limit retries, and log tokens per run. A useful sizing rule is daily cap = 2–3× one run's expected cost.

Should I use a laptop or a Raspberry Pi?

Use a laptop if it is truly always on. Use a Pi if you want a cheap, quiet, low-power host that runs 24/7 without tying up your main machine. It costs roughly $6 a year in electricity at typical US rates.

Sources and Further Reading

• OpenAGI website: https://openagi.sh
• OpenAGI README: https://github.com/spshulem/openAGI
• Raspberry Pi official documentation: https://www.raspberrypi.com/documentation/
• Raspberry Pi on Wikipedia: https://en.wikipedia.org/wiki/Raspberry_Pi
• Model Context Protocol documentation: https://modelcontextprotocol.io
• Ollama (local model server): https://ollama.com
• Google Identity, Using OAuth 2.0 to Access Google APIs (refresh token expiration)

Install OpenAGI in 5 Minutes

If you've decided a cron script won't cover what you need, OpenAGI gives your Pi persistent memory, spend caps, approval gates and a decision layer. It runs as a daemon on hardware you own, works with the model you choose, and sends no telemetry. Run curl -fsSL openagi.sh | sh on your Pi, tunnel to the dashboard, and start with one read-only routine.

Install OpenAGI in 5 minutes. → Star on GitHub