Support.
How to get help, what to include, and where a report should go — issue, discussion, or a private security report.
0.1.0-alpha.N → -beta.N → -rc.N → 0.1.0 ladder. The wire protocol between hub and node, the on-disk state layout and the CLI surface can all change without a deprecation period; /v1 tracks the OpenAI shape and is the most stable thing here. Nothing is accredited or covered by a compatibility promise.Start with relay doctor
relay doctor # this machine
relay doctor https://hub:8383 # and whether it can reach that hubIt checks the things that actually go wrong: whether a GPU was found, whether llama-server and rpc-server resolve and match the build relay expects, whether the sandbox is available, whether this machine has joined a pool, and whether TLS to the hub and to /v1 works.
Most reports resolve to something doctor already prints, so paste its output first.
Where to ask
| Something is broken, or behaves unlike the docs | Open an issue |
| A question about how relay works | Open a discussion |
| A security problem | Not a public issue — report it privately, see Security. |
docs/KNOWN-ISSUES.md covers the surprises that are deliberate — third-party mDNS browsers not seeing a hub, sharding being slower than one card that fits, caps that warn instead of deleting. Worth a look before filing.
What to include
| Include | Detail |
|---|---|
relay doctor | output, and relay status if a pool is running |
relay version | the exact version |
| Expected vs. actual | what you expected, and what happened |
| Machine | which machine it happened on — hub or node, and what GPU |
Logs go to stderr. Under systemd that is journalctl --user -u relay -n 200; in the foreground it is already on your terminal.
What this is
relay is pre-1.0 and maintained by a small team. Issues get read. Not every one gets fixed quickly, and a clear reproduction is the difference between a fix and a thread.