MiniMax H3 (ComfyUI)

Local reference-to-video generation via ComfyUI on a single RTX 3090 — one real video produced, several ways to set the GPU on fire trying for a second one, and by 2026-08-11 a working 3-clip continuous-chain pipeline with real character consistency.

Goals

Take a free, community-shared ComfyUI workflow for MiniMax H3 (a newly-released video model, paired in the source workflow with LTX 2.3 and Wan 2.2 5B as optional upscalers) and get it running end-to-end, fully local, on the existing comfyui-local container. Dogfooded 2026-08-04 across several coding-agent runs, starting from a Patreon post advertising "12x faster" upscaling and ending in a paused experiment after a hard reboot, an OOM-killed process, and a wasted ten minutes of mouse-driven browser automation. Extended 2026-08-11 to a community "seamless chain" multi-clip workflow — chaining several H3 clips into one continuous shot with a persistent character.

Effectiveness

No longer just "in progress" — by 2026-08-11 this produces a genuinely usable multi-shot output: a 3-beat action scene (breach → ambush → resolution) rendered as one continuous 13.7s video with a consistent named character across all three clips, revised in a single iteration from direct creative feedback ("too static — nobody's reacting") into something with actual kinetic motion. The safe VRAM/host-RAM operating envelope from the 2026-08-04/05 incidents held throughout — no repeat crashes. Still not push-button (each new scene needs custom character refs and hand-tuned prompts), but the core pipeline is now trustworthy enough to iterate on creative direction rather than fighting infrastructure.

After-Action Report — 2026-08-04

Five incidents. One successful video. Here's what broke.

1. The full comparison workflow saturates a 24GB card by itself

What happened: The source workflow bundles a no-upscale baseline alongside LTX 2.3 and Wan 2.2 5B upscale branches in one prompt graph. Running it as shipped — all three branches loaded — pushed VRAM to 23.2GB/24GB at 100% utilization mid-sampling. The box became unresponsive and needed a hard reboot.

Why: MiniMax H3's own diffusion model is ~21GB int8-quantized before anything else loads. Its text encoder (Qwen3VL-8B/32B depending on variant) and VAE add several more GB on top. Adding an upscale stage to an already-maxed pipeline leaves zero headroom — there's no OOM error, just a system-wide freeze.

Fix: Run only the "no upscale" baseline branch; explicitly bypass the LTX/Wan groups so their models never load at all.

2. ComfyUI's own process leaked ~52GB of host RAM, independent of VRAM

What happened: Across several runs earlier in the day, the ComfyUI Python process's resident memory grew to ~52GB — on a 62GB box. Available RAM dropped to ~1GB, swap nearly filled, load average hit 27. The kernel OOM-killer fired and killed an unrelated claude process (confirmed in dmesg), which turned out to be this agent's own tool-call bridge — every MCP tool call started failing with generic connection errors, with no obvious link back to a GPU workload.

Why: Repeated generations without a container restart accumulate memory ComfyUI never releases. This is a host-RAM problem, not just a VRAM one — monitoring only nvidia-smi misses it entirely.

Fix: docker restart comfyui-local reclaims it immediately (confirmed: freed ~49GB in seconds, container back to healthy). Going forward, any generation-monitoring loop polls free -m alongside nvidia-smi, not GPU memory alone.

3. Ten minutes of mouse-driven browser automation, zero progress

What happened: A coding subagent, working from the ComfyUI web UI instead of its HTTP API, spent about ten minutes repeatedly panning/dragging the node-graph canvas with agent-browser mouse commands and taking screenshots — never actually queuing a job. GPU sat idle the entire time; from the outside this looked identical to a genuine hang.

