No account. No telemetry.

Your agents.Your machines.

Review pull requests. Keep a knowledge base. Run the nightly job. Give each agent its own memory, tools and budget — on a machine you control.

Get started with alpi → Or in your terminal: uv tool install alpi-agent See it in practice →

Python 3.11–3.13 · Linux and macOS · Windows via WSL2
One daemon per machine. Every profile a directory you can back up.

A morning with your agentsIllustrative session

One daemon. Your terminal, desktop and phone.

✱Runs on hardware you own
✱Memory in files you can read
✱Your provider keys, your bill
✱No registry, no broker
From one agent to your own network

Start with one.
Let it grow with you.

An agent in your terminal today. A daily briefing from your server tomorrow. Add another profile when the work needs its own memory, tools or model.

  1. 01
    Give it a real responsibility.

    Review changes, learn your documents or prepare a morning report.

  2. 02
    Keep the context.

    Memory and reusable skills stay with the profile, beyond a single conversation.

  3. 03
    Connect it on your terms.

    Schedule the work. Grant access to a peer. Choose when it should notify you.

Set up your first agent →
A daily briefingExample setup
08:00 · Your scheduled task
Your server

blue shieldreviewer

Checks the changes.
Prepares your briefing.

Own memory & budget
ALP
Another machine

green treelibrarian

Finds the context
in your knowledge base.

Own memory & budget

Pinned peers · Explicit permission to ask

Your morning, already in context
“Three changes reviewed. One retry issue needs your attention. Here is the context.”
Delivered to your paired apps
One machine is enough to start. Peers are optional. Each agent uses the local or cloud model you configure.
01 / The unit you own is the profile

A home for every responsibility.

Code review, project knowledge, research or a daily report. Each has its own model, memory, keys, schedules and spend, kept together in a profile.

Separate state. Permission to collaborate.

One daemon supervises the profiles on a machine. Each keeps separate state, credentials and spending records; peer calls need explicit grants. Profiles organize responsibilities under one owner. Mutually untrusted tenants need separate runtimes.

blue shieldreviewer

Reviews code changes and flags what needs attention.

keyed25519 · 9f2c…
memoryown
modelopus-5
cap$20 / day
toolsrepo, email
green treelibrarian

Keeps project knowledge and finds relevant context.

keyed25519 · 41ab…
memoryown
modelflash
cap$20 / day
toolsknowledge
violet starresearcher

Compares sources and prepares a cited brief.

keyed25519 · c07e…
memoryown
modelflash
cap$20 / day · hit 11:40
toolsbrowser
blue shieldreviewer→ link.ask →green treelibrarian everything else: denied
identity

A profile is the boundary.

A profile is a directory under ~/.alpi/: model, memory, skills, keys, schedules, logs, approvals and ALP peer list, all in files. Copy it to back it up, open it to audit it, delete it and the agent is gone. Crossing the boundary requires capabilities you grant explicitly.

per-profile
model choice

No model is chosen for you.

The daemon assumes no model and never will. Route the reviewer to a frontier model, the indexer to a cheap one, and anything that cannot leave the building to a local Ollama server — per profile, changed without touching a peer.

no lock-in
memory

Memory you can open.

No hidden vector store as the source of truth. USER.md, MEMORY.md, and AGENT.md are updated in the moment and stay readable on disk.

plain files
skills

Skills that pass inspection.

A skill is a directory: instructions, scripts, references, assets, its own secrets and its own state. Mutations run through validation and a security scanner before they become useful.

scanner-gated
integrations

MCP servers, scanned first.

Point a profile at any MCP server and its tools register as alpi tools. npm-launched servers are checked against OSV for known malware before the wizard saves them, subprocesses get a stripped environment instead of your keys, and everything the server returns enters the turn labelled untrusted.

mcp client
operations

Small surface. Real upkeep.

One setup wizard, live doctor checks, launchd/systemd services, merged logs, approval audit, and a per-machine daemon supervising the scheduler, ALP, and host plane. A per-profile daily USD cap, checked before every model call, keeps a runaway agent from quietly burning your API budget.

day-2 ready
02 / Set it up once, then it is yours

One daemon. Your agents around it.

Five decisions, once. After that it runs unattended, and every surface reaches the same agents.

  1. 01

    Pick your model.

    Claude, OpenAI, OpenRouter, Gemini, Groq, Ollama or your own endpoint. A fresh profile starts empty, so nothing is chosen for you.

  2. 02

    Give each responsibility a profile.

    Each profile is its own directory, so retiring one is alpi profile remove — the key, the memory, the schedules and the peer list go with it. No orphaned agent left running somewhere with credentials nobody tracks.

  3. 03

    Pair the devices you use.

    The desktop app and the phone pair once, by scanning a code. The terminal on the machine itself pairs with nothing — the local socket is sovereign and carries no token. Revoking one device disconnects only that one, mid-session.

  4. 04

    Pin the peers you trust.

    By key, never by hostname. An unpinned sender is dropped at the transport, before a model ever sees the message.

  5. 05

    Set the ceiling.

    A daily dollar ceiling per profile, checked by the daemon before every model call — outside the context a looping agent can reason about.

03 / ALP — the Alpi Link Protocol

A team of agents. One protocol.

ALP is how alpi agents talk to each other — across profiles, across machines, and in workgroups. Pinned keys, signed envelopes, grants you wrote. Nothing in between.

