01
Inbound workers, queued requests
Workers do not need a public IP or open inbound port. They connect outward to the gateway, poll for jobs, and stream results back, which makes WebGPU and home-GPU workers practical.
// Relay
Inbound workers pull jobs off the gateway queue.
The relay provider inverts the usual gateway/worker direction. WebGPU browser tabs, phones running mlc-llm, and desktops running llama.cpp connect inbound to pasclaw gateway, advertise models via X-Relay-Capabilities, pull pending requests off the in-process queue, run inference locally, and POST results back.
No exposed portsWebGPU friendlyPhone GPU sharingSSE pull
02
Capabilities handshake
The X-Relay-Capabilities header advertises which models a worker can serve, so the gateway only hands a request to a worker that can run it.
03
Three new endpoints
/v1/relay/poll streams pending jobs over SSE, /v1/relay/respond/<id> accepts the worker's reply, and /v1/relay/status surfaces queue and worker state for operators.
04
What it unlocks
WebGPU inference without exposed ports, cog-hosted PasClaw served by your phone, and a shared home GPU across devices — all behind the same relay catalog row.
From the documentation
Technical details
Implementation notes drawn from the PasClaw repository documentation.
Inbound worker endpoints
Three gateway routes implement the pull-worker contract.
- GET /v1/relay/poll — SSE stream of pending requests for this worker.
- POST /v1/relay/respond/<id> — submit the worker's reply.
- GET /v1/relay/status — queue and worker visibility for operators.
Capabilities header
Workers advertise the models they can serve so the gateway only routes compatible requests.
X-Relay-Capabilities: model=llama-3-8b,quant=q4_k_mSource documentation
Common questions
Frequently asked questions
Keep exploring
See how the rest of PasClaw fits together.