BRAIN / BODY · 100% SELF-HOSTED · ZERO CLOUD

A personal AI that's always on, and never leaves home.

An always-on assistant, driven from the phone's chat app (no app to build), that understands voice notes and runs entirely on owned hardware — no per-token bill, no audio or messages traveling to a third party. The trick: split it across two machines by strength.

This page describes a system running on my own hardware. The repository publishes the architecture and the decisions, not the implementation. The components that do ship code have their own repositories, linked below.

2 nodes
always-on body + on-demand GPU brain
~20 W
the mini-PC that never sleeps barely draws power
0 cloud
audio, messages, and reasoning stay on owned hardware
chat UI
the interface already lives on the phone, no app needed
The idea

Split the system by its strengths.

The always-on node holds state and connectivity; the GPU node provides on-demand capacity. If the GPU is asleep, the body still responds and queues work for when it wakes up.

🟢 THE BODY

Mini-PC · always-on · ~20 W

24/7 services: agent orchestrator, chat gateways, work queues. Cheap to keep running forever; a stable host for everything that must never sleep.

🔴 THE BRAIN

GPU workstation (24 GB) · on-demand

Heavy compute: local LLM inference + speech-to-text. Only powers on when needed; does the work the mini-PC can't. They connect over a private VPN mesh.

What it does

Three capabilities, zero cloud.

💬

Control from chat

A daemon-gateway exposes a local HTTP API with a token. The security edge is SSH: ssh mini-pc "send ...". Any tool — even an AI session — reads and sends messages without ever holding the credentials.

🎙️

Voice notes → text, locally

The note is queued on the always-on node, transcribed on the GPU with a local Whisper (CUDA), and the text returns to the chat tagged with who sent it. The audio never leaves home.

🧠

24/7 agent with a local brain

The orchestrator runs as a persistent service and uses the GPU's local LLM (via an OpenAI-compatible endpoint over the mesh) as its reasoning engine — persistent memory, tool use, accessible from chat.

🩹

Graceful degradation

If the GPU node is off, the always-on node still responds and queues. Nothing hard-fails because one machine was asleep. The cloud is an option, never a dependency.

Tech stack

Pieces, and why.

ConcernChoice
Always-on hostLinux mini-PC, systemd services (Restart=always)
Heavy computeGPU workstation (24 GB), powered on-demand
Local LLMOllama (OpenAI-compatible API)
Speech-to-textWhisper.cpp (CUDA build, large model)
NetworkTailscale mesh VPN — nodes reachable from anywhere, private
Chat controlGateway daemon + local API with token; ssh as the trust boundary
Design principles

How I think about AI deployment.

1

Brain/body

Separate always-on connectivity from on-demand capacity. Cheap to keep alive, powerful when it matters.

CORE
2

Graceful degradation

If the GPU is off, the always-on node responds and queues. Nothing hard-fails because one machine was asleep.

3

Local-first / privacy by design

Audio, messages, and reasoning stay on owned hardware. The cloud is an option, not a dependency.

4

SSH as the security edge

Services bind to localhost + token; remote access is only through the mesh + SSH, so secrets never travel.