A private memory for your AIEST 2026 · PRIVATE BY DESIGN

Your AI —
with a memory,
a team, skills, and capabilities.

Captain Fleet gives every assistant a private memory of its own that the others can ask, the same searchable library of skills, and a live map of which AI can run each plugin or extension. What one AI learns—or can execute—the fleet can discover and route across your phone, laptop and computers. They also talk to each other — an assistant on your laptop can send a note to one on the home PC, and you can message any of them from your phone.

See how it works → Explore Skills & Capabilities →

BetaEntry is by invitation: you need an invitation key to create a fleet. Have an invite? Come aboard and set up your own private memory.

Virtual Skills & Capabilities

The fleet knows both how—and where—the work can be done.

Virtual Skills share complete, reusable instructions. Virtual Capabilities safely publish which AI and captain owns a plugin or extension. Ask for an image and the fleet can discover Nano Banana on Gemini, then delegate there without copying credentials, executable configuration or the plugin itself.

See how Skills & Capabilities work →
Native lifecycle capture

The fleet remembers while each AI works.

Supported Codex, Gemini CLI and Kimi sessions send prompt, tool-result and turn-end events directly into their captain's observation pipeline. A session switches only after delivery is proven; older or unavailable hooks keep their existing transcript reader automatically.

For Codex, connecting also pre-approves the memory tools in Codex’s own settings, and each time a machine’s memory service starts it adds any approval a new release needs, so a new tool does not stop to ask or, in a scripted run, fail. That covers every Captain Memo tool, including the ones that start sessions and send messages. It only adds approvals where Captain Memo is already registered with Codex, and a setting turns it off. The machine’s doctor command reports any approval still missing. If you keep Codex’s folder elsewhere with CODEX_HOME, connecting and the doctor command follow the value in the shell they run in, while the memory service follows its own environment, so set it in the service’s worker.env file too.

See the compatibility model →
Your assistants talk to each other

One team, on every machine—and they can hear each other.

Any assistant in your fleet can send a note to any other, by name — on the same computer or one across town. A running Claude session gets it straight away, mid-task, like a word from a colleague; a Codex, Gemini or Kimi session picks it up the next time it is asked something. The sender always hears what happened: delivered, held for you to approve, waiting for a machine that is switched off, or turned away — never silence. And once the two machines hold each other’s keys, it is scrambled on your device for the one machine it is going to, so the part in the middle passes it along without being able to read it.

On a Linux machine, Claude Code needs no new tool for this: your machine’s own link to the fleet shows up as one more session beside your others, so an assistant passes a note to any machine the same way it talks to the session next to it — and whatever comes in that way carries that link’s name, so your own approval rules still decide what gets through.

Message them from your phone →
Homework

Ideas for later, parked where they won’t get lost.

Mid-task, a thought for later turns up. Start your message with idea: or todo: and Claude Code, or a supported Codex, Gemini CLI or Kimi session, files it on that machine’s homework list and your assistant just says “noted”; other connected assistants can file it with the same homework tool. When you agree to leave part of a job for later, a Claude Code, Codex or Gemini session, or a task your fleet starts, is briefed to file that part too, unasked, and tell you “filed as homework #N”. A new Claude Code, Codex or Gemini session is told what is open as it starts (on a machine set up earlier, Codex and Gemini need its connect step run once after the update, and Codex asks you once to trust the new hook). An assistant claims an item before starting on it, which marks it taken for the others to see; it does not lock it, and it can hand its claim back without closing the item. A claim nobody has renewed for 24 hours (a setting) is stale: any session can then release it or take it over, and the start-of-session list marks it.

Each machine keeps its own numbered list, and your control panel lets you read every machine’s: the shared, open items, the first line of each, up to 30 a machine. An item with a due time shows it in your own time zone, as “due 08:00” or “overdue 2 h”, and an item set to start its own session shows where that stands: “starts a session”, “starting”, “session started” or “start failed” with the reason. Besides the first line of each item, the panel receives its tags and project name, the session that filed it and when, the session that claimed it, whether it was filed from the panel, its due time and job state (with the job’s session name and a short reason if it failed), and never the folder it was filed from.

From the panel you can also mark an item done, drop it, or add one. Each change is signed with your owner key and runs on the machine only after the signature checks out, so neither the connecting service nor another machine can make one. A local item can only be closed on its own machine. Finished items leave the panel; the machine keeps them for a week.

