How Saylek handles your information.

Local-only, and your content stays put. With local_only = true set under [federation] in ~/.saylek/config.toml, prompts you send to your machine’s local API are processed on that machine and Saylek does not route them to any other machine. If that 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.

Having nobody share with you is not the same thing. A request your machine cannot serve can still go, through our registry, to another machine of your own. Local-only is the setting that keeps it where it started.

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 who shares with you. Local-only is a control over where your content is computed, not an airgap.

And it applies only to requests that go through your machine, because that is where the setting is read. A request an application sends straight to our hosted API with an application key never touches your machine, so local-only cannot hold it back: our registry routes it as section 2 describes.

Two phrases recur below. The people who share with you are those whose invitation you accepted: their machines can serve your requests. The people you share with are those who accepted yours: your machine can serve theirs once you switch sharing on. Each direction is a separate choice, and neither creates the other. The Terms of Service use the same words, and the app shows both directions under Sharing.

When your own machine cannot serve a model, your request can go to another machine: one of your own, or one belonging to someone who shares with you. You do not switch this on. Accepting someone’s invitation is what puts their machines in reach. 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 another machine of yours, or to a machine of someone who shares with you, by way of our registry, which routes it. Saylek does not offer groups, but an older kind still exists in our system: one that admits people without an invitation, or one set up for an organization. It can only be created or joined with commands we no longer document, and if you are in one, your request can also go to anyone in it. saylek circles list shows any such group you are in, and saylek circles leave <id> takes you out of one.

Encrypted in transit on the default setup, but never from the machine that serves you. 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 machine that serves you 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. The machine that serves you is your own, or belongs to someone whose invitation you accepted. That choice is the actual mitigation, and it is only as good as your judgement of who you accept. In a group of that older kind, the people who can serve you may be strangers to you.

What the serving machine learns about you: your display name, beside each request. On that machine’s page, its owner can see each of your requests it served in the last 7 days, with its model, tokens, time, outcome and measured speed, under your display name. If the machine is no longer shared with you, or you have no display name, those entries show “Member · ” and the first 4 characters of your account id instead, and they stay listed. The list never shows your prompt or reply, or your email. Their machine still reads each prompt it serves, as above, and its own records of those requests can be matched to the list by time, model and tokens. Not using that owner’s machines is the only way to stay off their list: section 6 says how. Their Sharing page also lists you by the name you set in your account, never by your email, and our registry, which routes the request, knows which member you are.

One thing your machine sends on its own, without you asking it to. If you share your machine, so it serves other people’s requests, 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 5: 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.

Two honest headlines, because they pull in different directions.

Nothing on a machine is ever deleted automatically. Not your receipts, not your logs, not the receipts on a machine that served you. 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 best-effort twenty-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.
The serving machine, when someone else’s machine serves 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 5. On that machine’s page its owner can also see each of your requests from the last 7 days, with its model, tokens, time, outcome and measured speed, under your display name, or under “Member · ” and the first 4 characters of your account id once the machine is no longer shared with you or you have no display name. That list never shows the prompt or reply, though their machine still reads each prompt it serves, and its own records of those requests, these receipts among them, can be matched to the list. Not using their machines is the only way to stay off it.	Theirs, on their disk. We cannot reach it, and neither can you. The list on that machine’s page covers the last 7 days.
Our registry (routing)	Your prompt body, the actual text, while it waits to be routed to the machine that serves it.	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 the serving machine 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 twenty-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 (failure reports from a shared machine)	Only if you share your machine. 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, who shares with you, and who you share with.	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 registry (a record of each routed request)	For each request our registry routes: when it ran, the model, token counts, how it ended, which member sent it and with which application key, and whose machine served it. Also running totals of how much each pair of members has served the other. A copy of who served whom, and how many tokens, also goes to an internal event stream that keeps roughly the most recent 100,000 entries. No prompt text, no replies, no receipts.	Indefinitely. Nothing in our code deletes the per-request rows or the running totals for their age, and deleting your account does not remove them today, which puts them in the same position as the account record above. The event stream keeps only its most recent entries, so older ones drop off as new ones arrive. The same routing facts (which member sent a request, which machine served it, the model and a request id) are also written to our server’s structured log files. Our software rotates those by size and sets no time limit on how long they are kept.
Our registry (the measured speed of each machine)	How fast a machine ran the requests it served: the time to the first token and the generation speed, from that machine’s own report, checked against our own timing of the request. Each figure is tied to the request it was measured on, which is how the list on the machine’s page shows a request’s measured speed. No prompt text, no replies.	Until newer figures replace it. Each figure is kept until 20 newer ones for the same machine, model, engine settings and kind of request replace it, which has no time limit of its own. When a machine’s engine settings change, the figures for the old settings are deleted 35 days after the last request that used them, unless a request uses them again, and the same holds when a machine stops offering an engine for a model. Our own timing of a request, kept to check that report against, is deleted after about an hour and a half when no report for it is counted.
Our backups	A copy, taken every night, of our two server databases: the account database and the registry’s database. Between them they hold your account record and the per-request records in the two rows above.	No fixed maximum. Each night’s copy is kept for 14 days on our server and 14 days in Cloudflare’s R2 storage. A machine we run also keeps snapshots of those copies: one for each of the last 7 days, 8 weeks and 12 months in which a backup was taken. That is a count, not an age limit, so a snapshot can be more than a year old. Separately, Cloudflare keeps a restore history of the account database it holds for us, for up to 30 days. Deleting your account does not remove records from existing backups, and records still kept in our databases also appear in later backups.

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.

