Net.Listen pattern — HTTP request in, output out — appears in
the Quickstart section of the SDK reference; these
recipes build on it. They lean on the localhost transport numbers documented in
Remote control.
A WebSocket remote
Net.WSListen is the same idea over a persistent connection. Use it when you need
push events (server to client) or a low-latency channel for high-frequency
commands. The server handles multiple clients, broadcasts to all of them, and
reacts to each message within a single tick.
websocket-client:
Net.WSListen can expose arbitrary JSON-RPC surfaces — reads (screen pixels,
window state, clipboard, input state), writes (HID commands), and push
subscriptions (mouse position, window changes, input events) compose with the same
handler. For the official typed, auto-reconnecting clients, see
Remote control.
A screen-condition trigger
Screen.GetPixelColor samples a pixel; Screen.SearchForColor scans a region.
Polling them on a tick gives you a desktop-automation trigger: act when a known
visual state appears. This recipe watches a fixed point on screen and fires a
keystroke when a build indicator turns red — the kind of thing you’d wire into a
CI dashboard, a long-running render, or an accessibility cue.
Screen and Window are limited or absent on Linux; see
Platforms & limits.
Screen.SearchForColor instead of a fixed point when the indicator can move:
A timer-driven task
Timer.Every runs a callback on a fixed interval without blocking the input loop.
This recipe nudges the cursor a few pixels every few minutes to keep a workstation
from idling during a long unattended job, with a hotkey to toggle it.
A sidecar over shared-memory IPC
Keep the perception and decision loop in your own process, with your model and your stack. When the sidecar decides what to do, it hands the decision to Rebind overPipe (shared-memory IPC, Windows-only) and the script emits the movement as
standard USB HID. The sidecar never touches the hardware; the script does,
deterministically, at up to 8,000 Hz.
Pipe is the low-latency path for a co-located process. For anything on the
network or off-Windows, use the HTTP or WebSocket recipes above.
0) and reads from channel B
(offset size / 2), so the peer does the inverse — it writes into channel B and
reads from channel A. Each channel is framed as [u64 seq][u32 len][payload]
(little-endian); the writer lays down the payload and length first and bumps the
sequence number last, so the reader only acts on a complete frame. In Python: