Privacy
How Saylek handles your information.
Effective 2026-07-24 · v1-beta
This describes what actually happens to your data, checked against the code rather than against what we would like to be true. Where the answer is uncomfortable, it is written down as the uncomfortable answer.
1. When your requests stay on your machine
Solo, and your content stays put. With no Circle, or with
One boundary on that sentence, because it is easy to read it as broader than it is. This governs Saylek’s routing. It does not override a destination you configured yourself: if you have registered your own proxy upstream and call a model that resolves to it, the request is forwarded there regardless of this setting. Saylek also still talks to our own servers for the ordinary running of your account, such as signing in and checking memberships. Local-only is a control over where your content is computed, not an airgap.
local_only = true set under [federation] in ~/.saylek/config.toml, your prompts are processed on your own machine and Saylek does not route them to anyone else. If your machine cannot serve a request, it fails rather than being sent somewhere. That is enforced in the code, not a preference we honour on a best-effort basis.One boundary on that sentence, because it is easy to read it as broader than it is. This governs Saylek’s routing. It does not override a destination you configured yourself: if you have registered your own proxy upstream and call a model that resolves to it, the request is forwarded there regardless of this setting. Saylek also still talks to our own servers for the ordinary running of your account, such as signing in and checking memberships. Local-only is a control over where your content is computed, not an airgap.
2. When your requests leave your machine
In a Circle, when your own device cannot serve a model, your request goes to another member’s machine. On by default. What that means, precisely:
What leaves: your prompt, as text. Your uploads too, if any, such as an image or an audio clip. Not a summary and not a hash. The content.
Where it goes: to a Host in a Circle you belong to, by way of our registry, which routes it.
Encrypted in transit on the default setup, but never from the Host. Out of the box the connection is TLS, so nobody in between reads it off the wire. One caveat worth knowing: if you point Saylek at a different registry with an
TLS protects your prompt in transit, not from the people it is travelling to:
The Host’s machine decrypts and reads your prompt, because running it requires that. There is no end-to-end encryption, no secure enclave, and no technical measure that stops the person operating that machine from seeing what you sent.
We handle it too. It passes through our registry to get routed, so your prompt is on our server as well. Section 3 says for how long.
The protection here is social, not cryptographic. It is a member of a Circle you belong to. That is the actual mitigation, and it is only as good as how that Circle admits people. On an invite-only Circle, the default, the owner or an admin admits members, so unless you own it someone else chose them. An open-join Circle admits people without an invite, and they may be strangers to you.
What the Host learns about you: a key fingerprint, not your name or email. But it is stable across requests, so a Host can tell that many requests came from the same member. They just cannot tell which member from that alone. Pseudonymous, not anonymous. Our registry, which routes the request, does know which member you are.
One thing your machine sends on its own, without you asking it to. If you are contributing capacity, so your machine serves other members, then a request that fails or is refused by policy while it is serving sends a short status report to our registry. It is queued in the background and goes out over the connection your machine already holds. This is the only thing Saylek uploads that you did not initiate, and it exists so that a member whose request died is not the only party who can tell that it did.
The whole report, with nothing omitted: which of a fixed list of failure conditions occurred, an opaque request id, the Saylek version you are running, and a timestamp. That is all of it. No prompt text, no replies, no log lines, no file paths, no email address, no machine name. The report has no free-text field for any of that to travel in, so this is the same kind of claim as the one about receipts in section 4: a shape the data cannot take, not a rule we are promising to follow.
It is attributable to you.The connection it arrives on is authenticated, so even though the payload names nobody, we can tell which member’s machine sent it. We would rather say that than let “the payload contains no identifier” imply an anonymity it does not have.
Running
What leaves: your prompt, as text. Your uploads too, if any, such as an image or an audio clip. Not a summary and not a hash. The content.
Where it goes: to a Host in a Circle you belong to, by way of our registry, which routes it.
Encrypted in transit on the default setup, but never from the Host. Out of the box the connection is TLS, so nobody in between reads it off the wire. One caveat worth knowing: if you point Saylek at a different registry with an
http:// address, it will use an unencrypted connection and will not stop you or warn you. Do not do that outside a trusted local network.TLS protects your prompt in transit, not from the people it is travelling to:
The Host’s machine decrypts and reads your prompt, because running it requires that. There is no end-to-end encryption, no secure enclave, and no technical measure that stops the person operating that machine from seeing what you sent.
We handle it too. It passes through our registry to get routed, so your prompt is on our server as well. Section 3 says for how long.
The protection here is social, not cryptographic. It is a member of a Circle you belong to. That is the actual mitigation, and it is only as good as how that Circle admits people. On an invite-only Circle, the default, the owner or an admin admits members, so unless you own it someone else chose them. An open-join Circle admits people without an invite, and they may be strangers to you.
What the Host learns about you: a key fingerprint, not your name or email. But it is stable across requests, so a Host can tell that many requests came from the same member. They just cannot tell which member from that alone. Pseudonymous, not anonymous. Our registry, which routes the request, does know which member you are.
One thing your machine sends on its own, without you asking it to. If you are contributing capacity, so your machine serves other members, then a request that fails or is refused by policy while it is serving sends a short status report to our registry. It is queued in the background and goes out over the connection your machine already holds. This is the only thing Saylek uploads that you did not initiate, and it exists so that a member whose request died is not the only party who can tell that it did.
The whole report, with nothing omitted: which of a fixed list of failure conditions occurred, an opaque request id, the Saylek version you are running, and a timestamp. That is all of it. No prompt text, no replies, no log lines, no file paths, no email address, no machine name. The report has no free-text field for any of that to travel in, so this is the same kind of claim as the one about receipts in section 4: a shape the data cannot take, not a rule we are promising to follow.
It is attributable to you.The connection it arrives on is authenticated, so even though the payload names nobody, we can tell which member’s machine sent it. We would rather say that than let “the payload contains no identifier” imply an anonymity it does not have.
Running
saylek diagnose uploads nothing. That command writes a redacted bundle to a file on your own disk and stops there. You decide who sees it. Your logs and your prompts do not leave your machine by any route described on this page other than the routing in this section.3. What is kept, where, and for how long
Two honest headlines, because they pull in different directions.
Nothing on a machine is ever deleted automatically. Not your receipts, not your logs, not a Host’s receipts. There is no expiry, no TTL, no cleanup job. It sits there until someone deletes it by hand.
What our own servers delete automatically, they delete on two different schedules, and one of them is much worse than the other. The reply coming back to you is cleared as soon as it has been delivered, with a ten-minute backstop if something crashes mid-delivery. The queue your prompt waits in on the way out is trimmed by volume rather than by age, so there is no maximum time it can sit there. Both are in the table.
A receipt is a hash, not a transcript. A hash is a fingerprint: it proves this reply came from that request, and it cannot be turned back into what you typed. That is the point of it. It makes work verifiable without recording content.
Nothing on a machine is ever deleted automatically. Not your receipts, not your logs, not a Host’s receipts. There is no expiry, no TTL, no cleanup job. It sits there until someone deletes it by hand.
What our own servers delete automatically, they delete on two different schedules, and one of them is much worse than the other. The reply coming back to you is cleared as soon as it has been delivered, with a ten-minute backstop if something crashes mid-delivery. The queue your prompt waits in on the way out is trimmed by volume rather than by age, so there is no maximum time it can sit there. Both are in the table.
| Where | What is there | How long |
|---|---|---|
Your machine: ~/.saylek/receipts/ | A receipt per request: model, token counts, timestamps, and a hash of the request and response. Not the text. | Forever, until you run saylek wipe. No expiry. |
Your machine: ~/.saylek/log/ | Activity lines: what was served, when, how long. No prompt text. | Forever, until you run saylek wipe. No expiry. |
| A Host’s machine, when they serve you | A receipt for the work they did, with the same hashes, not text. Plus whatever their own machine does while running it: see the caveat in section 4. | Theirs, on their disk. We cannot reach it, and neither can you. |
| Our registry (routing) | Your prompt body, the actual text, while it waits to be routed to a Host. | No time limit. The queue is trimmed by count (about 10,000 entries), never by age. A busy queue displaces it in moments. A quiet queue can hold it indefinitely, because nothing deletes it for being old. This is the least tidy fact in this notice and we are not going to hide it. |
| Our registry (the reply coming back) | The completion text a Host produced for you, while it is being relayed back to your machine. | Minutes, not indefinitely. It is removed as soon as your machine has received it. If something crashes mid-delivery, a ten-minute expiry clears it instead. Setting that expiry is best-effort, so in the rare case it fails the entry is evicted later under memory pressure rather than on a clock. |
| Our registry (Host failure reports) | Only if your machine contributes capacity. A failure condition from a fixed list, an opaque request id, your Saylek version, a timestamp. No prompt text, no replies, no logs, no paths. Section 2 has the full field list. | It becomes a line in our server logs. Treat that as indefinite. Nothing expires it and no job purges it, which puts it in the same position as the account record below. A short-lived duplicate-suppression key alongside it does expire, after an hour, but that is a de-duplication mechanism and not a retention limit on the report itself. |
| Your account | Email, region, and your Circle memberships. | Indefinitely, and we are not going to round that up into a deletion promise. Deleting your account is a 90-day soft delete: it is reversible for 90 days, and after that you can no longer recover the account. What the 90 days does not do is erase the record. Today nothing purges or anonymises it when the window closes; an actual purge is planned and not built. The keys on your own device go immediately and irreversibly. |
| Our trust engine, your Circle standing | A per-request ledger of work that ran between you and another member: when it ran, which Circle, who served, who consumed, and the points it moved. No prompt text, no replies, no receipts. The contribution and consumption totals you see are derived from these rows. | 24 monthsafter you delete your account. Then we collapse those rows to a single per-Circle total and drop the per-request detail. We collapse rather than erase because the record is shared: erasing your side would silently rewrite the other member’s history, so their contribution would change because you left. |
A receipt is a hash, not a transcript. A hash is a fingerprint: it proves this reply came from that request, and it cannot be turned back into what you typed. That is the point of it. It makes work verifiable without recording content.
4. What we do not do
We do not train on your prompts. No model is trained, tuned, or improved on what you send.
We do not sell anything about you. There is nobody to sell to, and there is no money in this system at all.
We do not read your prompts for analytics, quality, or moderation.
Receipts and activity logs never contain prompt text. The code that writes those two has no field for it. That is not a policy we are promising to keep, it is a shape the data cannot take.
One caveat to that last point, stated plainly. Saylek has an opt-in debugging setting (
We do not sell anything about you. There is nobody to sell to, and there is no money in this system at all.
We do not read your prompts for analytics, quality, or moderation.
Receipts and activity logs never contain prompt text. The code that writes those two has no field for it. That is not a policy we are promising to keep, it is a shape the data cannot take.
One caveat to that last point, stated plainly. Saylek has an opt-in debugging setting (
[debug] traces = true) that writes prompts and replies to a file in plaintext, so an operator can see what their own machine is doing. It is off by default. As the code stands today a Circle-mate’s request does not reach that writer, but that is because of how the request happens to be shaped, not because there is a rule stopping it. We are fixing that so it becomes an actual rule rather than a lucky miss. Until then: a Host running with that setting on is not currently capturing your prompts, and we would rather tell you the shape of that than round it up to a guarantee.5. What you control
local_only = true ([federation] in ~/.saylek/config.toml): your prompts, uploads, and completions are not routed to another member. A request your machine cannot serve fails rather than being sent. Note the scope twice over: Saylek still talks to our servers for the ordinary running of your account, such as signing in, checking your Circle memberships, and looking for updates; and this does not override a proxy upstream you registered yourself, which still receives requests that resolve to it. What it stops is your content going to another member.Leave every Circle.Requests stop leaving once you hold no live membership at all. Leaving one Circle while you are still in another only removes that Circle’s machines from reach; the rest still serve you.
saylek wipe deletes ~/.saylek entirely: receipts, keys, models, logs, config. It asks you to type DELETE first, because it is irreversible.Delete your account. Two routes, and they do different amounts of work. From account settings on the web, which closes the account but obviously cannot touch files on your machine, so run
saylek wipe yourself if you want those gone too. Or saylek settings account delete from the CLI, which closes the account and clears this machine in one step. Either way the account record itself behaves as described in section 3.What you cannot control: requests already served. Those receipts are on other members’ machines. We have no ability to reach into someone’s laptop and delete them, and we are not going to claim we do. If that matters to you,
local_only is the control, before rather than after.6. Who holds this data, and who else touches it
Saylek is operated by Saylek LLC, a Washington limited liability company, whose registered agent is Northwest Registered Agent in Spokane, Washington. Saylek LLC decides what is collected and why, so it is the party you address a data question to, at Contact.
Three sets of machines are involved, and it is worth being exact about which is which.
Cloudflare and Resend are both US companies operating global networks, so data reaches servers outside your country. A more consequential version of the same fact is in section 2: Hosts are wherever members are, so a request can be served in another country by a person, not a data centre. If that is unacceptable for your work,
Three sets of machines are involved, and it is worth being exact about which is which.
| Who | What they handle | Why |
|---|---|---|
| Cloudflare | The saylek.com site itself, your account and sign-in records, and the bot check on public forms | Saylek's web surface runs on Cloudflare Workers, with account data in a Cloudflare D1 database and Turnstile guarding public forms |
| Resend | The sending of sign-in links, invites, and account notices, which means your email address and the text of that message | It is our email provider. It receives your address in order to deliver the message; it is not the only party that holds it, since your account record lives on Cloudflare and on our own servers |
| Saylek's own servers | The registry: which member you are, which Circles you are in, and the routing of a request to a Host | This is the part we run ourselves. Section 2 covers what a routed request contains |
| Another member's machine | Your prompt and its reply, in the clear, when that member's Host serves you | Not a company we hired. A peer, whose Circle you joined. This is the one that matters most |
local_only is the control.7. What is still outstanding
Saylek is not intended for children, and the exact minimum age and the jurisdictions it has to satisfy are being settled rather than guessed at.
Also outstanding, and deliberately not invented: the legal basis for processing under GDPR and UK GDPR, whether Saylek is characterised as controller or processor for a routed request, and a formal data-rights request route beyond the address above. These need a counsel answer and will be published here before Saylek opens publicly.
There are no retention commitments to make beyond what section 3 states, because there are none in the system to commit to. If that changes, this page changes with it.
For a question this page does not answer, or a request about your data, reach us at Contact.
Also outstanding, and deliberately not invented: the legal basis for processing under GDPR and UK GDPR, whether Saylek is characterised as controller or processor for a routed request, and a formal data-rights request route beyond the address above. These need a counsel answer and will be published here before Saylek opens publicly.
There are no retention commitments to make beyond what section 3 states, because there are none in the system to commit to. If that changes, this page changes with it.
For a question this page does not answer, or a request about your data, reach us at Contact.
Related
Terms of Service sets out the routing model as a term you accept. Security covers signed receipts, sign-in, and how to report a vulnerability. Privacy and egress is the operator’s-eye version with the actual commands.
Grounded against the running code, not against any privacy regime's disclosure requirements. Not counsel-reviewed. The legal basis for processing and a minimum age are named below as outstanding rather than invented.