Two stdlib-only wrapper ops around the VIDGOD stack (gitea monster/vidgod):
click-to-cutout (SAM2.1+MatAnyone -> ProRes 4444 alpha) and clip-library
indexing (PySceneDetect + mlx-whisper). They shell out to ~/Documents/VIDGOD
bin CLIs, which carry their own venvs — no MODELBEAST venv or install script.
New optional manifest field requires_path: gates the LOCAL node on a path
existing (expanduser), so ops whose stack lives only on some boxes are not
grabbed by the primary. Remote nodes stay allowlist-gated via nodes.json
(vidgod_* allowlisted on m1/ultra only for now).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- jobs.node column (migration) written at dispatch: placement was held only
in runner memory, so every job rendered as the primary and busy remotes
showed idle in fluxgod
- sysinfo.nodes_detail() joins running jobs on jobs.node; legacy NULL rows
still credit the primary. gpu_pool() now derives busy from the inflight
counters instead of the dead busy key (set once at load, never updated)
- /api/nodes endpoint exposing the per-machine view
- local pool node named after its host (m3ultra), not "local"
- /api/assets?parent_job= filter actually filters now (was accepted and
silently ignored; callers got the whole table)
- tests/test_node_reporting.py: 8 framework-free checks incl. the captured
/api/nodes contract fluxgod consumes
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The gpu lane is now a pool of nodes -- this Mac plus any remote workers in
nodes.json (gitignored, primary-only). A gpu job acquires the first free node
that supports its operator; local runs as before, a remote node has its inputs
rsynced out, runs the operator's run.py over ssh (keys sourced from the node's
.env.remote, kept off the process table), then its outputs are rsynced back and
registered locally exactly as for a local job. One job per node (one Metal
device each).
- server/remote.py (new): node loading, cached health checks, prepare/cmd/collect
- runner: _acquire_gpu_node + a remote branch in _run_job. lane_of now treats
'gpu' as a real lane -- it was dropped from LANE_LIMITS (which holds only the
semaphore lanes cpu/net), so gpu jobs were silently falling back to the cpu
lane and the pool was never reached. A node is reserved before the health
await so two concurrent jobs can't grab the same one.
- sysinfo: gpu lane capacity = pool size, plus per-node status for the dashboard
Verified: all 7 gpu operators route to the pool; remote_cmd/node_supports and
nodes.json parsing correct; acquisition is race-free; a scratch-DB server boots
clean and logs the pool.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
