Acceptable Use Policy.

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.

The words below mean what they mean in the terms. The people who share with you are those whose invitation you accepted: your requests can run on their machines. The people you share with are those who accepted yours: their requests can run on your machine once you switch sharing on. Each direction is a separate choice. Clarifying what the words mean adds no duty, so it is not a version change.

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 the machine that serves a request can see everything in it, which is disclosure rather than enforcement.

So the rules below are not backstopped by a machine. What actually keeps sharing safe is who you share with, which is why the invitation rule in section 6 of the terms is not a formality.

Your request can land 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.

Do not use a machine shared with you as bulk compute. It is idle capacity its owner lets you use, 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. People who share with you exposed their hardware 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 track or profile other members. This rule does not rest on anyone being unknown to you. If you share your machine, you can see on its page each request it served for someone in the last 7 days, with its model, tokens, time, outcome and measured speed, under that person’s display name, or under “Member · ” and the first 4 characters of their account id once your machine is no longer shared with them or they have no display name. The list never shows the prompt or reply, though your machine still reads each prompt it serves, and its own records of those requests can be matched to the list. For the people you share with, not using your machines is the only way to stay off it.

Reading that list is not a breach of this rule. What you may not do with it is use it to track or profile anyone: do not collect it, publish it, or pass it on, and do not combine it with your machine’s own records or any other information to build a picture of what someone does. The same goes for anything else that passes through your machine. This is the rule in section 6 of the terms, in full.

Do not misrepresent what your machine is. Advertising models you cannot serve, or capacity you do not have, wastes the requests of the people you share with and corrupts the record everyone relies on.

Sharing your machine is always something you switch on. Using a machine someone shares with you never turns it on, and neither does accepting an invitation: saylek host wizard sets it up, and you switch sharing on for a machine from its page or the CLI. Switching it on is how you agree to the following, so read it before you do rather than after.

You will be running other people’s work on your own hardware. Requests from the people you share with will arrive and execute on your machine without you being asked each time. Saylek does not offer groups, but if you have joined one of an older kind that admits people without an invitation, or one set up for an organization, requests from anyone in it can arrive too. 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. The people you share with accepted your invitation on that understanding, and section 4 makes it a rule rather than an etiquette.

What you will see of who sent it. On your machine’s page you can see each request it served for someone in the last 7 days, with its model, tokens, time, outcome and measured speed, under that person’s display name, or under “Member · ” and the first 4 characters of their account id once your machine is no longer shared with them or they have no display name. The list never shows the prompt or reply, though your machine still reads each prompt it serves, and its own records of those requests can be matched to the list. For the people you share with, not using your machines is the only way to stay off it. Section 4 says what you may not do with that list.

What it does not expose. A request does not give you the sender’s email. Serving does not give anyone 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: a request you are serving for someone else 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 serving other people and keeps your own inference running; stopping the daemon stops both. You do not owe anyone notice or a reason.

The controls you have are who you share with, which models you advertise, and when your machine is available. You choose who can reach your machine by inviting them, and you can pause or remove any one of them, or limit sharing to set hours. You do not see a request before it runs. If that is not a bargain you want, do not switch sharing on; nothing else in Saylek depends on it.

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.

If you share your machine, you are 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 machine owner 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.

You are responsible for what you do 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 someone sent you. That is a choice you made, not a workload you received.

You are responsible for your own machine. Deciding whether to share it at all, what the hardware can take, and what else lives on that box. We do not indemnify you, and sharing your machine 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 suspend someone’s account, and we can decline to route for them. We cannot reach into another person’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.

Most of it we expect to handle by talking to people. Where we cannot, we can suspend an account, or stop routing requests to or from a machine, and the terms allow that.

We will normally raise it with the people involved 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.

If someone is misusing Saylek, or something arrived on your machine that should not have, write to Contact and 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.

Saylek is in public 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.