> ## Documentation Index
> Fetch the complete documentation index at: https://mifr.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# How a request is served

> The coordinator lists Macs. A caller seals to one of them. The model runs on that machine.

Mifr owns the model catalog. A provider advertises a subset and lazy-loads weights. The default alias is `qwen3-4b` (`mlx-community/Qwen3-4B-4bit`). That is the join-test model on purpose. Larger aliases are a supply choice, not a trust item.

The coordinator publishes the catalog as public JSON and lists who is live. It still never decrypts. When a caller wants a completion, it picks a Mac at the trust floor, agrees an HPKE channel with that Mac, and sends sealed frames through the relay. You run the model. You sign a receipt over `H(request) || H(response)`, plus model, trust, and nonce.

The hosted API is one such caller. It seals on the caller's behalf, checks the receipt, and returns the answer. `mifr ask` is the same protocol with the seal on the caller's own Mac.

The binary you serve should be the logged `mifrd`. Callers grant `transparent` when the running cdhash is a leaf of the signed log. Building from source is how you check that claim, not a requirement to join. The curl installer ships the logged build and checks checksum and cdhash before it starts the service.

Logs live at `~/.mifr/logs/mifrd.err.log`. Identity keys survive a normal uninstall, so a reinstall is the same provider. A purge makes the Mac a new identity.