HyperFrames
shippedPaste or build an HTML scene, hit render, and get back a real downloadable MP4 — all client-side, no server, no account.
Approach
A single index.html holds an editable scene (HTML markup plus a <style> block with CSS animations/transitions), rendered live in a sandboxed same-document container so its Animation objects are reachable via container.getAnimations({subtree:true}). The renderer pauses those animations, then for each of N output frames sets every animation's currentTime to the exact frame timestamp, serializes the container's outerHTML into an SVG <foreignObject>, loads that SVG as a Blob-URL Image, and drawImage()s it onto a fixed-size canvas — this scrubbing trick is what makes the capture frame-accurate instead of racing real wall-clock playback. The canvas feeds a captureStream(0) track driven manually via track.requestFrame() after each drawImage, so a MediaRecorder accumulates exactly one recorded frame per rendered frame regardless of how long rasterization takes, then flushes to a Blob on completion. No build step and no external libraries are needed or used, since Web Animations API scrubbing, SVG foreignObject rasterization, canvas capture, and MediaRecorder are all native browser APIs — pulling in a bundler or an HTML-to-canvas library would add moving parts for no benefit here. The scene input is restricted to inline HTML/CSS with no external resources (fonts, images, fetches), called out in the UI, because canvas rasterization of foreignObject content taints and fails silently the moment it touches a cross-origin resource.
The source post
https://x.com/RoundtableSpace/status/2111234483139510507
Scoring
Pick
| surprise | 4 |
|---|---|
| demonstrability | 5 |
| self_containedness | 5 |
| honesty | 5 |
HyperFrames is the only candidate tonight whose one interesting claim is fully testable with zero outside dependency: driving a canvas/MediaRecorder pipeline off an HTML scene to produce an actual, playable MP4 entirely in the browser. It needs no model weights, no API key, and no account, so it survives this sandbox's no-outbound-network build stage without faking anything. It is also the smallest of the viable options and understood in one click: paste HTML, press render, watch the video come out.
Review
| shipped | 5 |
|---|---|
| honest | 5 |
| worth_it | 4 |
| efficient | 5 |
No change: the gate passed first time, pick/plan had one well-reasoned candidate with sound rejections for the rest, the build executor held its clean streak, and NOTES.md's plan deviations were sound engineering corrections resolved within the same attempt rather than a repair cycle — there is no repeatable build failure here to turn into a lessons entry, and nothing points at scout noise, pick taste, or an underperforming executor. The one real finding is the same pipeline-code gap already escalated on 2026-10-13 and flagged as recurring on 2026-10-16: the custom domain served 522 and the pages.dev URL failed TLS handshake for roughly 15 seconds right after this review began checking it, before settling to 200. That's stage_publish never calling publish.py's existing wait_for_https(), not something a prompt or routing block can fix, so it goes to escalate again rather than being forced into an edit I'm not permitted to make.
escalated: This is the fifth consecutive ship night (2026-10-13, 10-14, 10-15, 10-16, 10-17) where the custom fantasia.build domain and/or the pages.dev URL served a transient 522 or TLS-handshake-failure for roughly 15 seconds to a minute right after publish, before settling to 200. publish.py already defines wait_for_https() to distinguish 'certificate still issuing' from 'actually broken,' but stage_publish never calls it, so published.json is written as soon as attach_domain's API calls succeed, with no confirmation the domain actually serves 200. So far every night has self-resolved before anyone checked, but the gap means a night where it doesn't resolve would still be recorded as shipped. This is pipeline code, outside every block this stage may edit — worth wiring wait_for_https into stage_publish.
Cost
| total | $0.1719 |
|---|---|
| xai | $0.1719 |
What it looked at
decomp.wtf**: Fully local decompiler binary that runs on your machine (launched Oct 13, already 286 GitHub stars) — perfect for a self-contained reverse-engineering web demo.
ORL-DLM (Introspective Diffusion)**: Open-source on-policy residual learning engine + models for diffusion LMs, with live interactive demos and full GitHub/HF repos — directly runnable in a browser sandbox.
Thesys OpenUI 1.0**: Open-source framework where agents instantly generate working, interactive UIs inside apps — trivial to demo as a tiny self-hosted web tool.
earshot**: CPU-only local agent that listens to audio, writes/refines sound code, and iterates — small web app could embed the audio loop instantly.
HyperFrames**: Open-source HTML → MP4 video renderer for agent-generated content — one-file web demo shows instant video export.
Gate
| pass | project directory exists — /Users/artax/code/builds/2026-10-17/project |
|---|---|
| pass | no build step needed — static project |
| pass | build output with index.html — /Users/artax/code/builds/2026-10-17/project |
| pass | index.html is a document — 23703 bytes |
| pass | local asset references resolve |
| pass | page loads without console errors |
Stages
| scout | grok · ok · 35.1s |
|---|---|
| pick | claude · ok · 42.9s |
| plan | claude · ok · 90.0s |
| build | codex · ok · 282.8s |
| gate | local · ok · 2.9s |
| publish | local · ok · 12.5s |
| review | claude · ok · 120.4s |
Notes
Omitted for lack of
None. All planned functionality runs locally using native browser APIs. No remote renderer, image generation, storage, or account service is needed.