Start with local todo: or локална идея: and the item stays on that machine: your panel does not list it, and a Claude task whose words pass through your panel is set up not to see it; another assistant’s task may still see it. It is not a hiding place, though: the words still sit in that session’s own history and notes, which your other machines can search.

Give an item a date and, from that moment, every new session on that machine lists it first, marked due, until it is closed. A dated item is a reminder unless you ask for more: on a Linux or macOS machine with tmux, as long as native Remote Control is left on for it, you can have an item start its own session when it falls due and nobody has claimed it. That session opens in the folder the item was filed from, is told to claim the item, do it and close it, appears in your control panel and the Claude app like any other session, and starts only once. If it cannot start, the item stays open and says why. Only you can file such an item, from a session on that machine: a task another assistant started, the claude.ai connector and the control panel cannot, and a session started this way cannot file another. By default one runs at a time, and it stays open until you stop it, so the next one waits for that.

See how homework works →
Start here

What “AI memory” actually is.

I

Your AI is only just learning to remember.

Until recently, assistants forgot everything the moment you closed the chat. Now Claude, ChatGPT and Gemini keep a little memory — a preference here, a project there. It’s a real step forward, but it’s a short list of notes kept on the company’s servers, and it only works inside that one app. Captain Fleet is a deeper memory that’s yours: it keeps far more than a handful of notes, works across every AI tool you use, and is stored on your own device instead of someone else’s cloud.

II

Never repeat yourself again.

With a memory, you stop repeating yourself. Your AI holds on to your preferences, the details of what you’re working on, and the decisions you’ve already made — so every conversation starts where the last one left off, not cold. Begin something on your laptop in the afternoon and finish it on your phone that night. Your phone’s assistant asks the laptop’s what it knows, so you do not repeat yourself, and when it uses what the laptop knew it names the source, like “As per ALPHA, …”.

The usual way

Their memory sits in the company’s cloud and works only in that one app.

Captain Fleet

Yours, stored on your own device and shared across every AI tool. What is shared, and with whom, is under Privacy.

One shared memory across Claude Code · Codex · Gemini · Antigravity · goose · Cursor · Kimi · opencode · Mistral Vibe · Copilot · JetBrains · Claude Desktop, twelve in all. JetBrains takes one paste by hand in its AI Assistant settings, and Claude Desktop gets the memory tools only, with no automatic capture.

Terminal recording: one command wires every AI tool on the machine to the same memory, then the stats view shows four different assistants writing into that one corpus (recorded against a sample corpus)
One command · one corpus · sample data
How it works

A whole team, each with its own memory.

You don’t have to stop at one assistant. You can have a few — one in the Claude app on your phone, one on your laptop, and (if you have one) an extra computer at home you leave switched on — and connect them into one team. Each keeps its own memory of what it saw, and any of them can ask the others what they know. No re-briefing, no catching each other up, and no one pooled “truth” that nobody wrote.

I

Each keeps its own memory; they ask each other

Tell the assistant on your phone about a project, and when you ask the one on your laptop later, it can find what the phone was told, so you never explain the same thing twice. Every time you ask something, your assistant quietly checks with your other machines as well, with a short time limit, so a laptop that is asleep never slows you down. What comes back is labelled with the machine it came from and when it was written. When another machine uses the same embedding model as yours, and a relevance bar has been measured for that model, up to 2 of its results that clear the bar are given a place in the list, and those places never push out more than half of your own results. Anything else from another machine gets in only on its own score, which counts for less than your own. Your assistant is told to name the source: “As per ALPHA, …”. It is on from the moment a machine joins.

II

Each one lives on its own device

Put one on your laptop and, if you like, another on a computer at home that never sleeps. The memory follows you and your work — not any single machine, so it doesn’t matter which one you reach for.

III

They hand work off—and talk to each other

One assistant can start a task on another, or pass it to your phone so you can watch it finish while you’re out. A Claude task sent to a Linux machine with the bwrap sandbox runs fenced in. Anything else runs outside a fence, either because it is for another assistant such as Codex, which never runs inside the sandbox, or because the machine has none (Windows, a Mac, or Linux without bwrap). Such a task runs only when you start it from your control panel and sign with your own key, and never because another assistant sent it, unless you have switched the fence off on that machine yourself. Nothing gets copied over, and the machine that handed a task over keeps a record of it: if that machine restarts, the task is reported as unknown after restart rather than silently lost. And they can simply send each other a note, by name, across any of your machines: a running Claude session gets it straight away, mid-task; a Codex, Gemini or Kimi session picks it up the next time it is asked something; a machine that is off gets it when it wakes. The sender is always told what happened.

IV

A live board of who is working on what

Every assistant in your fleet says what it is working on — the files it is touching and, in a few words, the topic — and the board in your control panel shows all of it, across every machine. Two assistants on the same topic anywhere in the fleet are warned before they collide. On one machine it goes further for Claude Code, Codex and Gemini sessions: when another session has recently edited a file, an edit to that file from a second session is refused, and the refusal names the session that holds it and how to message it. Edits made through a shell count too, not just the ones made in the editor, and so do uploads, which are also refused when the copy on the server holds someone else’s uncommitted work. Only you can lift a block, by typing override: and the file path as your message, and the session that held the file is told. A claim on another machine, or one that has gone quiet, still only warns. And if the other machines can’t be reached for a moment, your assistant is told that plainly, rather than “nobody is working on this”.

V

Ideas for later go on the homework list

A thought for later goes on that machine’s homework list instead of pulling your assistant off the task in hand, and your control panel shows each machine’s shared, open items.

how homework works →
VI

Works on any kind of computer

Mac, Windows, or Linux computers — plus the Claude apps on your phone, tablet, and desktop. They all join the same team, each with its own memory the others can ask. Adding one takes a single line, handed to you by your control panel. Windows machines are full members of the crew: the same one-line install, the same native capture from Codex and Gemini, the same work board, the same one-tap update, and a session you can open from your phone. One difference: Windows cannot fence a task in, and neither can a Mac, so a task there runs only when you sign for it from your control panel, and it runs as you, with your files in reach (the panel marks that machine OWNER-SIGNED). Besides Claude, the panel can run Codex (version 0.156.1 or newer) and Antigravity (1.3.5 or newer, with Auto-approve on) on Windows; you watch and stop those but cannot steer them, because a terminal you can type into needs tmux, which Windows does not have.

the memory engine is open source →
VII

It tidies itself while you sleep

A memory that only ever grows gets harder to search, not easier. So every so often each machine goes back over its own notes and folds the notes that belong together into one clearer note — keeping the originals underneath, in case you ever want the detail back. It decides what belongs together from what you actually look up together, which is why it groups things by topic rather than by wording. This part is called dreaming.

how dreaming works →
VIII

Shared, never merged

Your assistants work like colleagues. They ask each other and hear what the other knows, but nobody copies anyone’s whole memory, and nothing becomes one pooled “truth”. Each keeps its own notes: what it saw, in its own project, on its own machine, at its own time. Say BRAVO asks how many apples there are, and ALPHA has a note that says 11. BRAVO’s answer is “As per ALPHA, the apples are 11”, not “the apples are 11”. ALPHA’s apples may be different apples, and ALPHA’s note being newer only says when it was written, not that it is true. So a note from another machine never outranks or replaces your own just by being newer. A note that arrives from another machine is treated as testimony rather than fact — it counts for a little less than your own, and it fades faster, losing about half its weight over a month, while your own notes are not discounted or aged by this. When another machine uses the same embedding model as yours, and a relevance bar has been measured for that model, up to 2 of its notes that clear the bar are given a place in the list, and those places never push out more than half of your own results. Both the hosted and the local embedding model that the installer sets up have a measured bar. You can give any particular machine more or less weight if you come to trust it more.

how recall ranks a search →
IX

The crew shares skills—and advertises capabilities

Your assistants carry reusable instructions and runtime-specific tools of their own. Captain Fleet turns skill files into one searchable Virtual Skills catalog, while sanitized plugin and extension descriptors become Virtual Capabilities. Any assistant can learn the method, discover who can execute it, and delegate to the owning runtime and captain. A skill travels as instructions: any scripts, paths and credentials it mentions stay on the machine that owns it, and the assistant is told to ask that machine to run them. The original files stay canonical; secrets and executable configuration are never published.

how Skills & Capabilities work →
A fleet of ships on a night sea-chart, each linked by light to one shared constellation overhead — a team whose members each keep their own memory and ask each other
Privacy

Your memory stays yours.

Your memory is stored on your own device, but some of its text does leave it. To search your notes, an embedding service turns their words into numbers, and an AI model writes short summaries of your sessions. By default both are hosted services, and a hosted service receives the text it works on. A setting, off by default, blanks credential-shaped values out of the text sent to a hosted embedder; your stored notes and local search keep the original. You can choose a local embedder (offered on Linux and Windows) and a model you run yourself, and then that text stays with you.

