Personal AI should run on your machine, be reachable through the messaging app you already use, improve itself nightly against tests it cannot cheat, and stay out of the cloud, including ours.

Almost every personal AI worth using in 2026 runs on someone else's computer. Your conversations, the most private self-facing text you produce in a given day, sit on their disks. They train models on it. They lose it to breaches. They change their terms of service on a Friday afternoon. Your memory of the last three years with the assistant belongs to them, not you.

Kwisai runs on a Linux server that you own. Your SQLite file lives on your disk. Conversations never leave your server except as prompts to the LLM you chose and configured. There is no phone-home. There is no shared analytics bucket. There is no maintainer dashboard where I can see what you asked it to do.

The LLM is your choice. Anthropic direct, OpenRouter, any OpenAI-compatible endpoint, or a local model running on your own hardware through Ollama. Fully offline is supported: point every agent at a local provider and nothing leaves your server.

If that sounds like alpha talk, read the code. About twelve thousand lines of TypeScript. Ten npm dependencies. Auditable in an afternoon.

Kwisai is not one agent. It is three, each with its own model, tool set, and filesystem permissions.

• Kwisai (default: Haiku 4.5). Quick answers, simple questions, status checks. 2,048 tokens per response. Read and write restricted to ~/.kwisai and /tmp.
• Builder (default: Sonnet 4.6). Implementation work: write code, fix bugs, deploy, configure, install. 64k tokens per response. Unrestricted read. Write scoped to the Kwisai workspace.
• Thinker (default: Opus 4.6). Research, investigation, analysis, comparison, planning. Extended thinking enabled. 64k tokens. Read-only: no write or edit tools are available to this agent, ever.

Every incoming message passes through a three-tier router before any agent sees it.

• Tier 1: regex on the message body. Zero milliseconds, zero cost. "Fix this bug" goes to Builder. "Analyze the tradeoffs" goes to Thinker. Handles the common case.
• Tier 2: semantic k-NN. About 50ms, zero cost. Typesense index of pre-seeded exemplar messages, queried by embedding similarity. Used when the regex is ambiguous.
• Tier 3: Haiku-based classifier. About 300ms, about $0.001 per call. Invoked only when Tier 1 and Tier 2 disagree. The router spends real money only on messages the cheap classifiers cannot resolve.

The router also gets smarter. A daily cron job reads the previous day's routing decisions, finds messages where Tier 3 answered with high confidence, and proposes them as new exemplars for Tier 2's semantic index. Approve the proposals manually, or set routeReviewAutoApply: true and let them merge automatically. Yesterday's Tier 3 calls become tomorrow's Tier 2 hits. The cheap path handles more of your traffic every day.

Each agent is independently configurable. Swap Kwisai's model for a local Llama on your GPU and keep Thinker on Opus for the hard questions. Point Builder at OpenRouter for cost and keep the rest direct with Anthropic. Add a fourth agent by dropping a JSON stanza into your config. The router will learn to route to it. Delete any of the three and the router adapts.

This is how a personal AI earns its cost. Ninety percent of what you ask is cheap, so ninety percent of what you ask should be answered cheap. One agent forced to handle everything either burns money on trivia or stutters on depth.

Nobody is going to install a seventh chat client. The personal AI you actually use is the one that reaches you in the messenger you check reflexively. OpenClaw got this right before anyone else. The correct answer was not a cleverer chat interface.

Kwisai is Signal-first. You message a Signal account that belongs to your Kwisai instance. Voice notes are transcribed locally on your server by Whisper before the agent ever sees them. End-to-end encryption on the wire; interpretation in your own process; plugin execution in a capability-scoped sandbox. The phone in your pocket becomes the front end for your private AI, and no one in the loop has ambient microphone access.

Future channels (WhatsApp, Matrix, Telegram) will arrive when someone wants them enough to contribute a plugin. The bar for the core gateway is that it stays honest about what it can and cannot do on each channel.

This is the section that turned "interesting project" into "I have to build this."

The personal AI that broke through in 2026 shipped a plugin system with no isolation at all. A skill you installed could read the host filesystem, reach any network endpoint, and touch any global in the Node.js process. It had the same authority as the gateway itself. The gateway, by design, sees your email, your calendar, your contacts, your messaging history, your API keys. The marketplace grew to thousands of skills on trust-the-developer assumptions. Nothing stopped a single compromised skill from pulling your entire life into an attacker's bucket.

Your detection window: zero.

OpenClaw documents this in its own repository. The plugin-architecture doc states it verbatim: "Native OpenClaw plugins run in-process with the Gateway. They are not sandboxed. A loaded native plugin has the same process-level trust boundary as core code." The project's own threat model rates skill-based exfiltration Critical.

A personal AI is not a game mod. Its attack surface is the concrete facts of your life: inbox, calendar, contacts, files, messaging, credentials. The blast radius of a single plugin can be your entire digital life (email, calendar, contacts, files, conversations, etc). And the risk scales linearly: every plugin you install raises the probability that at least one is malicious, buggy, or upstream-compromised. A more useful personal AI is, by definition, a bigger target.

