Hosting your GPU
Hosting is how capacity gets into the pool. It is always an explicit choice: nothing you do as a consumer ever turns your machine into a Host.
What hosting commits you to
When you host, your machine serves requests from members of your Circles while your GPU is idle. In exchange your own requests can draw on everyone else's idle capacity.
Two things are worth being clear about before you start:
- Your own work keeps priority on your own GPU. A Circle request is not allowed to starve something you are waiting on yourself.
- You will see what you serve. Serving a request means your machine handles that member's prompt in the clear, because that is how it computes the answer. The other side of this is documented for consumers in Privacy and egress; as a Host you are the party on the receiving end of that trust.
The full version of what arming hosting commits you to, including what serving does not expose and who is answerable for what, is the Acceptable Use Policy. Read it before you run the wizard below rather than after: running it is the act that agrees to it.
Requirements
| Hardware | A GPU the daemon can serve from. NVIDIA via cuda, Apple Silicon via metal. |
| Binary | A build with an inference backend compiled in. Released binaries have one. |
| Membership | You must be an active member of the Circle you host for. |
A from-source build with no --features flag compiles but cannot serve: the first call
returns HTTP 503 no inference backend compiled in. Build with cpu, cuda, or metal.
Start hosting
Get a model serving first, if you have not already:
saylek gpu wizard
Then arm hosting:
saylek host wizard
The wizard is what actually turns hosting on: it sets [host].enabled, resolves and writes
the models you will advertise, mints the host credential and installs the background service.
saylek gpu wizard above gets a model serving locally, which is a different thing and does
not arm contribution. Bare saylek host is the serve verb for a machine that is already set
up; on one that is not, it refuses and points you back here.
Afterwards, saylek host runs the up-path in the foreground if you want to watch it.
Confirm what your machine is offering:
saylek models # what this machine can serve right now
saylek status # health, and whether you are connected
Stopping: three different scopes
These are easy to confuse, and one of them is much larger than people expect.
| You want to | Command | What keeps working |
|---|---|---|
| Stop contributing, keep using Saylek yourself | saylek host pause | Your own inference, your Circles, your standing |
| Stop the daemon entirely | saylek stop | Nothing. saylek call will not answer until saylek start |
| Step away from Saylek but keep your account | saylek settings account deactivate | Reversible with activate |
saylek host pause is the small, targeted one, and it is what the "Pause contributing"
control on your home page does.
There is no bare saylek pause. "Pause" means two different things at two different scopes,
so the CLI does not guess which one you meant: it answers with both commands and lets you
pick. Use saylek host pause when you mean contributing, and saylek stop when you mean
the daemon.
Checking your contribution
saylek statement <YYYY-MM>
An honest, no-money record of where each request ran. It is a record of work served, not a bill: nothing is owed in either direction.
Next steps
- Circles and membership: who your Host will serve.
- Troubleshooting: when your machine shows as offline.
- CLI reference: the full everyday command table.
Last checked 2026-07-24 · read as markdown at /docs/hosting.md