Cytible uses third-party AI models, through their APIs, to reason over evidence, to index material for search, to read scanned pages and for speech. Answering your question means sending the model that question and the passages needed to answer it. This page is about what happens to that request afterwards: what Cytible asks the model provider to keep, and what Cytible keeps itself.
Everything stated here is enforced in code and described as it works today.
One checkpoint, not a rule to remember
Every request Cytible's servers send to a model provider leaves through a single checkpoint. It sits at the network boundary, underneath every feature, not inside each one. A feature does not have to opt in and cannot forget to: a request is checked because of where it is going, not because of which part of the product sent it.
What it does to every request
It refuses requests whose purpose is to keep data at the provider. Uploading files to a provider, creating stored assistants or conversation threads, building a document store there, batch jobs, fine-tuning a model, and stored conversations are all turned away. A refused request never leaves our servers.
It switches storage off. Each request tells the provider not to store the response. If a feature leaves that instruction out, the layer adds it. If a feature asks for storage, the layer overrides it. Options that only work when a provider holds on to a request, such as running it in the background or keeping a prompt cached for an extended period, are removed.
It removes end-user identifiers. The fields a provider offers for labelling a request with a user id, or for attaching tags to it, are stripped before the request is sent.
It records metadata only. For each request the layer logs which model was called, the size of the request, whether it succeeded and how long it took. It does not log the prompt, the response, or the text of an error.
What Cytible keeps
- The layer's own log: the metadata above, nothing else.
- A usage record: the model, the number of tokens and the cost of each call, against your organisation and your user, so that usage and cost can be accounted for.
- A run log for the built-in prompts: tokens, timing and success. Since this layer was introduced, new entries hold no prompt or response text. An operator can switch that text on for a debugging session; it is off by default.
- Your own work. Conversations, notes, reports and dossiers are saved in your workspace because they are yours. That is the product, not a log.
What this layer cannot decide
Read this part
The layer governs what Cytible asks a provider to do and what Cytible keeps. It cannot shorten what a provider holds on its own systems, for example for a limited period to monitor for abuse. That is set by the terms on the provider account, not by anything a request can say.
This page therefore claims only what the layer enforces. The provider-side terms will be stated here once they are confirmed in writing for every provider we use.
Two more limits, stated plainly:
- It is about retention, not about whether data is sent. The model is still given your question and the material retrieved to answer it. The layer does not read or change the wording of a prompt.
- It covers Cytible's servers. If you connect your own AI assistant to Cytible, what you retrieve is handed to that assistant and is then subject to that assistant's terms. Dictation that your browser performs itself is handled by your browser before anything reaches Cytible.
Voice
Spoken input that Cytible transcribes is sent from our servers as a recorded clip, through the layer. A live voice session would stream audio from your browser directly to the provider, around the checkpoint, so the layer refuses to start one.
How it is checked
- Automated tests send requests of every kind through the layer and inspect exactly what would have left: storage instructions, identifiers, refused endpoints, and the contents of the log.
- A second test fails when new code builds its own connection to a model provider instead of using the shared one.
- Live state. Whether the layer is installed in the running service is shown on the status page, alongside every other component.
It has not yet been reviewed by an outside auditor.
Version history
| Version | Date | Change |
|---|---|---|
| 1.0 | Oct 2026 | First version: refused endpoints, storage off on every request, identifiers removed, metadata-only logging |
Zero-retention layer v1.0 · Published Oct 2026 · Last reviewed 13 Oct 2026