One key per profile. Every envelope signed. Unknown sender, dropped at the transport.

The key is generated on your machine and never leaves it. There is no directory to be listed in and no account to be locked out of — the only thing that makes two daemons trust each other is a public key each owner pasted into the other's peer list. The next agent joins the same way: one line in a file. Nobody else can add a peer to your fleet, and nobody else can remove one.

ALP.1

Profile to profile

Same machine, same daemon. alp.sock at mode 0600. The grant is a line in the peer list; not listed, not allowed.

ALP.2

Machine to machine

Noise_XK handshake plus ChaCha20-Poly1305, forward-secret session keys. No TLS, no PKI, no certificate authority to trust — identity is the pinned pubkey on both sides.

ALP.3

Workgroups

A team of agents on one task under a stable group key — the way it runs in production today. A hub holds the transcript; members join, post and settle their own spend. No replication, no consensus election.

link.ping // liveness
link.ask // runs a full agent turn on the peer, using its memory, skills and tools
link.cancel // interrupt
link.put_blob // hand a peer a file, chunked and hash-addressed
link.get_blob // fetch one back
 
// five methods, each granted separately. no introspection, no federation, no generic RPC surface.
capabilities

Fail-closed per peer.

Every peer lists an allow: array of methods it may invoke. Not listed, not allowed. Rate limits are per peer, per minute. Spend is not: every inbound call draws on the same daily profile ceiling, and a tripped cap answers -32005 budget-exceeded.

reentrancy

Reject fast, never queue.

A second link.ask on a running session returns -32007 target-busy. The caller retries with jittered backoff. No deadlock class.

audit

Every crossing is recorded.

Who asked, which method, under which capability, what it cost. The approval log is per profile and survives the turn — a fleet you cannot account for is a fleet you do not control.

04 / Put it on a machine you already run

Put alpi to work.

Start in the terminal or the desktop app, then pair your phone. The clients are windows onto the same daemon; your keys never leave the machine running it.

desktopstart here

alpi for desktop

Pair every daemon you own and switch with one click. Approvals, sessions and logs in a native window.

Download for macOS →

Apple Silicon · v0.8.7

also for your desktop — client only, pairs with a Linux or macOS daemon Windows · x64 ↗ Linux · AppImage ↗
in your pocket

alpi for mobile

In internal testing. Scan a QR to pair with your daemon; chat, workgroups, inbox and approvals, sized for one hand.

App StoreiPhone & iPad
Google PlayAndroid

Builds are in internal testing. Biometric unlock; pairing tokens never leave the device.

from the terminal

Four commands. No account.

Python 3.11 to 3.13 — uv installs one if you have none. The default profile lives in ~/.alpi/; every other one under ~/.alpi/profiles/.

Install guide →

# 1. install from PyPI (uv recommended; pipx works too)
$ uv tool install alpi-agent   # package name; binary stays "alpi"

# 2. configure the default profile (model + .env + workspace)
$ alpi setup

# 3. chat
$ alpi

# 4. check health
$ alpi doctor
your server

alpi on an always-on machine

One daemon supervises every profile on the box — scheduler, peers and host plane. Install it with uv, or run the container on a NAS or a VPS.

$ uv tool install alpi-agent
$ docker pull satoshiltd/alpi:latest

uv install: Linux and macOS. Container image: linux/amd64 and linux/arm64. Then alpi setup in the terminal — docker exec -it <name> alpi setup inside the container.

Free for individuals on machines they control — personal, research and non-commercial use, production included. Companies get evaluation and development free; production deployment runs under a commercial licence. Read the licence →

Questions, answered

Before you get started.

The answers people ask for before putting agents anywhere near production.

What does it cost to run?

You pay your model provider directly, using your own API keys, and cover the machine it runs on. Set a daily dollar ceiling per profile to limit model spend across chats, scheduled jobs and peer requests. You can also use a local model. Commercial production use requires a separate licence.

Where can I run it?

A laptop, an always-on home server, a shared team box or a cloud VM. For offline work, configure a local model and use tools that do not need the network. Scheduled jobs need the machine and daemon to be running.

Does anything leave my machine?

Your memory and configuration live on your machine. If you choose a cloud model, the prompts and context needed for a turn are sent to that provider; tools and configured peers can also send data outside the machine. Use a local model for local inference. Alpi has no usage telemetry or central account. It also makes update and security checks and downloads browser or model components when needed.

What about prompt injection?

It is treated as a blast-radius problem, not a filtering one — because filtering does not work. Capabilities are fail-closed per peer, dangerous verbs go through an approval gate, sensitive paths are denied, outbound requests are SSRF-guarded, and the terminal can run inside an OS sandbox.

Can I use it at work?

Personal use, research and evaluation are free. Commercial production, or offering alpi as a hosted, embedded or managed service, runs under a Satoshi Ltd. commercial licence. The code is source-available under BSL 1.1 and converts to Apache 2.0 on 2030-04-23, or four years after each version's first public release, whichever comes first. Read the licence ↗ · info@satoshi-ltd.com

How does it connect to what we already run?

Any MCP server you configure becomes a tool the agent can call, checked against OSV for known malware before it installs and run under the same approval gates as everything else. Email works over IMAP or Gmail, driven by the agent during a turn or a scheduled job. And your own code can drive a profile or a workgroup directly over the host plane with a scoped device token.