WOL for selfhosted folks

[george1612]

Hi @DevEmperor, what are your thoughts on this topic:

#189 (comment)

[DevEmperor]

Answered by shipping it — #189 is closed and in the app since 5f9ca9d (4 Aug). Thank you again for the write-up and the prototype; describing the setup rather than just the request is what made it straightforward to build.

Settings → AI providers → your own server → "Wake before rewording", off by default. It sits with the server it belongs to and only appears for endpoints of your own — everywhere else there is no machine to wake.

It fires when a rewording is certain to follow, as early as that is knowable: at the start of a recording that will end in one (auto-formatting on, or a prompt set to apply itself), and when you tap a prompt. That gives the machine the whole length of your dictation to boot in, rather than racing the request you are already waiting for. Nothing fires for a plain transcription — your cloud-STT-in-front-of-a-local-GPU case was exactly the reason for that. Throttled to once a minute, fire-and-forget: a failure is the case this exists for, so it never reaches you or holds up a recording.

Where it differs from your proposal, and where that matters

It sends an empty GET /models rather than a magic packet.

For a box with an always-on front end — a reverse proxy, a small always-on host, Ollama parked in front of a sleeping GPU — that is the better shape: it needs no MAC address, no broadcast, and it works when the phone is not on the same L2 segment, which is most of the time. Mobile data, a guest VLAN, a VPN — a broadcast magic packet never arrives in any of those, and Android's handling of UDP broadcast from a backgrounded app makes it worse. /models is answered by every OpenAI-compatible server, so it also needed no per-user configuration beyond one switch.

But it does not cover the case you may actually have. If the machine is asleep with nothing listening — no front end, only the NIC awake waiting for a magic packet — then an HTTP request has nobody to answer it and only Wake-on-LAN will do. That case is genuinely not solved, and I would rather say so than let this thread close on the impression that it is.

So: if that is your setup, say so here and I will reopen for the sender specifically. The hard part is already done and in main — the trigger points, the "is a rewording actually coming?" logic, the throttle, the per-server switch. What would be left is the packet itself and a MAC field, which is close to the standalone piece you sketched.

Closing this as resolved since the thoughts you asked for are now on the record and the shipped half is testable. Reopening for the WoL sender is one comment away.