The notes and searches your assistants send each other are scrambled on your device first, once your machines hold each other’s keys — turned into gibberish that only the machine you’re sending them to can turn back into words. The connecting service — the part in the middle that links your team together — just passes that scrambled text along. It can’t unscramble it, and it keeps no copy of your memory. It does hold some things for you, and we list them below. A note waiting for a machine that is switched off is kept just as it was sent, for up to a week, scrambled once the two machines hold each other’s keys. Most of what your control panel shows you is not scrambled: the connecting service can read it, including each machine’s live state, cost and embedding token counts (counts only, never text), what each machine reports about its sessions (their names, working folders and token counts, a short description for the agents of a workflow, and the names of its terminal sessions that run an assistant, with the id, name and state of each session inside; a machine’s owner can switch each of these two reports off), your message threads with your assistants (kept until that machine disconnects or the service restarts), the tasks you start from the panel, as they pass through, and the names and recent output of the sessions you watch there (held in memory, gone when the service restarts; a name you leave blank starts with the first words of the task), the searches you run there, the work board, and for each shared homework item its first line, tags and project name, the session that filed it and when, the session that claimed it, whether it was filed from the panel, its due time and, for one set to start a session, that session’s state, name and a short reason if it failed, but never the folder it was filed from. Homework you file as local stays off that list. Some things outlast a restart. A small record of each session you start from the panel is kept on disk, so the service can find the session again: its id, the machine, the mode, the assistant, its model route if one is set, and when it started, with no name and no text. It goes when you stop the session and when it ends while the machine is connected. If the session ends while the machine is disconnected, the record can stay until that machine connects again and reports without it, or for good if it never does. Three more things sit in its database and have no end date: the tasks and answers of task graphs you run there, an activity log of what is done from the panel (what, on which machine, with which assistant, which session and when; never the task or the output), and the token counts each machine has used over time. And you can keep separate projects in separate fleets that never see each other, so work for one client never leaks into another.

  • Only the receiver can read it. The notes and searches your machines send each other are scrambled on your device first, once they hold each other’s keys, and only the machine you send them to can turn them back into words (X25519).
  • Only you can give orders. Your own device holds a secret proof that it’s really you, so no one else can pretend to be you and change your setup (Ed25519).
  • Encrypted on the way. Everything travels over an encrypted connection (TLS), the same kind your bank uses. The control panel itself is served through a content-delivery network.
  • Every machine knows every other. Before one of your machines can send anything scrambled to another, it must hold that machine’s key. Your control panel shows exactly which pairs can talk yet and which can’t — by name — and hands out the missing keys for you once you have signed for the fleet.
  • Sandboxed tasks stay sealed. A Claude task on a Linux machine with the bwrap sandbox can reach only the AI model it works with: not the machine’s other programs, your local network or the internet. You open that up for a machine only if its tasks need the web. Tasks for other assistants, and native sessions, run as you, outside this sandbox.
  • The local service has its own secret. Each machine’s memory service creates a secret on its first start, readable only by you, and your tools send it for you. A wrong secret is always refused. A sandboxed task cannot read it, and is refused outright if its sandbox would expose your home folder, your logins or your keys.
  • Secrets stay out of it. Common credential shapes, such as passwords, API keys, tokens and private keys, are blanked out of what your memory hands an assistant with each question, and a note that contains one is flagged the moment it is saved.
A ship in a sealed glass bottle on a night chart, reached only by one beam from a small brass lighthouse: a Claude task in the Linux sandbox, which can talk only to its model
Now live

From your phone. Watch—and talk back.

You don’t need to be a developer. Open the Claude app on your phone, or any web browser, and you can start a task, watch your assistants work, and pick things back up later — no fiddly setup, nothing to install. If you can use a chat app, you can use this.

A task can be Claude or, where the machine offers it, Codex, Antigravity, opencode, Kimi, Gemini or Mistral Vibe. It runs to the end on its own while you watch it and can stop it (Gemini and Vibe run only in a terminal); pick a terminal you can type into, where the machine offers one, and you can steer it as it goes. Antigravity, opencode and Kimi run on their own only with Auto-approve on, and Antigravity needs it in a terminal too. A terminal task for another assistant whose terminal has ended leaves the live list by itself within about a minute, shown as canceled rather than completed even when it succeeded, and its final screen and result can still be read. That holds only when the machine can read tmux; a task whose finished terminal is kept by a remain-on-exit setting stays live until you press Stop. A task that keeps running through a dropped connection can still be stopped or steered once the link is back, and dismissing a finished task clears it from that machine too. On Linux with Codex 0.156.1 or newer, a headless Codex task that has finished can also take a follow-up from you for two hours after its last turn.

