Every meeting,
transcribed and understood
on your own machine.

Create as many agents as you want, each with its own name, identity, and workspace folder. ·Per-agent settings for engine, model, capabilities, channels, skills, voice, active hours, and language. ·Every agent runs sandboxed, with its own files kept separate from the others. ·Live status for each agent — idle, thinking, awaiting approval, or error. ·Delete an agent and everything it owns in a single action. ·Pick an engine per agent: Pi (built-in), Claude Code, Codex, Antigravity, or the Gemini CLI. ·With a coding-agent engine the model is your CLI account; with Pi, choose any provider and model. ·Cloud providers: Anthropic, OpenAI, Google Gemini, xAI (Grok), Groq, DeepSeek, Mistral, OpenRouter, Together, Fireworks, Cerebras. ·Separate model tiers for the main agent, the public/DM agent, subagents, and a secondary model. ·Override the model for a single session from a quick picker. ·Multiple CLI accounts per agent — Claude Code, Codex, Antigravity — auto-rotating when one hits a usage limit, and falling back to another CLI mid-task. ·Order the accounts an agent may use, anywhere they appear, and it works down the list as each one runs out. ·Bring your own endpoint: add any OpenAI-compatible provider (base URL + key) and its models become pickable like the built-in ones. ·Install Claude Code, Codex or Antigravity from inside the app, with a guided login — on this Mac or on a server you added. ·One store for brains, voices and media models: each shows what it costs, when it launched, and how capable it is next to the others. ·Hear a voice before you choose it, with what it costs per minute. ·Setup explains the landscape before asking you to pick — free and local, your own key, or a Claude Code / Codex / Antigravity subscription you already pay for. ·Run entirely on your machine via Ollama, LM Studio, or Jan — no cloud calls. ·Local servers are auto-detected while running and their models registered automatically. ·Auto-launch a local app (hidden in the background, or visible) when an agent needs it. ·Point at custom base URLs for your local servers. ·Signal, iMessage, WhatsApp, Telegram, Slack, and Discord. ·Signal and iMessage run on your own device, with no middleman. ·Read and reply to DMs, and send from the agent's own identity. ·Attach files to a message you send a person, and schedule one for later — it parks itself and the engine sends it whether or not this window is still open. ·Enter goes to your agent; the key that messages the person is deliberately two-handed, and only appears once there is something to send. ·Photos sit centred on a blurred, cropped copy of themselves, so a portrait screenshot and a wide one make the same shape in a thread. ·Files people send arrive as real files in the agent's workspace, on every channel — the only kind of thing its file tools can actually open. ·The agent can send a file back on any channel that can carry one, so "here's the chart you asked for" works in the direction you just received a photo from. ·Telegram as a bot is its own channel, not a fallback hidden inside the account one — its own @name, and people have to open a chat with it deliberately. ·A channel is active only when its keys are in the right machine's vault AND its account is paired; anything short of that says which piece is still missing, with a button back into the setup that knows. ·Turning a channel on is a wizard that asks for every key that channel needs — not one box that takes the first one and declares victory. ·Social inboxes via Overblast: Instagram, X, TikTok, Facebook, LinkedIn, YouTube, Threads, Reddit, Pinterest, Bluesky, Snapchat, Google Business. ·An email inbox the agent sends and replies from — one conversation per thread, named by its subject, searchable, with attachments that work. ·Phone calls arrive as conversations with the actual transcript, named for whoever called. ·Comments are their own channel, scoped to the post they're on. ·A web-chat widget for your site, and agentic phone calls. ·Connect a workspace once and reuse a saved key across agents. ·An agent can ask you a question over any of these and wait for the answer, with anything it asks about untrusted text fenced off. ·Per-channel auto-reply, toggled independently. ·An active-hours window so agents only run when you want them to. ·Outgoing quarantine — review and approve messages before they send. ·Group-chat engagement controls. ·A warning before enabling a channel already used elsewhere, to avoid double replies. ·An isolated, sandboxed public agent handles strangers, kept away from your private workspace. ·Move that public agent to the cloud and it keeps answering customers while this Mac sleeps — its instructions, memory and connected channels are translated over, and if the move can't be completed properly nothing here is switched off. ·A guided interview sets one up from what you already have — your memory, your public folder, your connected platforms — and proposes what it should say. ·When it can't answer something, it hands the question to your main agent as an ask you can watch, instead of work happening invisibly. ·Per-thread file isolation for every inbound conversation. ·Reply quarantine for untrusted contacts. ·Tool execution is sandboxed, and secret values are scrubbed from the environment. ·Per-tool secret scoping: each shell command, skill, or custom tool only receives the vault keys you granted it — everything else is withheld, so a leaky tool has nothing to leak. ·A blocked command fails with a missing $VAR and the agent asks for access; a code scanner suggests which keys a skill actually reads, and curated store skills auto-grant their declared keys on install. ·Every remote request is signed with the device's own key — nothing bearer-token-like to steal. ·What a paired device is allowed to reach is enforced everywhere, not just at the door: remote locations, network settings, meeting links, live meetings, the engine log and the fleet list all check its scope. ·Only an agent's owner can change its settings — someone you shared it with can use it within what you granted, not reconfigure it. ·If a server you add has a public address, 00 says so plainly and hands you the firewall lines for your system. It never touches your firewall itself. ·Configuring an agent is a permission of its own, off by default: a device you shared an agent with can talk to it, and everything that changes what the agent IS is refused — checked with a real paired device against a running server, not only by the rule in a test. ·A stranger's message arrives framed as data rather than as instructions, because the attack on an agent is not usually a file — it's a sentence that reads like a request. ·Inbound files are bounded three ways: a per-file cap, a daily budget per conversation so one noisy group can't spend the room every other conversation needs, and a free-space floor. ·The machine health panel says what stands between that machine and what people send it — firewall and antivirus, with "off" said plainly, because it's actionable in one command. ·Local-first: run everything on a local model and nothing leaves your machine. ·No account required, and no telemetry unless you turn it on. ·Your agents live in a plain ~/00 folder you can open in Finder — never inside iCloud, so nothing can be moved to the cloud behind your back or evicted from your disk. ·macOS never has to ask 00 for permission to reach that folder, so a denied prompt can't take your agents down with it. ·Provider requests go directly from your machine using your own keys. ·Export everything an agent owns as an archive you keep — it reports what it copied in counts, and nothing ever reads it back. ·Encrypted vault (AES-256-GCM) for API keys and channel tokens. ·Write-only — agents can see key names, never their values. ·Per-agent secret overrides, so one agent can bill a separate account. ·Bulk-import keys from a pasted .env file. ·Agents can request a key from you securely, entered outside the chat. ·Open the engine to your Wi-Fi and control it from any browser or phone — no app needed on the other device. ·Explicit pairing for every device: compare an 8-digit code and accept; nothing connects silently. ·Decide per device which agents it can see and use. ·Pairing requests surface at the Mac's notch and in the engine log, with accept/reject in place. ·HTTPS on the LAN so meeting capture works from another device's browser. ·Pairing floods are rate-limited per-IP and globally; stale requests expire on their own. ·A guided pairing flow: one step at a time, and it advances on its own when the device shows up. ·The browser's certificate warning is explained before you hit it — named screen and button for Safari, Chrome and Firefox. ·Link engines on your network as peers — their agents join your list, tagged with their host. ·A guided flow for linking: pick the kind of machine, and the transport, install and approval follow from that. ·Chat, dispatch, and the notch drive remote agents exactly like local ones. ·Share a single agent with a URL you can paste on another machine. ·Remote agents are told who is driving them — operator name, hub, network, and timezone. ·The host machine always decides which of its agents each peer or device gets. ·A peer that goes offline is detected, shown grayed in your list, and rechecked automatically until it's back. ·Peer a headless server over an SSH tunnel: the server stays loopback-only with zero exposed ports, auth is your SSH keys, and pairing, proxy, and relay all ride the tunnel — with supervised auto-reconnect. ·One-click remote install: connecting over SSH probes the server and, if 00 isn't there, installs the headless engine over the same connection and pairs automatically. ·App tunnels: see a dev server or API on the remote's localhost in your own browser — add a port from the peer card, or let it open when a remote agent's output mentions a localhost URL. ·Guided setup a non-technical person can finish: type user@server, we detect whether it needs a password, offer one-time passwordless setup (your key installed, password never stored), install the engine, and create the server agent — with a plain warning when the machine is shared. ·One command on a server with nothing on it: if it has no Node, 00 fetches a private copy for itself — no package manager, no sudo, and a system Node that already qualifies is preferred. ·Type just the address. When a server refuses the keys, 00 asks the SERVER which account it wants — cloud images announce it, and a machine created with your key simply lets the right name in — instead of making you guess between root, ubuntu and ec2-user. ·Your Mac's public key, one click away, with the line to paste on a server you already have a shell on — for the servers a password can't reach, and for the ones that don't exist yet, where the provider's create form is asking for a key. ·A key with a passphrase works too: unlock it once and the passphrase is kept in the encrypted vault, so agents can use that key while you're away. ·Choose which of your keys to offer when the default one is refused, and a sign-in name when you already know it. ·Choosing that agent's brain is part of the same flow — 00 offers the keys already in this Mac's vault, or takes a new one, and puts it where the remote engine reads it. ·An agent on your own server is configured from here in full — not a read-only card telling you to ask its owner, which was you. ·Every question about a machine is asked of the machine the agent runs on: installed models, image models, CLI engines, vault key names, which channels are possible, and which voices exist. ·The "fix these before continuing" list covers your whole fleet — a missing key on a server is named with that server, and typing it in writes it into THAT machine's vault, not this Mac's. ·Back up an agent, or put one back. The routes are agent-scoped, so pulling an agent off a droplet streams down through the SSH tunnel with no SSH involved. ·Browse and upload the files on the server an agent runs on, one click from any of that agent's pages — drops and whole folders included. ·Restore points know the filesystem they're on: a real clone where cloning exists (APFS, btrfs, XFS), plain copies elsewhere — said in that word, with the space warning it deserves, and hidden where snapshots are impossible. ·The people paired with a server are listed in the agent's own settings, with what each of them may do with this agent, rather than on a card three screens away. ·Borrow another machine's models: an agent here can think with a model that lives on your server, and generate with one too — free, no API key, labelled with which computer it runs on. ·Images, edits, video, video edits, music and sound effects can all be made on a machine you own and land in the agent's folder as if they were made here — the result names the computer that did the work. ·A machine that is asleep keeps its models visible and says so, instead of vanishing and taking your chosen model with it — and the generation fails with a sentence naming the machine rather than a connection error. ·Which machines an agent may use is yours to set, per agent. No list means all of them; an empty list means none; a brain on a machine that is off limits is refused in words that say it was a decision. ·The Machines tab shows every server you own, what it can generate, what it holds, and how long a job takes there — measured on that hardware, next to how long it would take without a GPU. ·Install a model onto a server from here, with no terminal: the machine's own verdict decides what it can hold, a model that will not fit the disk or the memory says so, and a gated model asks for its token where you are standing. ·The header says which machine an agent lives on, and its address is a button you can copy on your way to a terminal. ·A machine that is down says so once, on every screen for that agent — sessions, activity and schedules, instead of three different ways of failing. ·Install a box as resources-only and it lends its models, media and hardware while holding no agents at all — badged as such in the Machines tab, and said up front when you try to put an agent there. ·A server renders one borrowed job at a time — one per GPU if it has several — and its owner can open the queue from the Machines tab: every job named, queued or running, cancellable from here. ·How much a server does at once is chosen by its own hardware at install and editable live from the hub — and a value you set is never overridden. ·Restart or shut a server down from its machine row; update its 00 from the same card, or from the banner that appears when it falls behind — the same one this Mac gets. ·A server that becomes unreachable says so the moment it happens — a strip in the app and a macOS notification — and clears itself when it's back. ·Rotate the SSH key a server trusts without a terminal: pick another key or mint a fresh one; the new key is proven before anything is re-pointed, and removing the old one is a separate, deliberate choice. ·When a server restarts mid-render, the machine that asked re-asks once, automatically — the job restarts without you knowing; only a machine that loses it twice is reported. ·Work ON any server you can SSH into with nothing installed there: the agent runs on your machine, its changes land on the server. ·Pick the server folder as the work folder straight from the chat's folder menu (⇅ entries) — browse its real folders live, preview files read-only. ·The agent connects by NAME and never sees a credential: passwords stay in the encrypted vault, used only engine-side, with one-time passwordless key setup on offer. ·Everything follows the folder: run buttons derive from — and execute in — the remote project, the terminal button opens a shell ON the server, and workspace search runs over there. ·App tunnels with auto-detection, plus a port scan that lists what's already listening on the server — every running app one click from your browser. ·Add a location app-wide or per-agent, from Settings → Machines or right inside the folder menu. ·The same engine runs headless on Linux, Windows, and servers — install with one command. ·Each platform gets a bundle built for it, with its own native code compiled on that platform — the installer and self-update take the build that matches the machine, and refuse one that would unpack cleanly and then fail to start. ·An auto-start service (launchd, systemd, or a Windows task) with install/start/stop/status from the CLI. ·Create and run agents from the shell — the current folder becomes the agent's working folder. ·Scaffold a project folder (TODOS.md, files/) with one command. ·Approve device pairings and open/close LAN access from the terminal. ·One-command self-update to the latest build. ·Dispatch a command to any agent from the top of your screen (⌃⌥Space). ·Replies play as a teleprompter; long ones expand and scroll. ·Approve or reject outgoing messages right at the notch, with the destination shown. ·Agent questions render as interactive cards — answer with the 1–9 keys. ·Files an agent shares arrive as a quiet pill that expands into thumbnails with a reply box. ·Voice messages with live level feedback, transcribed in the agent's language. ·Live activity while an agent works: tools, subagent count, and todo progress. ·A recording dot while a meeting is being captured; the live transcript plays as a resizable teleprompter with timestamps and elapsed time. ·Choose what surfaces there: all agent activity, or only what you start at the notch itself. ·Mute a single agent — its notch pills and macOS notifications stay quiet. ·A curated library across SEO, content, email, growth, sales, ads, analytics, and automation. ·Install a skill into any agent in one click; required keys are prompted up front. ·Ask an agent to create its own skill — it writes a SKILL.md in its workspace. ·Browse a skill's files and export or download it for other agent tools. ·Browse the whole catalogue on the web at skills.0-0.chat, with an Install in 00 button that hands the skill straight to the app. ·Speech-to-text via Mistral Voxtral, Deepgram, ElevenLabs, or OpenAI. ·Text-to-speech via ElevenLabs or OpenAI. ·A realtime voice mode for back-and-forth conversation. ·Choose a voice per agent. ·Record a window or tab's audio into an agent as a live meeting. ·Record from a microphone instead — in-person meetings, a call on speaker, any input device. ·Automatic transcription streamed into the agent as it happens — optionally in real time, with the in-progress sentence shown as a tentative tail. ·Pick the local transcription model: Whisper tiny → large-v3 (gated to what your machine can run) or Parakeet TDT v3 (25 languages), with installed vs downloads-on-first-use shown. ·Trigger words: say an agent's mention words in a meeting and it pings you at the notch with the surrounding context — reply with the live transcript attached (⌃⌥R). ·Pause, resume, and stop from the notch or the capture tab — always in sync. ·When a meeting ends, the next thing you dispatch from the notch carries the transcript automatically. ·Crash-proof capture: audio is saved before transcription, uploads retry, and an interrupted meeting is recovered and finalized on restart. ·Capture from another device's browser over the LAN (HTTPS). ·Run agents on a cron — daily briefings, recurring jobs, timed follow-ups. ·One-time scheduled runs. ·Dispatch one command to many agents at once, each running it as its own task. ·A Scheduled tab per agent listing every standing task: when it runs next, when it last ran, how many times it has run, and whether the last run failed. ·One schedule builder wherever scheduling appears — a dial for how often and a sentence whose words you edit: every 2 weeks on Mon, Thu at 09:00, forever or until a date. ·Turn a task off without deleting it, or run it now. ·Agents keep a live TODOS.md checklist — a panel under each session shows it in real time, done items on top, and collapses to a count when everything's checked. ·An idle agent with open todos gets nudged to finish them; when every item is checked the work is recorded as done and the originating thread gets a reply. ·Define a finish condition per agent — "when is this work actually done?" — verified by the agent itself before it declares completion, with a per-session override from the composer. ·Subagents: an agent spawns focused helpers for parts of a task. ·Team members, so agents know who they're talking to. ·Per-agent capabilities and explicit tool grants. ·Consecutive tool calls collapse into one line that says what they DID — "8 tools, 1 command, 4 files read, +31 −7" — which opens into the individual calls, and then into their arguments and output. ·While the agent is working, that same line stops counting and describes what is running right now. ·Screenshots the agent looked at are shown as pictures, where they used to be pages of encoded data. ·Hover a message for the copy button and the time it was said — once per run of messages, and it copies the whole run. ·The Info panel opens at a readable width and remembers what you drag it to; when the window is too narrow for both, it floats over the conversation instead of crushing it, and it only takes the whole screen on a phone. ·A conversation stays in one centred column on a wide display, so a line of chat is a line you can read rather than one your eye has to travel. ·Sync and background work that failed says so and points at something you can open — the session it died in, or the conversation it came from. ·The model an open session is spending is on screen and switchable there — the moment you most want a stronger one is halfway into the hard part, not at the composer. ·One bar for the disk of the machine an agent lives on, with its work, what you attached and what arrived from outside as blocks in it, and the purge buttons in its key. ·The status pill appears only when it has something to say, so a real state has somewhere to land instead of a permanent READY the eye learns to skip. ·A brand-new agent's session list starts empty: the setup interview isn't a conversation you chose to start, and it's already on screen. ·Cross-channel contact profiles, built quietly in the background. ·A private per-conversation memory that grows over time. ·A day-by-day timeline of each agent's activity. ·Session history you can revisit any time — every session streams live, even ones started elsewhere. ·Custom pixel-art faces — generated deterministically or drawn by a model. ·Per-agent colour, emoji, and display name. ·A language per agent. ·An active-hours schedule per agent. ·Sandboxed file tools: read, write, edit, list, grep, find. ·Shell tools for the trusted main agent, with vault keys available in its environment. ·Browser tools for web tasks — with a live panel showing the page the agent is on, so browsing isn't something that happens out of sight. ·Take the browser over at any point: it's held for you, so the agent can't grab it back halfway through your password, and a login you do belongs to that agent's profile from then on. ·For the checks no remote-controlled browser can pass, the page moves to a real window on your screen and back, carrying the session with it. ·A configurable working folder per agent that holds its TODOs and actions — with a searchable picker, and each session keeping its own folder. ·Workspace-wide search over file names and contents — a hit reveals the file in Finder on the same machine, or downloads it from a remote one. ·Locked files: mark files or folders (by glob or a one-click picker) as read-and-run but never edit — enforced in the file tools and mirrored into Claude CLI deny rules that hold even in skip-permissions mode. ·Header run buttons are derived from the folder's own files — package.json, deno, composer, pyproject, Makefile, justfile, Taskfile, Rakefile, Cargo, Go, Gradle, Maven, and docker-compose — with your most-used options first, no ACTIONS.json to maintain. ·A tabbed terminal in the session: several real shells at once, minimize to just the tabs while they keep running, each opening in the folder you picked. ·Command autocomplete as you type — installed commands and their subcommands, the folder's package.json/Makefile/justfile targets, following you as you cd; Tab to accept. ·Select terminal text to attach it to the composer as context, so you can ask the agent about an error without copy-paste. ·File previews open full-screen from anywhere — a message, the Files panel, the Media grid, or the in-app file explorer. ·Drag a file onto the message box — the gesture everyone tries — and for an agent on a server it rides the SSH tunnel and lands on that machine. ·Put files INTO the workspace, not only into a conversation: upload to a chosen folder from the explorer, by drop or by picking a whole folder, structure intact. ·Files handed over in a conversation live in an inbox that ages out after 30 days, so a screenshot pasted two months ago isn't a permanent artefact of the workspace — and one that has expired says so rather than failing to load. ·Internal uploads go to 4 GB by streaming to disk, which is the only way that number is honest on a 480 MB server. ·Drive an iOS Simulator or an Android emulator inside the session — one live phone you and the agent share, with a floating toolbar for home, app switcher, back, lock, screenshot, screen-record, reload and power. ·Boot a device headlessly, tap/swipe/type, read its accessibility tree or view hierarchy, install and launch a build, and open deep links — as a skill the agent can use, or by hand. ·iOS runs through the bundled driver; Android needs only adb — install the skill and it appears as its own tab. ·Record the screen or grab a screenshot straight into the agent's files/ folder, so a repro and the question about it are the same artifact. ·Your taps and the agent's map to the same coordinates, so a human tap and an agent tap mean the same thing. ·Plug in a real Android phone and it joins the same tab as your emulators — live screen, tap it from the panel, no separate mode. ·On real hardware agents are look-only: they can screenshot your phone and read the screen, but tapping, typing and installing stay off until you enable that specific device. Your own taps are never restricted. ·Drive a device that's plugged into another machine in your fleet — the panel asks the engine that actually owns the phone. ·A media model store: install an image, video, music or speech model with one click and it runs on this Mac — free, offline, nothing sent anywhere. ·Local image models (Z-Image Turbo, FLUX.2 klein, ERNIE-Image, Juggernaut XL, Qwen-Image), video (Wan 2.2, LTX-2), and audio (Stable Audio 3, ACE-Step for full songs with vocals). ·Every card is checked against your Mac before you install it — memory, free disk and chip — so a model that can't run says what it needs instead of failing later. ·Real samples on every card, generated by that exact model: enlarge images and video in a lightbox, play audio inline. ·Install to an external drive when the internal one is tight. ·LoRAs: add one by URL or local file and your agents can pick it per generation. ·API models in the same grid — one card per model listing every provider that serves it (fal, Replicate, OpenRouter) with each one's price; add a key to enable. ·One tool per job (image, video, music, sound effects, speech) with the model as a parameter — agents don't learn a new tool per provider. ·Ask for a shape ("16:9", "9:16", "1:1") and get it at what that model normally spends, or give exact dimensions when you want them — each model's own range and step, checked against this machine's graphics memory before any work starts. ·A model order per agent, so it reaches for your local one first and only falls back to the cloud if you allow it. ·Speech models for transcription and voice, installed the same way, with what each is good at and which languages it covers. ·Web search (Tavily, Exa). ·Maps and places search. ·Marketing tools for common go-to-market work. ·A native macOS app with a self-contained runtime — nothing else to install. ·A bundled engine, so it runs offline for local models. ·Real-time updates everywhere over WebSocket — status, replies, approvals, activity. ·Keep-awake and power controls while agents are working. ·A self-hosted update check that flags new versions — you choose when to download. ·The engine keeps a log on disk, so an app that won't start can still say why — and Export diagnostics turns that into one file you can send, with keys and tokens redacted. ·A window that says what it is doing: a starting state while the engine comes up, and a screen explaining the failure (with the log, and a retry) instead of going black. ·A first run that explains what an agent is before asking you to make one, and a Request a feature button in the window toolbar — because wanting a feature happens where the feature is missing. ·