This section describes the information the Saylek software sends us from a device you connect with saylek host, whether or not you share it. The schedule below names each category: when it is sent, why, who reads it, where we keep it and for how long. Placement is the part of Saylek that picks which machine serves a request. Live state is where we hold each connected machine’s current figures.

4.1 Device Information. When you connect a device to the Services, the Saylek software on that device collects and sends us technical information about the device and its operation. This covers the software, engines and models installed on or available through the device, and their configuration, status, capacity, performance and activity (together, “Device Information”). Device Information may include information about software and models you have not chosen to make available through the Services. We may collect it whenever the device is connected, whether or not you have turned on sharing.

4.2 Usage and activity data. Device Information may include metrics, counters, timings and other operational data that describe how software on your device is used, including use unrelated to the Services. We design these features to exclude the content of your prompts, inputs and outputs. Even so, Device Information, alone or combined with other information we hold, may allow inferences about how, when and how much you use your device and the software on it.

4.3 How we use Device Information. We use Device Information to provide, operate, maintain and secure the Services. This includes showing you information about your devices, deciding where requests are served, planning capacity, measuring and diagnosing performance and reliability, and detecting and preventing misuse. We may also use it for other purposes described in this Notice or made known to you when the information is collected.

4.4 Who may access it. We may make Device Information available to you, to our personnel and service providers who need it for the purposes above, and as otherwise described in this Notice or required by law.

4.5 How long we keep it. We keep Device Information only as long as reasonably necessary for the purposes above, in line with the schedule below and our Data Retention Policy, unless the law requires or permits a longer period.

The schedule that follows lists the categories of Device Information we currently collect, with their purposes and retention periods. It describes our current practice and does not limit sections 4.1 to 4.5.

What we receive	When	Why	Who reads it	Where we keep it	How long
Machine status: its status, quota, priority, capacity and admission settings	Every 10 seconds while the machine is connected	Placement	Placement and Saylek staff	Live state	Until 30 seconds after the machine disconnects
How busy the machine is, including counts of the work its engines do outside Saylek (home use)	Every 10 seconds while the machine is connected	Capacity planning and staff diagnosis	Saylek staff	Live state and our measurement store	35 days in the measurement store
A record of each request it serves for Saylek	Each request it serves for Saylek	Measurement and staff diagnosis	Saylek staff and our measurement system	Our measurement store	Each request’s row about 2 to 3 hours, longer during an outage. The kept samples (the last 20 per model and machine) and the counters: 35 days
Engine facts (each engine’s configuration and model list, and whether its metrics endpoint is on) and the agent’s version	When the machine connects, and when one of them changes	Placement	Placement and Saylek staff	Live state	Until 30 seconds after the machine disconnects
The engines and models found on your machine, including models you have not chosen to share	When your machine connects, and whenever the engines or models on it change, even if you are not sharing the machine	To show you which models we found, and to help you share them	You and Saylek staff. It is not used to send requests to your machine	Live state	Until 30 seconds after your machine disconnects
A failure report	When something fails	Staff diagnosis	Saylek staff	Our report store	No fixed limit
Engine readings: each engine’s token totals, its start time, how many requests are running and waiting, how full its cache memory is, and, for each slot, the tokens it holds and its task number; whether each shared model is loaded. The engine’s address on your local network identifies it	Once per check of each engine, every 60 seconds give or take 20%, while you share the machine and our server has accepted readings on its connection	Placement and staff diagnosis	Placement and Saylek staff only	Live state	Until the engine leaves the machine’s routes, 30 seconds after the machine disconnects, when you stop sharing it, or when our server stops accepting readings
End stamps: each request’s reference to the engine’s latest reading at the end of the request. We store each check’s reading once, and only when a request refers to it: every request the engine finishes before its next check refers to that one copy	Each finished request on an engine we route to, while our server accepts readings	Staff diagnosis, and placement through the live readings	Saylek staff	Our measurement store	Each request’s reference about 2 to 3 hours, and the reading it refers to up to an hour longer: about 2 to 4 hours in all, longer during an outage
Reading counts: how many readings arrived or were missing, per value and per reason, and three counts about the machine’s status updates	Each reading, and each status update	Staff diagnosis	Saylek staff	Our measurement store	35 days
Our server’s log of parts it dropped: the machine’s id, the reason and how many	When our server drops part of what a machine sent	Staff diagnosis	Saylek staff	Our log store	Rotated by size, no time limit
Our backups of everything above that sits in our databases	Every night	Recovery	Saylek staff	Nightly copies of our databases, and each Saylek region’s own backups	No fixed maximum. Each nightly copy is kept 14 days; snapshots of those copies are then pruned to 7 daily, 8 weekly and 12 monthly ones. A region’s own backups keep 7 daily and 4 weekly copies