I could not reconcile that shape. So I built a different one.

Three tiers of isolation, with a policy built around who wrote the code.

First-party plugins authored by the Kwisai team run in Tier 1 or Tier 2, chosen by what they need to do. Every third-party plugin runs in Tier 3 by default. You did not write it. You do not know the author. It ships untrusted, and it stays untrusted. You can force any plugin upward to Tier 3 in one line of config. You cannot force any plugin downward.

• Tier 1 (in-process). The plugin runs inside a frozen SES Compartment. Capabilities are injected: ctx.fetch, ctx.email.search, ctx.fs.read. Each is explicitly granted in the plugin manifest. Each is revocable in one command. What you have not granted, the plugin cannot call. Globals are frozen. Ambient authority (require, process, fs, net) does not exist from inside the compartment. Overhead: under a millisecond per call.
• Tier 2 (worker thread + SES). Separate V8 heap, its own memory budget, survives main-thread issues. Same capability-gate as Tier 1. Used for first-party plugins that need real CPU or memory (NLP, embeddings, data transforms). Overhead: two to five milliseconds per call.
• Tier 3 (child process + SES + bwrap + cgroups). OS-level process boundary. Filesystem namespace via bwrap mount isolation. Network namespace with opt-in connectivity only. Hard memory caps and CPU quota via cgroups. Per-plugin auth token. No gateway secrets in the child's environment. The default tier for every third-party plugin, and the tier you can force any first-party plugin into. Overhead: five to fifteen milliseconds per call.

SES runs inside all three tiers. It is additive, not alternative. A Tier 3 plugin runs inside a frozen SES Compartment inside a sandboxed child process inside its own cgroup.

Every capability request is visible in the plugin manifest before you install. Every plugin call is trace-correlated through the gateway's logs. Every grant is revocable in one command.

This is not novel cryptography. SES is the same primitive Salesforce uses to run third-party code in front of five million developers; the same primitive MetaMask used to detect the LavaMoat supply-chain attack in December 2023. bwrap and cgroups are boring, production-hardened Linux primitives. None of this is novel. All of it is missing from the other projects in this space.

The worst case for a compromised third-party skill in Kwisai is not "arbitrary code execution on your machine." It is "a process with a blocked filesystem, a blocked network, a capped memory budget, and a capability set you approved in writing."

This is the section I think almost everyone is getting wrong, and it is the reason Kwisai exists as a separate project rather than a fork of something that already shipped.

There are two dominant schools of thought on how a personal AI should learn:

• Ship a frozen model that never adapts to you. Retrain every six months by a team on the other side of the world. Hope they ship the right improvement.
• Let the model "learn" through an opaque RLHF-style loop that neither you nor the maintainer can audit, and which is indistinguishable from a regression until something breaks.

Both are bad. The first is a waste of the signal your daily use generates. The second is fine until it is catastrophic, and you will have no way to know which before it is too late.

Kwisai runs a scheduled job every night. It reads the last day's conversations, proposes specific code changes, and runs the proposal against a golden dataset of real past interactions. Six empirical dimensions are scored. If the composite is better, it merges. If it regresses, it reverts.

The six dimensions are cost per conversation, conversation quality, correction rate, error rate, action velocity, and recall precision. Each is measurable, each is observable to you, and every change shows up in git. You can veto the job, pause it, or replay it against a larger window.

This is the novel claim. I am not aware of another personal AI shipping this today. I think in two years it will be table stakes and I would like Kwisai to have been the first sharp version of it.

This is also the single most load-bearing part of the project. If the self-improvement loop produces regressions you cannot explain, the whole argument collapses. That is why every commit it generates is empirically validated before it lands, why the scores are public on the /open dashboard, and why the golden dataset, the substrate the loop is measured against, grows openly and adversarially.

Every cloud-hosted AI makes the same claim: your data is safe with us. No maintainer of a managed service, myself included, can honestly claim that your data is safer with them than with you. I am not going to make that claim.

Kwisai Cloud will exist because some people, reasonably, do not want to run Linux. If you use Kwisai Cloud your data lives on a dedicated EU instance I operate, running the same software I run on my own box. It is still my server. It is still my incident response. It is still my terms of service. I will do it well, and I will not pretend it is the same as running it yourself.

Two paths. Self-host is the right default for people who can. Kwisai Cloud is a trade: your privacy surface shrinks, and in exchange you get managed updates and no systemd to babysit. The comparison table on the homepage is honest about what moves and what does not.

On the license: Kwisai is BSL 1.1 with a narrow grant that permits non-commercial and internal commercial self-hosting, and prohibits third-party hosted resale. Each version converts to Apache 2.0 after two years. The license is a moat for Kwisai Cloud, not for you. If this structure feels wrong to you, I understand. You can still fork, study, contribute, and run your own.