A private runtime for personal AI.

The useful version of personal AI needs your life as context. It works best when it can see your inbox, your calendar, your files, and your history. The default way to ship that is to send all of it to a vendor's cloud and run the intelligence there.

That arrangement gets worse as the AI gets better. The more it can do for you, the more access it needs, and the more you are trusting a company's policy, staff, and breach history with the most personal data you have. A privacy policy is a promise that can change. We wanted a guarantee that comes from the architecture instead.

otherself.ai is not an app that calls a vendor's model. It is a runtime: a small piece of software that holds your memory, runs your tools, makes the model calls, and browses the web for you.

It runs as a single unit: on your own machine or server when you want full control, or on an instance we host when you would rather not run it yourself. Either way, your content lives inside that runtime and the work happens inside it, instead of scattered across a vendor's services.

The runtime is a handful of parts, each with a narrow job:

The cloud's job is deliberately small. It helps the two ends find each other and relays encrypted traffic between them. It coordinates. It does not read.

There are two ways to run otherself.ai, and we are precise about the difference because it is the whole point.

Managed is private by policy. We host the runtime so you can start in seconds with nothing to install. Here your privacy rests on policy and operational controls rather than cryptography. Your data is access-controlled and never sold. Beyond that, how it is handled, including whether it is ever used to improve our product, is governed by the terms of your plan and can differ from one to the next. When you want privacy that does not depend on trusting us at all, that is what the private runtime is for.

Private is private by design. You pair a runtime you control, and your content is decrypted only inside it. The cloud relays ciphertext and sees metadata: that a connection happened, when, and how much traffic moved, never what was in it. Your data is sealed with a key that is yours alone and never reaches us.

Private by design is the mode that earns the word without an asterisk. Your data is sealed on a runtime you control, unlocked by a master password day to day and a recovery code you keep somewhere safe. Because it lives on your own hardware, surviving a lost or damaged runtime works like anything else you own: keep a backup. You can do that yourself, and we plan to offer optional encrypted backups you can turn on, held only as ciphertext we cannot read and restored with your password or recovery code. What we cannot do, in any tier, is bring back data you kept no copy of, or unlock it once both the password and the recovery code are gone. The key is yours and we keep none. Control and a backdoor are the same feature, and we chose control.

When you pair a private runtime, the web app in your browser connects straight to it over an end-to-end encrypted channel. Your browser and your runtime hold the keys; the traffic between them is sealed. The cloud's job here is introduction and relay: it helps the two find each other and passes along encrypted packets it cannot open. It learns that a connection happened, not what crossed it.

There is one honest gap in that picture, and we would rather name it than hide it. The web app is code we serve to your browser, which means the interface could in principle read what you type before it is encrypted. Cryptography protects the transport. It does not protect the page that sits on top of it.

We close that gap two ways. The client is source-available, so you can host it yourself on a domain you control and trust nothing we serve. And for everyone else, we are building a source-available browser extension you can run that watches the app and confirms it only ever talks to your runtime, with nothing slipping out a side door. Verifiable should reach the page in front of you, not stop at the wire.

An assistant that can act is only safe if it knows where to stop. The runtime will read, plan, draft, and prepare freely. It stops before anything that touches the outside world: sending a message, booking, paying, posting, deleting, logging in. You approve it, edit it, or take over and do that part yourself.

Sensitive values follow the same rule. Card numbers, passwords, and one-time codes are entered by you and kept out of the runtime's logs and its activity history. The record of what it did never becomes a copy of your secrets.

Most privacy claims ask you to trust a sentence in a policy. We would rather the claim be checkable. otherself.ai is built to be source-available, and the line between what stays in your runtime and what may touch the cloud is defined by a manifest, not by our marketing.

That means the boundary is something you, or an engineer you trust, can read and verify, rather than a promise you take on faith. Trust should be the result of being able to check, not a substitute for it.

Verifying the code tells you what the runtime is allowed to do. Auditability tells you what it actually did. The runtime keeps a typed, ordered record of every step it takes: the tools it calls, what it reads, what it changes, and each point where it stopped to ask you. Nothing meaningful happens off the books.

That record is built to be read, not buried. Each entry is a plain statement of an action rather than a dump of raw internals, and the rule about secrets still holds: the log of what it did never contains your passwords, card numbers, or the private content it handled. You can confirm it booked the table without the audit trail becoming a copy of your inbox.

otherself.ai is the runtime, not the model. You decide which intelligence sits in the middle. Run a local model when privacy matters most and you are willing to trade some capability for it. Point at a hosted model when you want the strongest reasoning available. Switch whenever you like.

Your memory, your tools, and your approval rules stay constant across that choice. The model is a part you can replace, not a vendor you are married to.

Ownership you cannot exit is not ownership. You can export your data, and you can delete it for real. A delete writes a durable proof and then reserves your namespace permanently. We cannot bring it back, even from a backup, and we do not pretend we can.

The right to leave with everything, and to be sure that what you erased is gone, is part of the design rather than a support request.