Acceptable use
Acceptable Use Policy.
Effective 2026-08-03
Saylek runs your requests on other members' computers, and runs theirs on yours. That is a different bargain from using a service, and it needs saying plainly: there is a person at the other end of every request, and their machine is the one doing the work. This page is what we ask of you, what you are agreeing to if you host, and who is answerable for what.
1. How this relates to the Terms
The Terms of Service are the agreement. Sections 4, 6 and 7 there each carry a sentence about hosting, conduct and liability; this page is the long form of those sentences.
It deliberately adds no new obligation. Your recorded acceptance is of a specific version of the terms, and it would not be honest to widen what you agreed to through a page you never had to read. If something here ever needs to become a new duty, it goes into the terms and we ask you to accept them again.
It deliberately adds no new obligation. Your recorded acceptance is of a specific version of the terms, and it would not be honest to widen what you agreed to through a page you never had to read. If something here ever needs to become a new duty, it goes into the terms and we ask you to accept them again.
2. Nothing here screens what you send
Before the rules, the fact they rest on: we do not inspect, classify, or filter the content of requests. There is no moderation layer, no keyword list, and no scanning step anywhere between your machine and the machine that serves you. We checked for one rather than assuming its absence.
Two things that might look like exceptions and are not. A model can refuse on its own policy, and if it does, that refusal is passed back to you unchanged; that is the model’s judgement, not ours. And a Host can see everything it serves, which is disclosure rather than enforcement.
So the rules below are not backstopped by a machine. What actually keeps the pool safe is who is in it, which is why the invite rule in section 6 is not a formality.
Two things that might look like exceptions and are not. A model can refuse on its own policy, and if it does, that refusal is passed back to you unchanged; that is the model’s judgement, not ours. And a Host can see everything it serves, which is disclosure rather than enforcement.
So the rules below are not backstopped by a machine. What actually keeps the pool safe is who is in it, which is why the invite rule in section 6 is not a formality.
3. What you may not send through the pool
Your request lands on a real person’s computer and they will be able to read it. Do not send:
Other people’s private data. Personal, medical, financial or otherwise confidential information that is not yours to share. This is the one most likely to happen by accident, and it is the one with a person on the other end.
Anything illegal where you are or where they are. You will not usually know which country the serving machine is in, so assume the stricter answer.
Sexual content involving children, in any form, generated or otherwise. There is no ambiguity here and no context in which it is acceptable. It is grounds for immediate removal and we will report it.
Work aimed at harming people. Building weapons, planning violence, targeted harassment, stalking, or producing material designed to deceive a specific person or group.
Credentials, keys, or tokens.Yours or anyone else’s. A prompt containing a live secret has handed that secret to whoever is hosting.
Other people’s private data. Personal, medical, financial or otherwise confidential information that is not yours to share. This is the one most likely to happen by accident, and it is the one with a person on the other end.
Anything illegal where you are or where they are. You will not usually know which country the serving machine is in, so assume the stricter answer.
Sexual content involving children, in any form, generated or otherwise. There is no ambiguity here and no context in which it is acceptable. It is grounds for immediate removal and we will report it.
Work aimed at harming people. Building weapons, planning violence, targeted harassment, stalking, or producing material designed to deceive a specific person or group.
Credentials, keys, or tokens.Yours or anyone else’s. A prompt containing a live secret has handed that secret to whoever is hosting.
4. What you may not do to the pool
Do not use the pool as bulk compute. It is idle capacity that members lend each other, not a batch cluster. Sustained automated load that crowds out the people whose machines you are using is a misuse of it, whether or not a rate limit stops you first.
Do not attack, probe, or destabilise other machines. Members exposed their hardware to you on the understanding that you would use it to run inference. Security research is welcome, but against your own machines and under the disclosure policy, not against a member who did not agree to be a target.
Do not deanonymise, track, or profile other members. A Host sees a stable key fingerprint rather than a name, and correlating that fingerprint back to a person, or building a picture of someone from what passes through your machine, is exactly the thing the design is trying to prevent.
Do not misrepresent what your machine is. Advertising models you cannot serve, or capacity you do not have, wastes other members’ requests and corrupts the record everyone relies on.
Do not attack, probe, or destabilise other machines. Members exposed their hardware to you on the understanding that you would use it to run inference. Security research is welcome, but against your own machines and under the disclosure policy, not against a member who did not agree to be a target.
Do not deanonymise, track, or profile other members. A Host sees a stable key fingerprint rather than a name, and correlating that fingerprint back to a person, or building a picture of someone from what passes through your machine, is exactly the thing the design is trying to prevent.
Do not misrepresent what your machine is. Advertising models you cannot serve, or capacity you do not have, wastes other members’ requests and corrupts the record everyone relies on.
5. If you host, this is what you are agreeing to
Hosting is always something you switch on. Consuming never turns it on, and joining a Circle does not either:
You will be running other members’ work on your own hardware. Requests from members of the Circles you host for will arrive and execute on your machine without you being asked each time. There is no approve-each-request step, and we are not going to pretend one is coming.
You will be able to read what you run. Their prompt passes through your machine in the clear, because that is how the answer gets computed. Treat it as theirs: do not collect it, do not publish it, do not go looking. Members joined a Circle with you on that understanding, and section 4 makes it a rule rather than an etiquette.
What it does not expose.A guest request does not carry the sender’s name or email; your machine sees a key fingerprint. Serving does not give another member a shell, filesystem access, or the ability to run arbitrary code on your box. What runs is inference, through the model backend you configured, on the models you chose to advertise.
What it costs you. Electricity, wear, heat, and a GPU that is busy when you might have wanted it. Your own work takes priority on your own machine: an in-flight guest decode is dropped when your work arrives. That is a priority, not an instant guarantee, and the interruption lands at the next step of the work rather than immediately.
You can stop at any time.
The controls you have are which Circle you host for, which models you advertise, and when you are on. You do not choose which member reaches you, and you do not see a request before it runs. If that is not a bargain you want, do not arm hosting; nothing else in Saylek depends on it.
saylek host wizard is the step that arms it. Running that command is how you agree to the following, so read it before you do rather than after.You will be running other members’ work on your own hardware. Requests from members of the Circles you host for will arrive and execute on your machine without you being asked each time. There is no approve-each-request step, and we are not going to pretend one is coming.
You will be able to read what you run. Their prompt passes through your machine in the clear, because that is how the answer gets computed. Treat it as theirs: do not collect it, do not publish it, do not go looking. Members joined a Circle with you on that understanding, and section 4 makes it a rule rather than an etiquette.
What it does not expose.A guest request does not carry the sender’s name or email; your machine sees a key fingerprint. Serving does not give another member a shell, filesystem access, or the ability to run arbitrary code on your box. What runs is inference, through the model backend you configured, on the models you chose to advertise.
What it costs you. Electricity, wear, heat, and a GPU that is busy when you might have wanted it. Your own work takes priority on your own machine: an in-flight guest decode is dropped when your work arrives. That is a priority, not an instant guarantee, and the interruption lands at the next step of the work rather than immediately.
You can stop at any time.
saylek host pause stops contributing and keeps your own inference running; stopping the daemon stops both. You do not owe the pool notice or a reason.The controls you have are which Circle you host for, which models you advertise, and when you are on. You do not choose which member reaches you, and you do not see a request before it runs. If that is not a bargain you want, do not arm hosting; nothing else in Saylek depends on it.
6. Who is responsible for what
This is the part a normal terms document does not have to answer, because normally the computer belongs to the company.
The member who sends a request is responsible for it. What is in it, whether it was theirs to send, and what they do with the answer. Sending it through someone else’s machine does not move that responsibility onto them.
A Host is not responsible for the content of what it serves. You cannot see a request before it runs, you did not choose it, and nothing gives you a way to refuse one on its content. Our position is that a Host serving requests in the ordinary way is not the author or the publisher of what passes through, and we will say so if we are asked.
A Host is responsible for what it does afterwards. The protection above is for serving. It does not extend to keeping copies, reading through what you served, publishing it, or running a modified build that logs what a member sent you. That is a choice you made, not a workload you received.
A Host is responsible for its own machine. Deciding whether to host at all, what the hardware can take, and what else lives on that box. We do not indemnify you, and running a Host is at your own risk; that is the plain reading of terms section 7 and we would rather state it here than let you discover it there.
What we can and cannot do about a breach.We can remove someone from the pool, and we can decline to route for them. We cannot reach into a Host’s machine to delete a request that already arrived, and we cannot retrieve something you sent. Once a request has left your machine, it is on theirs.
The member who sends a request is responsible for it. What is in it, whether it was theirs to send, and what they do with the answer. Sending it through someone else’s machine does not move that responsibility onto them.
A Host is not responsible for the content of what it serves. You cannot see a request before it runs, you did not choose it, and nothing gives you a way to refuse one on its content. Our position is that a Host serving requests in the ordinary way is not the author or the publisher of what passes through, and we will say so if we are asked.
A Host is responsible for what it does afterwards. The protection above is for serving. It does not extend to keeping copies, reading through what you served, publishing it, or running a modified build that logs what a member sent you. That is a choice you made, not a workload you received.
A Host is responsible for its own machine. Deciding whether to host at all, what the hardware can take, and what else lives on that box. We do not indemnify you, and running a Host is at your own risk; that is the plain reading of terms section 7 and we would rather state it here than let you discover it there.
What we can and cannot do about a breach.We can remove someone from the pool, and we can decline to route for them. We cannot reach into a Host’s machine to delete a request that already arrived, and we cannot retrieve something you sent. Once a request has left your machine, it is on theirs.
7. What happens when someone breaks this
Most of it we expect to handle by talking to people. Where we cannot, we can suspend an account, remove a member from the pool, or stop routing to a Host, and the terms allow that.
Because a Circle is people who vouched for each other, we will normally raise it with the Circle first rather than acting silently over the top of them. Section 3’s first and third items are the exceptions: those we act on immediately.
We do not read requests in order to police this, and we have no mechanism to. What reaches us is what a member reports.
Because a Circle is people who vouched for each other, we will normally raise it with the Circle first rather than acting silently over the top of them. Section 3’s first and third items are the exceptions: those we act on immediately.
We do not read requests in order to police this, and we have no mechanism to. What reaches us is what a member reports.
8. Reporting something
If a member is misusing the pool, or something arrived on your machine that should not have, write to Contactand tell us what happened. Include enough for us to identify the account; you do not need to send us the content itself, and for anything in section 3’s third item, please do not.
A security flaw is a different channel with a different promise attached. That goes to the disclosure policy, which sets out scope and safe harbour.
A security flaw is a different channel with a different promise attached. That goes to the disclosure policy, which sets out scope and safe harbour.
9. Status of this page
Saylek is in closed beta and this is a first version. The conduct rules are ours to state; the liability position in section 6 is our reading, written before a lawyer has looked at it, and it is the part most likely to change. When it does, the date at the top changes with it.
The factual claims here about what the software does are grounded against the code that does it rather than against how it was meant to work. Where we could not ground something, it is not on the page. Questions go to Contact.
The factual claims here about what the software does are grounded against the code that does it rather than against how it was meant to work. Where we could not ground something, it is not on the page. Questions go to Contact.
This restates duties already in the Terms of Service rather than adding new ones, so accepting it is not a separate step. It has not been reviewed by a lawyer, and the sections below say which facts are grounded in the running code.