Engine readings and end stamps hold no prompts and no replies. Their token totals do show how much each engine worked between checks, your own use of it outside Saylek included.

Engine readings and end stamps start only when our server accepts them. A machine sends them only on a connection where our server has accepted readings, and our server accepts them on no connection before this notice is published.

Stopping sharing is the only way to stop engine readings and end stamps. Run saylek host stop. Your machine then starts no new reads of its engines and sends us none, our server releases the live readings it holds for the machine, and end stamps still waiting on your machine to be sent are removed rather than sent.

Deleting your account does not yet remove them. End stamps, reading counts and live readings stay after your account is deleted, and they keep arriving for as long as the machine stays connected (#7217). To stop them arriving, stop sharing before you delete your account; what is already kept then ends on the times in the table.

If you run TensorRT-LLM with its statistics turned on: Saylek reads those statistics first, on every check. Each read empties them for every other reader, so any other tool on your machine that reads them sees only what built up since Saylek’s last read. A read takes seconds.

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.

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 another person’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 machine serving you 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.

local_only = true ([federation] in ~/.saylek/config.toml): your prompts, uploads, and completions are not routed to any other machine, yours or anyone else’s. 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 who shares with you, and looking for updates; and this does not override a proxy upstream you registered yourself, which still receives requests that resolve to it. It also covers only requests that go through your machine: a request an application sends straight to our hosted API with an application key never passes through it.

Stop using someone’s machines. Choose Stop using their compute on their page in Sharing, or run saylek sharing stop-using --person <name>. Once Saylek confirms it, none of your later requests reaches that person’s machine; a request already running there is not stopped. From then on none of your requests joins the list on their machines’ pages; the ones already there stay until they are more than 7 days old. It does not stop egress: anyone else who shares with you, any group of the older kind you are in, and your own other machines can 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 the machines that served them. 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, the control comes before rather than after: send that work through your own machine with local_only set, and not through the hosted API.

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.

Who	What they handle	Why
Cloudflare	The saylek.com site itself, your account and sign-in records, the bot check on public forms, and a 14-day copy of our database backups	Saylek's web surface runs on Cloudflare Workers, with account data in a Cloudflare D1 database and Turnstile guarding public forms. The backup copies sit in Cloudflare R2 storage
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, who shares with you, and the routing of a request to the machine that serves it	This is the part we run ourselves. Section 2 covers what a routed request contains
Another person's machine	Your prompt and its reply, in the clear, when their machine serves you. On that machine's page its owner can also see each of your requests from the last 7 days, with its model, tokens, time, outcome and measured speed, under your display name, or under “Member · ” and the first 4 characters of your account id once the machine is no longer shared with you or you have no display name. That list never shows the prompt or reply, though their machine still reads each prompt it serves and its own records of those requests can be matched to the list	Not a company we hired. Someone whose invitation you accepted, or a member of a group you are in. This is the one that matters most. Not using their machines is the only way to stay off their list

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: the machines that serve you are wherever their owners are, so a request can be served in another country by a person, not a data centre. If that is unacceptable for your work, send it through your own machine with local_only set, not through the hosted API.

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 sections 3 and 4 state, 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.

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.