Add a demo GIF to the README - #24
Conversation
Shows the whole heal loop in one take rather than a --help screen: a supervised training run hits a CUDA OOM, the oom pattern detector fires, the oom_halve_batch rule restarts the child with BATCH_SIZE halved from 8 to 4, the rerun completes, and the incident lands in the ledger. Three beats — the run, a grep of the process log proving batch 8 crashed and batch 4 finished, and `autosentry incidents list` for the paper trail. That's the README's own tagline (catch the failure, fix it, leave a paper trail) shown instead of asserted. The recording is a real run, not a mock-up: docs/demo/train.py genuinely OOMs at BATCH_SIZE >= 8 and genuinely succeeds below it, so the rule has an actual failure to fix. If the healing path regresses, re-rendering produces a GIF that visibly fails to heal. Source lives in docs/demo/ as a VHS tape plus the scenario files, so the GIF is regenerable when the CLI output changes rather than being an opaque binary nobody can reproduce. The tape records out of /tmp/autosentry-demo so the supervisor's absolute cwd= stays readable at GIF width and every take starts from clean state. 257 KB after gifsicle, 21s, 1000x720. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 26 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (6)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Adds the demo GIF at the top of the README, plus its regenerable source in
docs/demo/.What it shows
The heal loop end to end, not a
--helpscreen. Three beats:autosentry run— the child hits a CUDA OOM, theoompattern detector fires,oom_halve_batchmatches, and the supervisor restarts the child withBATCH_SIZEhalved. The rerun exits 0 andrestart_on_failureshuts the supervisor down cleanly.grep … process.log— four lines proving the fix worked rather than just that something restarted:batch_size=8→OutOfMemoryError→batch_size=4→training complete.autosentry incidents list— the paper trail, with the detector, rule, and action that fired.That's the README's own tagline — catch the failure, fix it, leave a paper trail — demonstrated instead of asserted.
It's a real run
docs/demo/train.pygenuinely runs out of memory atBATCH_SIZE >= 8and genuinely succeeds below it, so the rule has an actual failure to fix and the restart has an observable effect. Nothing is scripted to look like healing. If the healing path regresses, re-rendering produces a GIF that visibly fails to heal — the demo can't quietly drift out of sync with the code.One thing worth knowing:
BATCH_SIZEis exported as a real env var in the tape rather than set inprocess.env, because thehalfkeyword resolves its numeric base against the supervisor's environment (_apply_env_overrides), not the config. Setting it only inprocess.envmakeshalflog "no numeric base found" and no-op.Regenerable, not an opaque binary
docs/demo/holds the VHS tape and the scenario files, with regeneration steps in its README:PATH="$(make -s venv-info)/bin:$PATH" vhs docs/demo/demo.tape gifsicle -O3 --lossy=30 --colors 64 docs/demo.gif -o docs/demo.gifThe
PATHprefix is deliberate — the tape records whateverautosentryresolves to, and this machine had a stale 0.8.5 on the globalPATH, so without it the GIF would silently capture the wrong version. The recording runs out of/tmp/autosentry-demo(created and torn down inside the tape) so the supervisor's absolutecwd=stays short enough to read at GIF width and each take starts from clean state.Verified reproducible: rendered twice from scratch, same output modulo timestamps and pids.
Size
257 KB, 21s, 1000×720 — well under the 8 MB README budget.
gifsicle -O3 --lossy=30 --colors 64cut it 46% from the raw 469 KB with no visible quality loss (compared frame-for-frame; terminal text stays crisp).Docs and assets only — no source changes. Suite still 348 passing, lint/format/pyrefly clean.
🤖 Generated with Claude Code