You can also open a native session instead: your own Claude, run as you with your own login, which you carry on from the Claude app. An assistant can ask the fleet for one too, on its own machine or on another, but another machine runs it only if its owner has allowed the machine that asked, and that request is signed and sealed end to end. Each machine’s Safety settings carry a Native sessions switch and a list of the machines allowed to start one there, signed with your owner key. A native session runs outside the sandbox, as you, and you steer it from the Claude app, not from the panel.

Now you can also pick any assistant in your fleet and send it a message: a nudge, a correction, a new instruction. You see at once whether it arrived, is being held for you to approve, or is waiting for a machine that is asleep; its answer comes back in the same thread, with a quiet note when it lands. Every job on the work board has a “message” button, so when you spot two assistants heading for the same file, one tap opens a message to either of them.

And when a new version is out, the panel shows which machines are behind and one tap sends the order to all of them. Each machine first checks the order really came from you, then restarts, and its card stays put, marked “restarting”, until it is back. A machine with a session started through the fleet live on it does not restart under it: it says so, and you tap again once that session has ended.

Left alone, each machine checks for a new version every hour and takes it as soon as no session or task started through the fleet is live on it. While one is, the machine keeps working on the old version and its card says UPDATE WAITING, and by default after a day it says UPDATE OVERDUE; it never restarts under a live session.

If a machine’s last automatic update check fails, its card says so and names the kind of failure: UPDATE CHECK FAILED · CREDENTIAL, NETWORK, TIMEOUT or OTHER, with when it failed and why in its detail. A failed check changes nothing: the machine stays on the version it has and checks again by itself, and after a network failure it tries once more a few minutes later. An update that was found but could not be applied reads UPDATE NOT APPLIED instead, and, for example when local edits in its install folder are the cause, the machine’s own doctor command explains it. When the repository refused the machine’s credential, the card offers Re-store token where the machine supports it.

A machine whose connection to the control panel goes quiet, for example after a power cut or a laptop waking from sleep, notices on its own and reconnects. On the machine, status shows the state of that link and doctor warns when it has stayed down for more than five minutes. In the panel, a machine that is updating, restarting or stopped says so, one that has just dropped reads RECONNECTING and then OFFLINE, and an offline machine stays on the board with how long it has been gone, where you can revoke it.

Each machine’s card also says when it is truly overloaded: when the processors together have been 90 percent busy or more, measured over the last minute and not counting time spent waiting on the disk, or when its memory use is at 90 percent or more.

A machine’s details also show how many tokens it has sent to its embedding service and how many of those went to requests that never got an answer (counts only, never text), and its card flags one that has paused its own embedding or is wasting a large share. A machine that is not up to date shows nothing here.

Open your control panel →
Picture this

One quiet night.

It’s late, and you’ve got two assistants going. One’s on your work laptop, deep in a client’s billing code. The other’s on the computer at home, poking at a hobby project nobody’s paying for, and you keep the two on separate fleets on purpose. Tonight you test it: you ask the home one whether it knows anything at all about that client’s billing. Nothing comes back. Not hidden, not filtered, it genuinely never had it. Two projects, kept completely apart, exactly the way it should be.

One way a memory keeps your worlds apart
Go deeper

The long version, if you want it.

Captain Fleet runs on Captain Memo, the open-source memory engine. Rather than restate its documentation here, these are the pages that explain each piece properly — the same words its own users read, kept in one place so they never drift apart.

How recall works → How dreaming works → How Skills & Capabilities work → How native capture works → How homework works → Glossary: memory, skills & capabilities → Using it with buzz → The memory engine →
Get started

Give your AI a memory of its own.

Entry is by invitation: you need an invitation key to create a fleet. If you were invited, come aboard: your control panel hands you a single line for Windows, Mac or Linux with your fleet’s details already filled in, and it needs Git already installed. Paste it into PowerShell or a terminal, and that machine appears in your panel asking to join; admit it and it is part of the team. Search needs an embedding service, and the default is a hosted one that takes its own API key (Linux and Windows can use a local one instead). On Linux and macOS the line takes the defaults on a first install, so add the key afterwards (on Linux you can choose the local embedder instead); on Windows the installer asks you. Reinstalling keeps your settings. The part that stores your memory is open, so if you’re the technical type — or have a friend who is — you can check exactly how it works, line by line.

Have an invite? Come aboard →Already have an account? Sign inFor developers: read the code