Docs.
What we have so far. Peerd V1 is in development; sections marked ⊘ at launch will be available when V1 ships in the Chrome Web Store. Sections marked ◌ later are on the roadmap.
The architecture and security model below are real and final. They're what V1 is being built to.
What peerd is.
Peerd is a browser extension that turns your browser into an AI agent harness. The agent runs entirely client-side: in your browser, using your browser's session, talking to whichever model provider you pick with your own API key.
The product thesis: cloud AI browsers (Comet, Atlas, Brave Leo, Dia) ask you to switch your default browser. Native AI apps (Hermes, OpenCode, Claude Code) ask you to install another app — and reach the browser via janky external MCP servers (Playwright MCP, browser-use, BrowserBase MCP) that drive a headless browser from outside, without your session state. All three reimplement what the browser already does — session state, the DOM, hardware access, peer networking — only worse, and with a process or server in between. Peerd inherits all of that from the browser directly, with no backend in the loop.
The extension is free and open source under Apache 2.0. There is no Peerd service to subscribe to, no telemetry, no account. You pay your model provider directly.
Get going.
Install ⊘ at launch
Peerd will be available in the Chrome Web Store at V1 launch. Add the extension; it'll open the side panel automatically and walk you through first-run setup. Sign up for the waitlist to be notified.
Set up your provider key ⊘ at launch
On first run, Peerd will prompt you to set a passphrase (used to encrypt your provider API key locally) and paste an API key from your model provider. V1 ships with Anthropic; OpenAI and Ollama follow in V1.1. Your key is encrypted with WebCrypto and stored only in your browser — Peerd has no server to send it to.
First task ⊘ at launch
Open the side panel, type what you want done, and the agent starts working. It can read pages, click links, fill forms, and run shell commands in a sandboxed Linux VM that runs in your browser via WebAssembly. For anything that could change state irreversibly — submits, downloads, cross-origin requests — it asks you to confirm first.
Voice ⊘ at launch
Optional. Off by default. The setup wizard has a Voice toggle; flipping it on opens a confirmation showing the model source (Moonshine), the download size (~120 MB), and the privacy facts. Confirming triggers a one-time download from jsDelivr; the model is SHA-384 verified against a baked-in hash and cached in IndexedDB. After that, all transcription happens locally — no audio ever leaves your browser.
Once enabled, a mic icon appears next to every text input. Click it, start talking, and the transcription streams into that input. The mic auto-stops after a configurable silence threshold (default 1.5s), or you can click again to stop manually. ESC also stops listening from anywhere.
Model variant. Three sizes ship: tiny (26 MB,
runs on anything), base (60 MB, recommended for
Apple Silicon or discrete GPU), and small (120 MB, best
accuracy on uncommon words and technical terms). The browser
uses WebGPU when available and falls back to WebAssembly
otherwise. On Apple Silicon, WebGPU runs against Metal — fast
enough that base feels instant. Note that browser code can't
reach the Neural Engine yet (no WebNN in production), so peerd
leaves some Apple Silicon performance on the table compared
to a native helper. On the hardware most peerd users have,
this doesn't matter perceptually.
Where the latency floor actually lives. Once you're past WebGPU and a small model, the bottleneck isn't inference — it's audio buffering (~100-200ms regardless of hardware), voice activity detection deciding you've stopped (the silence-threshold slider tunes this), and the round-trip to your model provider for the actual response. Most users drop the silence threshold to 800-1000ms once they get a feel for it.
Five modules. One per letter.
The wordmark is the architecture diagram. Each letter is a real subsystem in the codebase. Each color is fixed in meaning across the brand and the code.
peerd-provider
Model adapters. The connection to whichever LLM you picked. BYOK lives here.
peerd-egress
The security layer. Vault, allowlist, denylist, trust modes, audit. Every outbound call passes through here.
peerd-engine
WebVM. A sandboxed Linux box in WebAssembly. Where shell commands actually run.
peerd-runtime
The orchestrator. Agent loop, tools, skills, memory, sessions, profiles. The thing the side panel UI is a view over.
peerd-distribution
Federation. P2P, swarms, DHT discovery, dwapps. The forward-looking surface — mostly empty in V1, the canvas for V2+.
Module layering: provider, egress, and engine are Layer 1 (no cross-deps between them). runtime is Layer 2 (composes all three; owns sessions, profiles, skills, memory). distribution is Layer 3 (federation across instances — mostly empty in V1).
Six defense layers.
Any agent that reads webpages can be tricked by them. A page can contain hidden instructions telling your agent to read your cookies, exfiltrate session tokens, or summarize your inbox to a third party. Peerd defends with six layers — one inherited from the browser, five we built on top.
Browser process isolation, inherited
Cloud agents build their own sandboxes. Peerd composes with the browser's: per-tab process isolation, same-origin policy, CSP, site isolation, the renderer sandbox. Fifteen years of Chrome security work, applied without us writing a line of it.
Hardcoded egress allowlist
The extension can only make network calls to model APIs you configured. Even if the agent is fully prompt-injected, your conversation can't leave your machine.
Default denylist
Prevents the agent from touching your bank, healthcare portal, password manager, or identity providers. Hundreds of domains pre-populated. Fully editable.
Trust modes per session
Open, Scoped, Paranoid. You pick how much rope your agent gets before it asks. Surfaced persistently in the UI so you always know what's authorized.
Confirmation gates
Form submits, downloads, cross-origin requests — none happen without your sign-off. Bypassable only by you, never by the model.
Structural separation in the prompt
Web content is wrapped as untrusted data, not instruction. The model treats prompt-injection attempts as text to read, not commands to follow.
Two axes of control.
Every session has two top-level controls. Persona decides whether the agent can act at all. Trust mode decides how aggressively it acts. They compose orthogonally — pick one of each per session.
Persona — can the agent act?
Read
The agent observes. Reads pages, takes screenshots, queries the DOM, summarizes. Doesn't click, type, submit, navigate, download, or run VM commands that modify state.
Act
The agent acts. All tools available, gated by trust mode. Switching from Read to Act mid-session requires confirmation.
Trust mode — how aggressively?
Applies when the persona is Act. Determines what counts as "needs confirmation" vs "go ahead."
Open
The agent acts freely. Confirmation only on actions with hard side effects (downloads, cross-origin POSTs, form submits). For trusted contexts and quick tasks.
Scoped
Default. The agent operates only on tabs/origins you've already named or are visiting. Confirmation required to expand scope. Recommended for most work.
Paranoid
Every action requires confirmation. Slow, but maximally visible. For sensitive sessions or when you don't fully trust the page content.
Persona and trust mode are per-session, not global. You can run a Read session in one tab while an Act + Scoped session runs in another. Profiles ◌ later let you persist different defaults per profile.
What comes next.
V1 ships with Anthropic-only, single-profile, single-session, the six-layer security model, and the WebVM. From there, the arc builds outward through provider expansion, then user extensibility, then long-running and multi-agent.
- V1.1// real hands, with safety — OpenAI + Ollama adapters, chrome.debugger upgrade, /undo and /redo, Read/Act personas.
- V1.2// profiles — isolated agent roots: separate vault, denylist, sessions, memory per profile.
- V1.3// tool exposure — per-session tool exposure manifests. Sharper agent behavior, smaller prompts.
- V1.4// skills — user-defined skills as markdown files. Per-skill tool exposure and origins.
- V1.5// memory — persistent distilled state across sessions. Per-profile, vault-encrypted.
- V2.0// long-running — lineage-based context compression, background sessions, subagents.
- V2.1// real DOM tools — mutation observers, network interception, schema-guided extraction.
- V2.2// reachability — external messaging gateway for off-device interaction.
- V2.3// peer to peer — WebRTC between peerd instances, session sharing via link. The name pays off.
- V2.4// local inference — WebGPU running small models in the browser. Privacy mode, offline mode.
- V2.5// hardware — Web Bluetooth / USB / Serial / HID as agent tools.
- V3.0// self-improvement — trajectory export + optional in-browser LoRA fine-tuning.
Timing isn't committed. We're going to prove the V1 thesis first, then build outward. The full roadmap doc lives in the GitHub repo at launch.
Frequently asked.
Is peerd free?
Yes. The extension is free and open source under Apache 2.0. You pay your model provider directly for inference. There's no Peerd subscription, no Peerd account, no usage caps we control.
Which models does peerd support?
V1 ships with Anthropic (Claude). OpenAI and Ollama follow in V1.1. WebGPU local models come in V2.4. The provider layer is designed for adapters, so adding new providers is ~50 lines of code.
How is peerd different from Comet, Atlas, Dia, Brave Leo?
Those are AI browsers — full browsers with cloud agent services bolted on. They require switching your default and they route through their server. Peerd is an extension that runs entirely in your existing browser, with no service in the loop and your API key under your control. Different category.
How is peerd different from Playwright MCP, browser-use, BrowserBase MCP?
Those are MCP servers that drive a headless browser from outside your terminal agent. They run a separate browser process you don't own, without your real session state (cookies, logins, history, extensions), and shim everything through MCP's JSON-RPC layer. Peerd inherits the user's actual browser, runs in-process, talks to the DOM directly, and has the real session state because it IS the browser session. No MCP shim, no headless puppet, no missing logins.
Does peerd phone home?
No. No telemetry, no analytics, no error reporting service, no auto-update beacon beyond the standard Chrome extension mechanism. The egress allowlist is hardcoded to your configured model API. We have no server for it to talk to even if we wanted one.
How is the crypto stack designed?
Peerd doesn't ship its own crypto. The browser provides the entire stack and peerd uses it: WebCrypto's AES-GCM encrypts the vault (API keys, sessions, memory); WebAuthn passkeys unlock the vault via Touch ID / Windows Hello / hardware key; Subresource Integrity verifies every downloaded model and plugin against a baked-in SHA-384 hash; origin isolation keeps the extension's IndexedDB and chrome.storage off-limits to any web page. Terminal harnesses have to ship a crypto library (large dependency, supply-chain risk), wrap an OS keychain (platform-specific install pain), or hand-roll storage. Peerd writes zero lines of cryptographic code. The browser does the work — the same battle-tested primitives that secure your bank session in the next tab.
Does voice transcription work offline?
After the one-time ~120 MB Moonshine model download (jsDelivr, SHA-384 verified, cached in IndexedDB), yes — transcription is fully local and works without network. The audio never leaves your browser. The only network still required is the call to your model provider for the agent's response, which happens whether you typed or spoke. True end-to-end offline operation (including the model) waits on V2.4's local inference via WebGPU.
Can I use peerd offline?
Not in V1 — the cloud model providers (Anthropic, OpenAI) require network. Ollama via local-network in V1.1 works offline if you have it running. True offline operation arrives with V2.4's WebGPU local inference.
Does peerd work in Firefox or Safari?
V1 targets Chrome and Chromium-based browsers (Edge, Arc, Brave). Firefox follows shortly after — the extension is MV3, but Firefox's MV3 implementation has some divergences we have to handle. Safari requires significant rework due to its different extension model; no current timeline.
What does "BYOK" mean?
Bring Your Own Key. You sign up with the model provider of your choice, get an API key, and paste it into Peerd. Peerd uses your key to call the provider. The provider bills you directly. We never see the key, the prompts, or the responses.
When does V1 ship?
When it's ready. We're not committing a date until we're sure we can hit it. Join the waitlist for first notice.
Can I contribute?
Once the repo is public at launch, yes. We'll publish contribution guidelines, the design doc, the architecture doc, and a starter-issue list. Until then, the waitlist is the best way to stay in the loop.