Why: ComfyUI's web canvas is not built for reliable programmatic navigation — coordinates drift, screenshots require visual inspection to interpret, and there's no feedback loop confirming an action landed until something is queued (or isn't).

Fix: ComfyUI exposes everything needed via HTTP (/prompt, /queue, /history, /object_info, /interrupt) and the container filesystem. window.app.graphToPrompt() via a single one-time browser eval is a legitimate way to dump a loaded workflow's JSON — but that's the only acceptable UI touchpoint. Everything else — editing the graph, swapping reference images, submitting jobs, monitoring — goes through curl/API, never the canvas.

4. The safety valve was tuned more conservatively than the model's actual proven envelope

What happened: After incidents #1 and #2, a hard VRAM interrupt threshold of 21,500 MiB was set for all future runs. The next attempt — using the correct no-upscale-only branch, correct API-only approach — got cleanly through model load and into the actual sampling step, then crossed 21,500 MiB (peak: 22,631 MiB) and was auto-interrupted. No crash, no video either.

Why: The threshold was picked as a round, cautious number after the incident #1 freeze, without reference to what this specific (correct, no-upscale) branch actually needs. It turned out the identical branch had already completed successfully earlier in the day at a similar or higher peak, on the same card, with headroom to spare (24,576 MiB total).

Fix: not yet applied — flagged for the next attempt: raise the ceiling to ~23,000–23,500 MiB (still >1GB under the card's total) now that a real peak-VRAM data point exists for this specific workflow, rather than re-guessing a round number.

5. Two coding-agent contexts worked the same GPU task without either one noticing the other

What happened: A subagent spawned for this task and the coding agent's own persistent WhatsApp session both ended up independently monitoring/interrupting jobs against the same ComfyUI instance mid-session, each initially assuming a "mystery third process" was responsible for an over-threshold job neither of them had queued.

Why: Orchestration hygiene, not a ComfyUI problem — a subagent's completion wasn't confirmed before letting a second, longer-lived agent context pick up related work on the same resource.

Fix: Explicitly stand down one context before handing a shared GPU resource to another; don't let a persistent session and an ephemeral subagent operate on the same container concurrently.

Systemic observations

A model this large leaves no margin for guessing. At ~21GB base weight alone, MiniMax H3 on a 24GB card means every additional GB — an upscale branch, a second concurrent process, an unrelated app's VRAM use — is the difference between "works" and "hard reboot." Safety margins need to be measured against real peak-usage data, not picked as a round number in advance.

Host RAM is as real a failure mode here as VRAM. GPU-focused monitoring (nvidia-smi alone) missed the actual incident that took down agent infrastructure — the OOM-killer took a completely unrelated process with it. Any GPU workload doing sustained container work needs both watched together.

Deterministic interfaces aren't optional for this kind of work. The single biggest time sink of the day (ten minutes, zero output) was mouse-driven browser automation standing in for what a single curl -X POST /prompt call does reliably. If a tool exposes an API, use the API — full stop.

After-Action Report — 2026-08-05: Krea-2 → H3 combined pipeline

Goal: Chain Krea-2 Turbo (text-to-image) into MiniMax H3 (image-to-video), with the two models never resident in VRAM at the same time. Workflow saved to ~/code/comfyui-local/krea2_to_h3_pipeline.json.

A single combined graph does not enforce the flush — verified, not assumed

What happened: The first attempt built one ComfyUI graph: Krea-2 chain → easy clearCacheAll (VRAM flush) → H3 image-to-video chain, with the flush node's "anything" input wired to the Krea-2 output image so the flush would sit on the data path. Submitted via /prompt, the job was interrupted mid-run at the MiniMaxH3ImageToVideo node. Checking /history afterward: nvidia-smi showed ~22.2GB VRAM stuck in use with zero jobs running — the H3 CLIP loader (32B, ~16-20GB) and both H3 VAEs had already loaded before the flush had actually freed the Krea-2 models.

Why: The flush node only had a data dependency on the Krea-2 image (to enforce it ran after that stage). The H3 model loader nodes (UNETLoader, CLIPLoader, VAELoader ×2) have no free-form data inputs at all — they only need to feed MiniMaxH3ImageToVideo alongside first_frame. ComfyUI's scheduler is free to run independent branches in any order relative to the flush, so it started loading H3's CLIP encoder while Krea-2's models were still resident (or before the flush had actually released them). One flush node on one edge of the graph does not constrain the rest of the graph — verify execution order via /history's executed list rather than assuming a passthrough wire is sufficient.

Fix: docker restart comfyui-local to reclaim the stuck ~22GB (confirmed instant, matches incident #2's fix). Then split the pipeline into three separate /prompt API calls instead of one graph: (1) Krea-2 → SaveImage, (2) a standalone flush-only prompt (LayerUtility: PurgeVRAM V2, purge_models=True, purge_cache=True), (3) H3 stage with a LoadImage reading the file SaveImage wrote in stage 1 (copied from the container's output/ to input/ via docker exec cp — no live graph link needed). This makes non-overlap structural: each /prompt call is a separate execution: nothing from stage 1 stays loaded once its call returns. Confirmed via nvidia-smi: 19,208 MiB before the standalone flush → 2,090 MiB after. That's the number to check, not just "the node ran."

Aside: easy clearCacheAll/LayerUtility: PurgeVRAM V2's wildcard (*-typed) anything input rejects bare literals in the API — {"anything": 0} fails validation with a confusing value_not_in_list error. It must be wired to a real node's output slot (e.g. a PrimitiveInt node), even for a throwaway value.

Peak resource data from the successful run

A curl-piping gotcha nearly caused a false "still running" diagnosis (2026-08-05)

What happened: Polling /history/<prompt_id> by piping curl's stdout straight into python3 -c "... sys.stdin" produced a JSONDecodeError: Invalid control character and made a completed, successful job look like it was still running for ~7 minutes of wasted polling.

Why: matches the standing note on this box that piping curl through other commands gets mangled by a shell hook. curl -s -o file then reading the file separately avoided it every time.

Fix: always curl -s -o /tmp/x.json <url> then parse the file — never pipe curl's stdout directly into another process on this host.

After-Action Report — 2026-08-11: the "seamless chain" multi-clip workflow

Goal: move past single 5-second clips to a community-shared multi-clip "seamless chain" workflow (credited to seitanism on the Banodoco H3 thread) that chains up to 6 H3 clips into one continuous shot, carrying a character's face/body reference and motion context forward from clip to clip. First real test: a 3-beat action script (airlock breach → biomech ambush → resolution) with one named trooper character across all three beats.

The creator's own field notes turned out to matter more than the workflow JSON itself

What happened: The shared workflow arrived as a raw ComfyUI UI-graph export (nodes/links, not API format), plus a wall of prose from the creator explaining why it's built the way it is — seed-fixing strategy, sampler choice, a script-substitution trick, and a reference-image gotcha. All four turned out to be load-bearing on the first real run:

Why it matters: none of this is discoverable from the graph JSON alone — a bare UI-graph export has widget values and node wiring, but the reasoning behind those values (why this seed strategy, why this sampler) lives only in the accompanying human writeup. Treating a shared ComfyUI workflow as "just a JSON file to load" would have thrown away exactly the information that made the first attempt work on the first real try.

Duplicate-work detection saved a render cycle

What happened: A second sub-agent, dispatched to run the same 3-clip chain, checked the container's own output directory before queuing anything and found an identical render (same character, same script, matching checksum) already completed roughly 10 minutes earlier by a prior run. It verified the existing file instead of re-rendering — skipping ~2.5 minutes of GPU time plus another ~1 minute of reference-image generation.

Why it matters: on a single-GPU box running multiple agent contexts, "check whether this was already done" is cheap insurance against wasted GPU-minutes, and cheaper than the render itself.

Direct creative feedback closed the loop in one iteration

What happened: The first finished 3-clip chain was technically correct — consistent character identity across all three beats, no VRAM incidents, right runtime — but drew immediate feedback: "the videos are too static... nobody's running or crouching, not reacting... the enemies are like inanimate magnets." A revision pass rewrote all three clips' prompts from posed-tableau language ("troopers push through, weightless and drifting slightly") to continuous-motion-and-reaction language (troopers "diving and scrambling," drones "scuttling, lunging, thrashing in bursts of sparks"), and separately bumped the motion-context frame count from 22→39 on the continuation nodes.

Why it matters, and the one process mistake: the prompt rewrite and the motion-context bump both went into the same re-render, so the resulting improvement — genuinely more dynamic, reactive footage — can't be attributed to either change individually. Next time either change matters enough to isolate, run one variable at a time.

Systemic note

The 2026-08-04/05 VRAM and host-RAM safety margins (see above) held for the entire multi-clip chain — no OOM, no interrupt, no reboot — which is the first real evidence those fixes generalize beyond the single-clip case they were tuned against.

After-Action Report — 2026-08-14: fl2va (first-last-frame) candidate workflow

Goal: try a new community-shared H3 variant workflow (an "Image to Video (MiniMax H3)" subgraph, source) built around minimax_h3_fl2va_pruned_int8_convrot — a first-last-frame-to-video-audio checkpoint, distinct from the ref2va checkpoint every prior H3 test on this rig has used. first_frame/last_frame are both optional inputs on the underlying node, so with neither wired this runs as pure text-to-video — a genuine mechanics smoke test, not a reproduction of anyone's reference footage.

The workflow needed more than the four models it advertised

What happened: the workflow's own markdown note listed four models (the 20.97GB fl2va unet, its paired int8_convrot video VAE, an audio VAE, and the qwen3vl_32b text encoder) — all four checked out and only the unet needed downloading. But the collapsed subgraph also stacked two turbo LoRAs (minimax_h3_fl2v_turbo_4step_v1.0_768p_comfyui_bf16.safetensors, minimax_h3_turbo_v4_step600.safetensors), neither of which existed on this rig or in the official Comfy-Org/MiniMax-H3 repo. A web search turned up both — one in lightx2v/Minimax-h3-Turbo, the other in larryvrh/MiniMax-H3-Turbo-Lora — 2GB and 780MB respectively, filenames matching exactly.

Why: community workflows tend to document only the headline model in their own notes, not every LoRA riding along inside a collapsed subgraph — the four models advertised up front weren't the whole story.

Fix: treat "confirm the models exist" as a full-graph audit against every node's widget values, not a checklist against whatever the workflow's own markdown note claims. Also needed one missing custom node, VRAMCleanup (from LAOGOU-666/Comfyui-Memory_Cleanup) — source scanned clean (no eval/exec/network calls), installed via docker cp, no Dockerfile rebuild needed.

Two more nodes weren't available at all — bypassed, disclosed rather than silently skipped

What happened: the subgraph also wired a SolAttnPatch node (already set to bypass mode in the shared JSON — a genuine no-op, nothing to do) and an active DaSiWa_RTX_UpscalerRefiner node sitting between the video decode and CreateVideo — a 3-pass denoise/deblur/upscale node from darksidewalker/ComfyUI-DaSiWa-Nodes that depends on the proprietary NVIDIA RTX Video SDK.

Why: installing an SDK-gated closed-source dependency blind, under time pressure, to exercise a bonus quality pass that isn't core to "does the fl2va checkpoint run" wasn't worth the risk on a shared box already juggling tight VRAM/host-RAM margins.

Fix: wired VAEDecodeTiled's image output straight into CreateVideo, skipping the upscale/refine pass entirely — the same behavior ComfyUI's own bypass mode produces for a simple image-in/image-out node. Output is therefore the raw 960×544 H3 render, not the 1920×1080 the shipped workflow would have produced. Flagged here as a known gap for next time, not folded in silently.

VAEDecodeTiled crashes on this VAE variant — plain VAEDecode doesn't

What happened: the first full run (all four core models, both turbo LoRAs, low_vram=true forced per this rig's standing rule regardless of the shared workflow's own false default) executed cleanly through model load, the LoRA stack, and sampling — then died at VAEDecodeTiled with TypeError: to() received an invalid combination of arguments - got (NestedTensor), deep inside comfy/ldm/minimax/vae.py's decode() (latents_mean.view(...).to(z), where z arrived as a NestedTensor instead of a plain tensor). Everything upstream had already executed and was cached.

Why: this checkpoint's int8_convrot VAE's tiled-decode path doesn't handle the NestedTensor batching this model produces — a real bug in the shared workflow's own choice of decode node, not anything specific to this rig.

Fix: swapped VAEDecodeTiled → plain VAEDecode and resubmitted; upstream sampling reused from cache, no re-render needed. Completed clean, peak VRAM 23,117 MiB — under the 23,250–23,500 ceiling documented above. If revisiting this workflow, don't reuse its VAEDecodeTiled node as shipped; it doesn't work with this checkpoint on this ComfyUI version (0.31.1).

Result

Output: video/mmh3_fl2va_candidate_plaindecode_00001_.mp4 — 960×544, h264 + aac stereo, 5.167s (124 frames @ 24fps), 6-step turbo sampling, no upscale pass. Visual quality was clean on the first working attempt: a spacesuit-cosplay salute scene with a legible on-costume name patch, coherent convention-crowd background, no melting or artifacting. Audio: ~3s of silence followed by ~2.1s of audio landing roughly where the scripted dialogue line sits — a real improvement over the "gibberish audio across the entire clip regardless of prompt" behavior documented in the 2026-08-08 Turbo LoRA entry above. One data point isn't enough to call that fixed, but it's the first sign this isn't universally broken.

A second same-day test, prompted with a winged jaguar leaping from a jungle tree, came out equally clean — this one became the basis for the chain-graft experiment below.

Systemic note

Confirms the running pattern: a shared ComfyUI workflow is never "download 4 files and go" — check every model referenced anywhere in a collapsed subgraph, not just the ones named in its own README note, and expect at least one node to be either missing, deliberately bypassed, or quietly broken on a specific checkpoint variant. /history verification (and this time, the executed prompt embedded directly in the output MP4's own container metadata) is what confirmed both the low_vram override actually reached the node and the VAE-decode swap actually took effect — never trust that an override or edit landed without checking after the fact.

Fixed single-clip workflow: gist.

After-Action Report — 2026-08-14: fl2va chain-graft experiment

Goal: the fl2va checkpoint above natively takes optional first_frame and last_frame inputs — exactly the mechanism a clip-chaining pipeline needs for continuity (feed clip N's last frame into clip N+1's first frame). The existing seamless-chain pipeline (2026-08-11, above) achieves continuity a different way entirely: MiniMaxH3MotionContext/MiniMaxH3MotionContextTrim pin raw sampler-output latent windows from clip N directly into clip N+1's conditioning, no decode/re-encode round trip, plus a separate static-image identity anchor via MiniMaxH3ReferenceToVideo re-fed into every clip. Question going in: is fl2va's native handoff a better or simpler continuity mechanism, or does ref2va already do this better and this would just be redundant?

The graft itself worked cleanly

What happened: grafted the fixed single-clip fl2va graph (plain VAEDecode, forced low_vram, upscaler bypassed) into the chain pipeline's per-clip structure: extract each clip's last decoded frame via ffmpeg, docker cp it into the container's input/, wire it into the next clip's MiniMaxH3ImageToVideo.first_frame — the same filesystem-handoff pattern already used by the Krea-2 → H3 pipeline (2026-08-05, above). Rendered a real 3-clip chain continuing the cosplay/jaguar test above: leap → land → dive, 960×544, 124 frames/clip (~5.17s each, 15.5s combined). VRAM peaked at 23,415 MiB (clip 2), under the documented ceiling; no restart needed.

Why it matters: /history confirmed first_frame was genuinely linked to the LoadImage node on every submission, not silently dropped — the standing subgraph-parameter-override gotcha didn't bite here.

Result: quality was excellent. Each cut was frame-perfect (the same still re-injected exactly), and the model picked up the described continuing action (glide → land, then crouch → roar → dive) coherently, with character identity (wing/coat pattern) holding across both links.

Honest verdict: not a strict upgrade, don't replace the existing chain

What happened: fl2va's still-frame handoff is real and simpler than the existing chain's approach, but structurally weaker on inspection. It carries forward a single still image with no velocity or motion-trajectory information — the model reinvents motion from scratch at each cut, which only read as coherent here because the prompts explicitly spelled out the continuing physical action. It also costs a decode → re-encode round trip per seam, exactly the overhead MotionContext's raw-latent (context_latent) path is built to avoid, and it has no persistent per-clip identity-reference anchor the way ref2va's repeated reference-image wiring provides. Camera framing also jumped more between clips than true latent-context carryover would be expected to produce.

Why: /object_info confirms MiniMaxH3MotionContext takes generic CONDITIONING+LATENT inputs, so it's technically compatible with fl2va's MiniMaxH3ImageToVideo output too — a genuine latent-context graft onto fl2va is possible in principle, but that's a different, more invasive change than what was tested here, and wasn't attempted.

Recommendation: keep the ref2va + MotionContext seamless chain as the default for real multi-beat work. fl2va's native first/last-frame handoff is a legitimate lightweight option worth keeping around for quick 2-clip bridges or stitching independently-generated stills — not a replacement for the chain pipeline's continuity mechanism.

Systemic note

Grafting a checkpoint's native feature onto an existing pipeline is worth investigating on its stated merits, but "the model has a mechanism for X" doesn't mean it's a better X than what's already there — this is the second time on this rig (after the Krea-2 → H3 non-overlap question, 2026-08-05 above) that verifying an assumption via /history//object_info rather than taking a plausible-sounding shortcut at face value changed the actual recommendation.

Chain-graft reproducibility files: gist. Combined output, all three clips (leap → land → dive, 15.5s):

After-Action Report — 2026-08-23: attention-acceleration stack experiments vs. the Reddit consensus

Context: r/StableDiffusion's "Which Minimax H3 has the best balance of quality and speed node?" (u/dassiyu, RTX 5090, 2026-08-23) crowdsources six acceleration combos — Sage Attention, ComfyUI-Kitchen's native attention, Spectrum's step-skipping, Sparse Attention (SLA), and 4-step Turbo LoRAs, stacked in various combinations — and lands on Sage+4-step-Turbo as the practical daily driver, with CK+Spectrum at 19-25 steps as the quality ceiling for anyone willing to wait. Top comment: Turbo LoRAs are "disappointing... very plastic skins" on a 5090. This rig has been running variants of exactly that acceleration-node space for three days straight, so here's where the two compare.

Two of three attention-stack experiments were a wash, same as several commenters found

What happened: feature/h3-sla-sparse-attention-test (a sparse-attention node layered after the turbo LoRA) and feature/h3-sage-sol-attention-test (SageAttn + Sol-Attn sparse patch, itself sourced from a different Reddit workflow) were both built, rendered, reviewed against this rig's documented 78.1s / 22,403 MiB turbo-LoRA-only baseline, and merged for the record — then archived out of the active workflows/ set the same day. Verdict: "a wash, not a win."

Why: consistent with u/Radiant-Photograph46's top comment on today's thread ("Turbo LoRAs have been disappointing for me. Very plastic skins") and u/marres's ("I never got good enough quality with any speed-up LoRA") — this rig found the same pattern from the acceleration side. Stacking a sparse-attention node on top of an already-fast turbo pipeline didn't buy enough quality or speed to justify the added moving parts.

Fix: neither combo shipped to production workflows. The plain turbo-LoRA baseline, with no extra attention stack at all, remains this rig's actual daily driver — the same conclusion several commenters reached independently on a different card.

Chasing a bigger Reddit claim (30s single-shot) surfaced a failure mode nobody in today's thread mentions

What happened: a separate, earlier post ("Minimax H3, 30 seconds in one go", u/Altruistic_Dealer_59, RTX 3090, claiming 570s for a single-prompt 30s render via ModelAttentionBacked→SolAttn→Spectrum→turbo-LoRA) got the full reproduction treatment. ModelAttentionBacked doesn't exist on this box's pinned ComfyUI core, so the SolAttn+Spectrum+turbo half of the stack was isolated and tested at 5s (control) and 30s (the actual claim), everything else held identical. The 5s control ran clean: 103.16s, valid h264+aac output — about 32% slower than the unaccelerated 78.1s baseline, i.e. pure overhead at this duration, not a win. The 30s arm reproducibly crashed the host, twice, with the kernel OOM-killer firing at roughly 50GB resident RAM during audio/video VAE decode — confirmed via dmesg and docker logs, not inferred, and it took an unrelated awk process and an unrelated fly process down as collateral damage before finally killing ComfyUI's own process.

Why: this is host system-RAM exhaustion, distinct from every VRAM-side OOM this rig has hit before — GPU monitoring alone would have missed it entirely. Source-level tracing (not another render attempt) then confirmed VAEDecodeTiled is a no-op for this specific VAE: its decode_tiled() silently discards every tiling parameter it's given and calls plain decode() anyway, so the standard tiled-decode mitigation for long-duration video VAEs simply doesn't apply here.

Fix: none yet. A follow-up branch tried the model's own native long-duration answer — ComfyUI-MiniMax-H3-LongMedia's segmented-continuation architecture — instead of bolting external attention patches onto a monolithic decode. That turned out to be architecturally incompatible with SolAttn+Spectrum (LongMedia installs its own per-block attention wrapper that silently discards SolAttnPatch's forward hook, so the "SolAttn" half of the stack becomes dead code without any error). A second attempt using LongMedia's native segmentation on its own terms hit a different, pre-existing bug instead: two unrelated custom-node packages (ComfyUI-H3-Multishot, ComfyUI-ALLinONE-MinimaxH3) both monkeypatch comfy.model_base.extra_conds globally and collide, crashing 95 seconds in with KeyError: 'latent' before any segment even sampled. Three branches, three different blockers, zero working 30-second single-shot H3 renders on this rig so far.

Where we stand

Today's Reddit thread is faster and more practically useful than this rig's own process for the question it's actually answering: six real users converging on hands-on speed/quality impressions in a single afternoon. This rig's approach — hypothesis and dependent variables written down before rendering, N=1 explicitly disclosed as a spike rather than a claim, root cause traced to a specific kernel log line rather than a felt impression — produces more defensible individual data points, but three attention-acceleration experiments in a row here have landed on "wash" or "crash," while several commenters today (u/glusphere: SLA + 4-step turbo stacked with 6/3 sampling shifts, under 4 minutes for 1MP/15s on a 5090) report combos that just work for them. Rigor hasn't yet bought this rig a working acceleration stack the community doesn't already have informally. The open move, flagged in the last branch's notes and not yet started, is evaluating LongMedia's own native attention/memory-guard stack on its own terms rather than continuing to bolt external SolAttn/Spectrum patches onto it.