# 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](/docs/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](/aup). 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:

```bash
saylek gpu wizard
```

Then arm hosting:

```bash
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:

```bash
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

```bash
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](/docs/circles): who your Host will serve.
- [Troubleshooting](/docs/troubleshooting): when your machine shows as offline.
- [CLI reference](/docs/cli-reference): the full everyday command table.