Why q15

q15 is for one person who wants an agent they keep. Custody is the whole argument: the memory, the files, the jobs and the credentials stay where you can read them, and the machine keeps running when a vendor changes its mind.

Everything below is a claim you can test against the code, followed by its limit. None of it is a promise about how it will feel to use.

Four properties

1. Your memory is files you can open.

The transcript is JSON under /memory/history/, the extracted knowledge is markdown under /memory/semantic/, and the project tree is /workspace. Copy them, grep them, edit them, move them to another machine.

The limit: they are plaintext on your disk. Encrypt the disk, or encrypt the backups.

2. The credentials the agent reaches with are not in the agent.

The tokens for the hosts the agent calls through the shell are injected by q15-proxy at the network layer, for the hosts your policy names. The agent’s own environment does not carry them, so its prompt and its transcript have nothing to leak for those hosts.

The limit: two of them. The agent does hold the key for the model provider it calls, because it is the thing that calls the provider, and a hosted provider sees the prompt either way. And it can still use an injected credential by asking for a host the policy matches. Nothing to steal, plenty to abuse, so keep the policy narrow. See Credentials.

3. Chat bodies are sealed between the browser and the agent.

Every frame that carries content is encrypted per connection, with keys the browser and the agent derive and q15-web never sees. A carrier that copies your traffic gets ciphertext and frame sizes.

The limit: this is not end-to-end encryption from the edge. Whatever serves the browser’s JavaScript, or replaces the key exchange, is outside the guarantee. A TLS terminator still sees who connects, when, and how much.

4. Policy is enforced in code, not in the prompt.

Egress routing, file roots, the schedule tool’s limits and the web tier’s authorization are properties of the deployment. A prompt that asks to skip them is asking a process that does not have the option.

The limit: the model is not the only untrusted input. Anything the agent reads is untrusted, and the agent acts on it with the permissions the deployment gave it.

What q15 does not claim

• Not multi-user. One owner, one agent, no roles, no isolation between people.
• Not a sandbox against a hostile model. Commands run in a container, so they are off your host, but they can read every file under /workspace, /memory and /skills. That is your data.
• Not private from a hosted provider. Anything you send to a hosted model is in that provider’s hands.
• Not private from Telegram, if you enable that channel. Those messages travel through Telegram’s servers in the clear.
• Not audited. No third party has reviewed this code. It is one person’s project, and the security page describes what the design defends, not a certification.
• No push notifications. A closed browser tab hears nothing.
• No recovery password. Host access to the credential store is the only recovery path.
• No management console. The shipped web tier authorizes one scope: chat.
• Not finished, and not installable by a stranger yet. The installer is filed as work and not shipped; the documentation says so wherever it matters.

Who it is not for

Teams. Anyone who wants an account on someone else’s server. Anyone who needs prompts kept away from model providers without running local models. Anyone who wants install-and-forget.

If your case is one of those, this is the wrong tool, and it is better to find out here than on day three.

Where to go next

• Security for the threat model, and the class of attack the architecture is built around.
• Credentials for where secrets actually live and how they are injected.
• Architecture for the four services and the storage contract.
• Install q15 when you have decided.