DEV Community: Rodion Kazennov

Chaining image-to-video clips from the last frame: what 10 links did to a face (MiniMax-H3, measured)

Rodion Kazennov — Thu, 29 Oct 2026 05:07:26 +0000

For a dialogue scene I generated clips with MiniMax-H3, MiniMax's open-weights video model that can start from a given first frame, end on a given last frame, or both. To make one shot run longer than one clip, I started every clip from the last frame of the clip before. After ten clips the woman on screen no longer looked like the woman I had drawn:

Then I measured what each link did. People on forums describe this drift a lot (LTX-2.3, Wan, Seedance), but I didn't find numbers per link, so here are mine.

The setup

Model: MiniMax-H3, the first/last-frame checkpoint (FL2VA), run locally on an Apple Silicon Mac through a fork of h3.c, with an INT8 copy of the transformer and lightx2v's 8-step Turbo LoRA (fl2v_turbo_8step_v1.0_768p).
Every clip: 768x1344, 124 frames (5.17 s at 24 fps), 8 steps, seed 42.
Conditioning: a first frame only, no end frame. Clip 1 starts from a keyframe I drew. Every later clip starts from the previous clip's last frame:

ffmpeg -sseof -0.05 -i clip_n.mp4 -frames:v 1 -update 1 clip_n_last.png
# clip_n_last.png becomes the first frame of clip n+1

Three chains: A, 10 clips of a woman in an armchair; B, 7 clips of a man by a door; C, 9 clips of a woman with a phone. Each prompt gave the person on screen one line of dialogue (the model voices it too), and every prompt said "The camera holds a static shot" and "natural skin texture".

What I measured

On the first frame of each clip, which is the last frame of the clip before, I computed four numbers on the whole frame and divided each by its value on the drawn keyframe:

g = np.asarray(Image.open(path).convert("L"), np.float64)

lap = -4*g[1:-1,1:-1] + g[:-2,1:-1] + g[2:,1:-1] + g[1:-1,:-2] + g[1:-1,2:]
edge_sharpness = lap.var()                      # Laplacian variance

F = np.abs(np.fft.rfft2(g - g.mean()))**2
r = np.hypot(np.fft.rfftfreq(g.shape[1])[None, :], np.fft.fftfreq(g.shape[0])[:, None])
finest_detail = F[r > 0.25].sum() / F[r > 0.01].sum()   # energy above 0.25 cycles/px

contrast = (g / 255).std()
near_white = (g / 255 > 0.92).mean()            # share of pixels

Detail goes first

Finest detail dropped on the first link: 77 % of the keyframe in chain A and 80 % in chain B at the start of clip 2. It bottomed out at clip 4 (61 % and 65 %) and never returned to the keyframe's level: chain A ended at 65 %, chain B at 88 %.

Edge sharpness fell too at first, to 73 % and 82 % at clip 3, and then it overshot. From clip 5 on it was above the keyframe, and it reached 174 % in chain A (clip 9) and 159 % in chain B (clip 7). Detail wasn't coming back: the finest band stayed low. What rose were harder, coarser edges. On the shirts you can see it as a crunchy pattern that the keyframe didn't have.

Then the faces turn oily

Contrast rose with almost every link: by 14 % in chain A (clip 9) and 16 % in chain B (clip 7). Near-white pixels grew faster: from 0.20 % to 0.55 % of the frame in chain A, 2.8 times, and from 0.054 % to 0.124 % in chain B, 2.3 times. On a face this shows up as shine on the forehead, nose and cheeks. Up close:

The freckles from the drawing are gone by clip 4, the skin is glossy although every prompt asked for natural skin texture, and by clip 9 the bone structure has changed. I didn't score identity with a face-embedding model, so that last part is by eye.

One oddity: the first frame of chain A's clip 10 is brighter overall (mean luma up 10 %, saturation down 15 %), which pulls its contrast and near-white numbers back. I haven't looked into why.

Mistakes ride along

Chain C shows a different failure. At the end of clip 2 the model drew a chat bubble with made-up English over the frame, and since clip 3 starts from that frame, the bubble was in the scene from then on:

It stayed through the next seven clips, with the text inside it changing from clip to clip. The model treats whatever is in the conditioning frame as part of the scene. A last-frame chain has no way to drop it.

The rule I use now

When I watched the long chain, I saw smeared text on the phone and faces that looked oiled. Since then I work like this:

At most 3 clips in a row start from a previous clip's last frame. Then a fresh drawn keyframe.
If a new person or object enters, the clip still starts from the last frame, but it ends on a freshly drawn end keyframe: an edit of the start frame with the new detail painted in.
A face close-up or a new location always starts from a freshly drawn keyframe.

The cap of 3 is a judgment call, not a threshold the numbers found. In these two chains, the first three clips lose fine detail (to 66 % and 69 %), while contrast has barely moved (100 % and 106 %) and near-white pixels are up 16 % and 11 %. From clip 5 on, all four metrics move away from the keyframe together. You could argue for 2.

Check your own chain

The measurement needs only the PNGs you already feed the model. Compute the four numbers above for every first frame and divide by the keyframe. A falling finest-detail share with rising contrast is the pattern to watch for. Before you trust a long chain, look at the first, middle and last frame of every clip side by side. A contact sheet per chain would have caught the chat bubble at clip 3. I found it much later, in a rough cut.

These are two clean chains with one model, one seed and one resolution, and the metrics cover the whole frame while people move inside it. If you run the same check on another model, I'd like to compare curves.

Real-CUGAN on Linux vs Windows: same flags, two NVIDIA GPUs, SSIM 0.9977

Rodion Kazennov — Thu, 29 Oct 2026 05:05:53 +0000

I upscale short AI-generated clips to 4K with Real-CUGAN, the ncnn-vulkan build. Two laptops with NVIDIA GPUs can do the work:

	Windows laptop	Linux laptop
CPU, RAM	i7-13700H, 32 GB	i5-9300HF, 23 GB
GPU	RTX 4060 Laptop, 8 GB	RTX 2060, 6 GB
OS	Windows 11 (build 22631)	Arch Linux, kernel 7.2.9
NVIDIA driver	610.88	615.78.08
ffmpeg	8.1.3	9.0.2
realcugan-ncnn-vulkan	20220728 release	20220728 release

Before I split one video's clips between them, I wanted to know whether they give the same picture. If they didn't, a cut between two clips upscaled on different machines could show it.

The test

One clip, 768x1344 at 24 fps, 104 frames, went through the same steps on both machines: crop to an exact 9:16, write PNG frames, Real-CUGAN at 3x with the models-se weights and denoise level 0, Lanczos down to 2160x3840, then lossless x264. The Linux side:

ffmpeg -i "$src" -vf "crop=$cw:$h" -fps_mode passthrough in/f%06d.png
realcugan-ncnn-vulkan -i in -o up -s 3 -n 0 -g 0 -m models-se -f png
ffmpeg -framerate 24 -i up/f%06d.png -i "$src" -map 0:v -map '1:a?' \
  -vf scale=2160:3840:flags=lanczos -c:v libx264 -qp 0 -preset veryfast \
  -pix_fmt yuv420p -c:a copy -frames:v 104 out_4k.mp4

Windows runs the same three commands from Python, with one difference: -g 1. On that laptop GPU 0 is the integrated Intel chip, and -g 0 would run the upscale there.

The result

Both files have 104 frames. I compared them with ffmpeg's own filters:

ffmpeg -i windows_4k.mp4 -i linux_4k.mp4 -lavfi \
  "[0:v]split[a0][a1];[1:v]split[b0][b1];[a0][b0]ssim=stats_file=ssim.log;[a1][b1]psnr=stats_file=psnr.log" \
  -f null -

SSIM came out at 0.9977 (Y 0.9976, U 0.9978, V 0.9980) and PSNR at 54.2 dB. Frame by frame the range was narrow: SSIM 0.99758 to 0.99779, PSNR 54.00 to 54.45 dB. Nothing drifts over the clip.

A single score hides how the differences are spread, so I also counted the absolute difference of every Y, U and V sample, 1.29 billion of them:

75.5 % of the samples are identical, and 99.97 % are within one level out of 255. The largest difference anywhere is 5 levels, and only 5 samples reach it. The mean absolute difference is 0.25 of a level. Side by side at 100 % zoom I couldn't tell the two apart.

The core of the counting script, in case you want to run it on your own pair:

p = lambda f: subprocess.Popen(["ffmpeg", "-v", "error", "-i", f, "-f", "rawvideo",
                                "-pix_fmt", "yuv420p", "-"], stdout=subprocess.PIPE)
a, b = p(win), p(lin)
size = 2160 * 3840 * 3 // 2          # one yuv420p frame
hist = np.zeros(256, np.int64)
while (x := a.stdout.read(size)) and (y := b.stdout.read(size)):
    d = np.abs(np.frombuffer(x, np.uint8).astype(np.int16) - np.frombuffer(y, np.uint8))
    hist += np.bincount(d, minlength=256)

Where the difference comes from: not separated

The two sides differ in GPU, driver, operating system and ffmpeg version, all at once. The candidates are the floating-point math in the Vulkan shaders, on two GPU generations and two drivers, and ffmpeg's crop, Lanczos scaling and RGB to YUV conversion in two versions. The x264 step at -qp 0 is lossless; the only loss in that step is the conversion to yuv420p, which belongs to the ffmpeg candidate.

To split it, compare the PNGs that Real-CUGAN writes before the encode step. My pipeline deletes them after each clip, so I don't have that answer yet.

Speed, from the job log

I run these jobs with stageload, a small open-source tool that runs heavy jobs one at a time and logs each one's run time. Its log gives whole-job numbers: copying the clip over the LAN, extracting frames, upscaling, encoding and copying the result back. Divided by frame count:

Job	Machine	Frames	Run time	Per frame
Real-CUGAN 3x, 4K lossless out	RTX 4060, Windows	506 (one job, 5 clips)	515.5 s	1.02 s
Real-CUGAN 3x, 4K lossless out	RTX 2060, Linux	104 (one clip)	232.7 s	2.24 s
Real-ESRGAN x4plus, 4K lossless out	RTX 4060, Windows	73 each, 11 jobs	383 to 422 s, mean 401.5 s	5.50 s
Real-ESRGAN x4plus, 1080p out	RTX 2060, Linux	73 each, 3 jobs	542 to 558 s, mean 548.8 s	7.52 s

Read these with care. The Real-CUGAN rows are one job each, and the Linux job also ran a 4K lossless x264 encode on a CPU with 8 threads, limited to 4 threads at low priority. The Real-ESRGAN rows come closer to a GPU comparison, though not all the way, because the Linux jobs encoded to 1080p, the lighter encode. There the RTX 2060 laptop took 1.37 times as long. One two-clip Windows job took 3,374 s, far above the rest, and I left it out because I don't know why.

On the same Windows laptop, Real-ESRGAN x4plus (4x) cost about 5.4 times as much per frame as Real-CUGAN at 3x. I still use it for photoreal footage: Real-CUGAN is trained on anime, and on realistic faces it turned skin into painted strokes.

What I do now

Before I mix machines in one video, I upscale one clip on both and run the two checks above. If the frame counts match and the differences look like this histogram, the clips go to whichever laptop is free. The SSIM and PSNR pass took 11 seconds on my Mac for 104 frames at 4K. It catches setting mistakes, such as the wrong -g or a different denoise level, before they reach an edit.

"Resource provisioning failed" on Vercel previews: the Neon 10-branch limit, measured

Rodion Kazennov — Thu, 29 Oct 2026 05:05:46 +0000

My Next.js app runs on Vercel with a Neon Postgres database connected through the Vercel-managed Neon integration. In late October every preview deployment started to fail about a second after it was created. There was no build log at all, and production deployments kept working. Vercel showed one line:

BUILD_FAILED
Resource provisioning failed

The cause was the Neon free plan's limit of 10 branches per project. Below is how I confirmed it, how fast the project filled up again after I emptied it, and what to do before you delete anything.

Where Neon's reason shows up

With this integration, each preview deployment asks Neon for a database branch named preview/<git-branch>, a copy-on-write copy of the production branch. That request runs as an integration step before the build starts (Neon docs). The production branch counts toward the 10, so nine previews fill the project. When the project is full, Neon refuses the new branch and Vercel reports the whole step as "Resource provisioning failed".

The first time I hit this, in September, I found Neon's own reason in the deployment's integration actions, read through the Vercel REST API (GET /v1/deployments/<deployment-id>/integrations). The status text there said Branch limit reached. Counting the branches is faster:

npx neonctl branches list --project-id "$NEON_PROJECT" --output json | jq 'length'

# who made them and when
npx neonctl branches list --project-id "$NEON_PROJECT" --output json \
  | jq -r '.[] | [.created_at, .creation_source, .name] | @tsv'

If the first command prints 10 and most rows say vercel and preview/..., that's your answer. Other people on the Vercel community forum traced the same error to the same limit. Some threads report the error with free slots left, so check the count first. Don't assume it.

How fast ten branches fill

My repository gets a lot of short pull requests. In October, up to the 27th, 484 of the project's 851 Vercel builds were previews. Every new git branch that got a preview deployment also got a Neon branch.

On 28 October I emptied the project at about 05:02 UTC, leaving only production. This is what happened next:

Nine new preview branches appeared between 05:03 and 14:11 UTC, all with creation_source: vercel. The project was full again 9 hours 8 minutes after I emptied it. I deleted nine more at 18:29 to 18:31 UTC, and by 01:45 UTC the next morning five new ones had arrived.

The same cleanup came up every day that week. These are the preview branches I deleted by hand:

Day (UTC)	Preview branches deleted
24 October	9
25 October	6
26 October	3
27 October	5
28 October	9 in the morning, 9 in the evening

That's 41 branches in five days. The ones I looked at in the listing had each kept a compute endpoint active for about 300 seconds (active_time_seconds).

Merging the pull request doesn't free the branch

Every branch I deleted belonged to a pull request that was already merged, and its git branch was usually gone. With the Vercel-managed integration, Neon deletes a preview branch when the branch's Vercel deployments are deleted, and Vercel keeps preview deployments for 180 days by default (Neon docs). A merge doesn't delete deployments, so with that default retention the database branch stays for months.

Skipping the build doesn't skip the branch

My first fix was to stop building previews with Vercel's ignored build step in apps/web/vercel.json. The first version also cancelled a push to main, because VERCEL_ENV didn't read as production in that step. The second version tests the branch name:

// first try: also skipped production
"ignoreCommand": "[ \"$VERCEL_ENV\" != production ]"

// second try: build main, and any deploy whose branch is unknown
"ignoreCommand": "[ -n \"$VERCEL_GIT_COMMIT_REF\" ] && [ \"$VERCEL_GIT_COMMIT_REF\" != main ]"

The builds were skipped, but the database branches kept coming. All 14 branches in the chart were created after this step was in place. The integration step runs before the ignored build step, so a skipped preview still provisions its branch, and when the project is full it fails the same way. The ignored build step saves build minutes. It does nothing for the branch count.

Back up before you delete

A preview branch may hold data that a preview wrote, so I dumped each one before deleting it. One catch: pg_dump refuses to dump a server with a newer major version than its own (the error and the rule). My Neon project runs Postgres 17 and my Mac had pg_dump 16.15, so I installed the 17 client first. A loop like this one does the rest:

brew install postgresql@17
PG_DUMP="$(brew --prefix postgresql@17)/bin/pg_dump"   # 17.11 here

npx neonctl branches list --project-id "$NEON_PROJECT" --output json \
  | jq -r '.[] | select(.name | startswith("preview/")) | "\(.id) \(.name)"' \
  | while read -r id name; do
      uri=$(npx neonctl connection-string "$id" --project-id "$NEON_PROJECT")
      "$PG_DUMP" -Fc -f "backup/${name//\//__}.dump" "$uri"
    done

The preview branches I listed showed about 52 MB of logical size each, the same as production, since it starts as a copy. The nine dumps came to 27.7 MB in all, between 3.03 and 3.08 MB each, and finished 41 to 48 seconds apart. Only after that did I delete the branches, by id:

npx neonctl branches delete "$id" --project-id "$NEON_PROJECT"

The same limit breaks your CI

Before a schema migration merges, I rehearse it on a throwaway branch copied from production, then delete the branch. Reduced to its shape:

const created = neon(['branches', 'create', '--parent', MAIN, '--name', name]);
const id = JSON.parse(created.stdout).branch.id;
try {
  // prisma migrate deploy against the copy, then compare the schema
} finally {
  neon(['branches', 'delete', id]);   // also when a step fails
}

The finally keeps the rehearsal from leaking branches. It can't help when previews have taken every slot: on several days in the table the rehearsal failed at branches create until I cleared space by hand.

What stops the refill

Deleting branches only buys hours. The setting that stops the refill is in the integration: Neon's docs describe a "Create database branch for deployment" choice with Preview and Production boxes when you connect the project. With Preview off, a preview deployment gets no branch of its own, so check which DATABASE_URL your Preview environment uses then. It must not be production. Two other levers: shorten Vercel's retention for preview deployments, so the branches go with them, or delete the branch from CI when the pull request closes.

I haven't measured the fix yet. At 01:45 UTC on 29 October preview branching was still on and the project had 6 of 10 branches. My next step is to switch it off and check that the count stays at 1.

Checklist

1. neonctl branches list | jq length     -> 10 means the limit, not your code
2. pg_dump at the server's major version  -> back up the preview branches
3. delete by id, previews of merged PRs only
4. turn off "Create database branch for deployment" for Preview,
   or shorten preview retention, or delete branches on PR close
5. leave slots for CI throwaway branches

MPS backend out of memory: the "max allowed" number on every Mac size

Rodion Kazennov — Sat, 24 Oct 2026 20:02:36 +0000

The PyTorch error on a Mac carries one number that people search for. This one is from a 16 GB Mac (AudioLDM2 #20):

RuntimeError: MPS backend out of memory (MPS allocated: 18.02 GB, other allocations: 107.10 MB, max allowed: 18.13 GB). Tried to allocate 4.50 MB on private pool.

In my earlier note I measured where it comes from on my 48 GB Mac. "max allowed" is PYTORCH_MPS_HIGH_WATERMARK_RATIO, 1.7 by default, times the GPU working set macOS recommends, which torch.mps.recommended_max_memory() returns. One machine can't tell you what that number is on the others, so I read it off other people's errors.

Where the numbers come from

On 24 October I searched GitHub for issues that quote the error with its "max allowed" value. That gave 250 issues and pull requests, 167 of them with a number in the text. Most values fall into a few groups, and where a reporter named their Mac's memory, the groups line up with the size. Divided by 1.7, each value gives the working set macOS gave the GPU on that machine.

Mac memory	max allowed, GiB	GPU working set, GiB	share of memory	reports	seen
8 GB	9.07	5.33	67 %	27	2023 – 2026
16 GB	18.13	10.67	67 %	18	2023 – 2026
24 GB	27.20	16.00	67 %	9	Jan 2025 – Jan 2026
24 GB	30.19	17.76	74 %	3	Dec 2025 – Sep 2026
32 GB	36.27	21.33	67 %	6	2024 – 2025
36 GB	45.90	27.00	75 %	3	2024 – 2026
48 GB	63.65	37.44	78 %	4, plus mine	Sep – Oct 2026
64 GB	81.60	48.00	75 %	7	Dec 2023 – Apr 2025
64 GB	88.13	51.84	81 %	6	Mar – Oct 2026
128 GB	163.20	96.00	75 %	4	2024 – 2025
128 GB	182.78	107.52	84 %	2	Dec 2025 – Jan 2026

Older PyTorch versions label these numbers "GB" and newer ones "GiB". Both are the binary unit: 1.7 × two thirds × 16 GiB is exactly 18.13.

What changed

Until late 2025 the rule looks simple. macOS gave the GPU two thirds of memory on Macs up to 32 GB and three quarters above that. Reports from late 2025 on show larger shares on the 24 GB, 64 GB and 128 GB Macs. The three 64 GB reports that name their system all say macOS 26. The 8 and 16 GB values haven't moved. My own 48 GB Mac runs macOS 26.5.2 and returns 37.44 GiB, 78 %.

Two limits on what this shows: the newer rows rest on two to six reports each, and I can't tell from them whether macOS or the chip made the difference.

What it means when you see the error

At the default ratio the limit is above physical memory on every row of the table: 1.7 × two thirds is 113 % of memory, and 1.7 × 84 % is 143 %. By the time a job reaches "max allowed", it has been swapping for a while. That matches my own measurement: on my Mac, swap began between 33.5 and 36 GB of footprint, far below the 63.65 GiB limit. The advice at the end of the error, a ratio of 0.0, removes the limit, so the job can swap further.

If you'd rather get a clean error than a swapping Mac, set the limit below your memory, for example a ratio of 1.0, which is the working set itself. Set the low ratio with it: on PyTorch 2.14, a high ratio below 1.4 set on its own fails with "invalid low watermark ratio 1.4".

PYTORCH_MPS_HIGH_WATERMARK_RATIO=1.0 PYTORCH_MPS_LOW_WATERMARK_RATIO=0.8 python your_script.py

To see your own Mac's working set:

import torch
print(torch.mps.recommended_max_memory() / 2**30, "GiB")

The numbers that don't fit

About a third of the reports show other limits, such as 1.70 GiB, 3.40 GiB, 6.77 GiB or 3.00 GiB. Those aren't the Mac's default. An app or a user set its own ratio or cap: one video tool caps MPS at 3 GiB even on a 128 GB Mac. Another 20 reports sit at 7.93, and I couldn't tie that value to one Mac size. If your number is far below the table, look in the tool's settings before you blame the Mac.

Sources

Two reports for each row. The full list of 167 is in the data file.

8 GB, 9.07: noScribe #84, pytorch #105839
16 GB, 18.13: pinokio #941, AudioLDM2 #20
24 GB, 27.20: pytorch #145374, qwen3-optimizer-study #13
24 GB, 30.19: ml-bokeh #3, ComfyUI #17264 (ratio 1.0, so 17.76)
32 GB, 36.27: ComfyUI-LivePortraitKJ #82, instructlab #2568
36 GB, 45.90: ACE-Step-1.5 #282
48 GB, 63.65: trellis2-mlx #1, ask-physics #24
64 GB, 81.60: bobo-fun #8, ComfyUI-CogVideoXWrapper #312
64 GB, 88.13: EtherReel-releases #7, ComfyUI #17309
128 GB, 163.20: ComfyUI #9308, lm-evaluation-harness #1835
128 GB, 182.78: ComfyUI #11584, ComfyUI-WanVideoWrapper #1856

MPS backend out of memory on a Mac: what the numbers mean and how to set the watermark

Rodion Kazennov — Wed, 14 Oct 2026 00:01:59 +0000

When a PyTorch job runs out of memory on a Mac, the error ends with a piece of advice:

RuntimeError: MPS backend out of memory (MPS allocated: 18.50 GiB, other allocations: 448.00 KiB, max allowed: 18.72 GiB). Tried to allocate 512.00 MiB on shared pool. Use PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.0 to disable upper limit for memory allocations (may cause system failure).

I wanted to know what following that advice does, so I filled MPS memory in 512 MiB steps on my 48 GB M5 Pro (macOS 26.5.2, PyTorch 2.14.0), once per setting, under a guard that stops the process when swap grows by 2 GB. Two things came out of it. On this Mac the default limit is higher than the RAM, so a job that outgrows memory slides into swap and never gets to this error. And lowering the limit takes two variables, not one.

Where "max allowed" comes from

max allowed is the limit: PYTORCH_MPS_HIGH_WATERMARK_RATIO times what torch.mps.recommended_max_memory() returns. On my Mac that is 37.44 GiB, and 0.5 × 37.44 = 18.72 GiB, the number in the error above. MPS allocated matched torch.mps.current_allocated_memory() in my log, the memory held by tensors. To see your own base number:

import torch
print(torch.mps.recommended_max_memory() / 2**30, "GiB")

Why a 48 GB Mac swaps first

PyTorch's documentation gives the default high ratio as 1.7. On my Mac that puts the limit at about 63.6 GiB, more memory than the machine has. This is what each setting did:

setting	what stopped the fill	tensors held	swap during the run
default (1.7)	the guard	38.5 GiB	6.1 → 12.0 GB
0.0	the guard	36.0 GiB	5.1 → 9.8 GB
1.0, low 1.0	the guard	34.5 GiB	4.6 → 8.7 GB
0.8, low 0.8	PyTorch, max allowed 29.95 GiB	29.5 GiB	no change
0.5, low 0.5	PyTorch, max allowed 18.72 GiB	18.5 GiB	no change

With the default, with 0.0 and with 1.0, swap started to grow once the process passed 33.5 to 36.2 GB, and PyTorch never raised: its limit was further away than the end of the RAM. So 0.0, the advice inside the error, changed nothing I could see here. The limit was already out of reach, and nothing in PyTorch stopped the run.

Setting it: two variables

Setting only the high ratio fails at the first MPS call:

$ PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.8 python fill.py
RuntimeError: invalid low watermark ratio 1.4

The low ratio defaults to 1.4 on Apple Silicon and may not be above the high one (unless the high one is 0.0, which turns the limit off). Set both:

PYTORCH_MPS_HIGH_WATERMARK_RATIO=0.8 PYTORCH_MPS_LOW_WATERMARK_RATIO=0.8 python run.py

From Python, set them before the first tensor goes to mps. PyTorch reads them when MPS starts, not at import torch, and ignores changes made after that:

import os
os.environ["PYTORCH_MPS_HIGH_WATERMARK_RATIO"] = "0.8"
os.environ["PYTORCH_MPS_LOW_WATERMARK_RATIO"] = "0.8"
import torch

The documentation calls the low ratio a soft limit and says that "setting 0.0 disables adaptive commit and garbage collection". I set it equal to the high one and did not measure it on its own.

Picking a value

The limit should stay below the memory your Mac really has free, with your usual apps open. On mine 1.0 (37.44 GiB) was already too much, and 0.8 (29.95 GiB) gave a clean error with no swap. After a clean error you can lower the batch size or the resolution and try again; a run sliding into swap slows down the whole Mac first.

A trap when you test this

My first run filled the tensors with torch.ones. With the default setting it reached the 46 GiB cap I had set, with no error and no swap at all: macOS compresses pages of identical values almost to nothing. Model weights don't compress like that, so a memory test on a Mac needs random data.

When the model really doesn't fit

A clean error only tells you the model doesn't fit. For a pipeline of several models, loading only the models of the current stage does more than any ratio, which is why I wrote stageload. The fill script and the traces of every run above are in its repository, in bench/results/2026-10-13-mps-watermark.

PyTorch on a Mac: why memory looks freed after .to("cpu")

Rodion Kazennov — Tue, 13 Oct 2026 08:43:56 +0000

On a Mac, a tensor moved from mps to the CPU seems to disappear from memory. The process footprint, the number Activity Monitor shows in its Memory column, drops to almost nothing, and so does the MPS driver count. The copy is still there and still takes the same memory. This is the minimal example I put together for a diffusers discussion about offloading, with a 4 GiB tensor standing in for a model's weights (torch 2.14.0, macOS 26.5.2, M5 Pro with 48 GB):

import ctypes, os, time
import torch

# rusage_info_v2 from <libproc.h>; phys_footprint is the Memory column of Activity Monitor
FIELDS = ("user_time", "system_time", "pkg_idle_wkups", "interrupt_wkups", "pageins",
          "wired_size", "resident_size", "phys_footprint")
class RUsageInfoV2(ctypes.Structure):
    _fields_ = [("uuid", ctypes.c_uint8 * 16)] + [(f, ctypes.c_uint64) for f in FIELDS] \
        + [(f"rest{i}", ctypes.c_uint64) for i in range(10)]

libproc = ctypes.CDLL("/usr/lib/libproc.dylib")

def show(step):
    torch.mps.synchronize()
    info = RUsageInfoV2()
    libproc.proc_pid_rusage(os.getpid(), 2, ctypes.byref(info))
    print(f"{step:<14} footprint {info.phys_footprint / 2**30:4.1f} GiB, "
          f"mps driver {torch.mps.driver_allocated_memory() / 2**30:4.1f} GiB")

show("start")
w = torch.randn(2**30, device="mps")      # 4 GiB of float32, standing in for a model's weights
show("on mps")
w = w.to("cpu")                           # what model CPU offload does when a model's turn ends
torch.mps.empty_cache(); time.sleep(2)
show("moved to cpu")
float(w.sum())                            # read every page of the cpu copy
show("cpu copy read")

start          footprint  0.1 GiB, mps driver  0.0 GiB
on mps         footprint  4.2 GiB, mps driver  4.0 GiB
moved to cpu   footprint  0.1 GiB, mps driver  0.0 GiB
cpu copy read  footprint  4.2 GiB, mps driver  0.0 GiB

I ran it three times and got the same output each time.

What the numbers say

Right after the move, both counters are back near zero, but w holds all 4 GiB of its values. Once the CPU reads every page of the copy, the footprint is 4.2 GiB again. So a footprint taken between .to("cpu") and the next time the CPU touches those weights does not show them.

The reason the move frees nothing in the first place is the hardware. On Apple Silicon the CPU and the GPU use one pool of physical memory. On a PC, moving weights from the GPU to the CPU frees VRAM for the next model. On a Mac, the weights "on the CPU" sit in the same RAM the GPU needs.

Why it matters for model CPU offload

diffusers' enable_model_cpu_offload() keeps each model on the CPU and moves it to the GPU only while it runs. I ran Qwen-Image-2.1 at 1024 × 1024 that way on the same Mac (trace and write-up). The process footprint never went above 18.5 GB, which would fit on a 48 GB Mac with room to spare. Swap grew by 3.5 GB during denoising and had grown by 9.6 GB by the VAE decode, and my memory guard stopped the run before it wrote an image.

A chart of the footprint alone would have called that run a fit. The example above shows one way the footprint can stay low while the weights are still in memory. I didn't measure which pages went to swap in the offload run.

How to check your own run

Look at swap, not only at the footprint:

sysctl vm.swapusage             # compare "used" before and after the run
sysctl kern.memorystatus_level  # system-wide free memory, in percent

If swap grows while the job runs, it doesn't fit, whatever the footprint says. stageload (pip install stageload), a small library I wrote for this, records both in a trace every 0.5 s with MemoryMeter, and stageload guard stops a command once swap grows past a budget:

stageload guard --wait-free 40 --swap-budget 8G -- python generate.py

What does free the memory

For a pipeline that runs its models one after another, the fix is to load a model when its stage starts and release it when the stage ends, instead of parking it on the CPU. stageload's release(module) moves every parameter and buffer to PyTorch's meta device, collects garbage and empties the MPS cache; a tensor on meta has no storage, so the memory goes back even while other code still holds a reference to the module. With the text encoder (16.3 GB) and the transformer (13.3 GB) loaded one at a time this way, Qwen-Image-2.1 peaked at 19.0 GB on the same Mac, and swap did not grow in either of two runs. The full setup is in How to run Qwen-Image-2.1 on a 48 GB Mac without swap.

What I did not measure

The free memory of the whole system during the example: other jobs on this Mac move it by several GiB between runs, so I couldn't get a clean number.
Whether del plus torch.mps.empty_cache() gives the memory back as fully as moving to meta, and how quickly.
Other macOS and torch versions, and Macs with more memory.

Godot Movie Maker and screenshots on macOS without --headless

Rodion Kazennov — Mon, 12 Oct 2026 21:22:55 +0000

I wanted Godot to write screenshots and short videos from a script on my Mac, the way it does in CI on Linux. Godot 4.7.1 on macOS 26.5.2 can't do it in --headless, but it can with the real renderer and the window off the screen. One thing I haven't solved: the app still comes to the front while it runs.

Everything below ran on a 640 × 360 test project with one script:

extends Node2D

# Saves the 30th frame to the path given after "--" and quits.
var frames := 0

func _process(_delta: float) -> void:
    $Box.position.x = 80.0 + frames * 4.0
    frames += 1
    var args := OS.get_cmdline_user_args()
    if frames == 30 and args.size() > 0:
        await RenderingServer.frame_post_draw
        get_viewport().get_texture().get_image().save_png(args[0])
        get_tree().quit()

What --headless does with a capture

Godot.app/Contents/MacOS/Godot --headless --path . -- "$PWD/out.png"

The script reached frame 30 and then waited at await RenderingServer.frame_post_draw for good: the process was still running 15 seconds later, and nothing was saved. Reading the texture without the await fails at once:

ERROR: Parameter "t" is null.
   at: texture_2d_get (./servers/rendering/dummy/storage/texture_storage.h:110)

In --headless Godot runs a dummy renderer, so the viewport has no texture to read; the path in the error is the dummy renderer's texture storage. On Linux the usual way round is a virtual X display under a real renderer. Godot's macOS build draws through the macOS window server and Metal, so that trick doesn't carry over.

Render for real, off the screen

Keep the real renderer and keep the window out of the way. Window settings take effect when the window is created, before any script runs, so they go in an override.cfg next to project.godot for the length of the run:

[display]

window/size/no_focus=true
window/size/initial_position_type=0
window/size/initial_position=Vector2i(-6000, -6000)
window/size/always_on_top=false

Then start the app through open:

open -n -W -g -j -a Godot.app --stdout run.log --stderr run.log \
  --args --path "$PWD" -- "$PWD/out.png"
rm override.cfg

-n starts a new instance even if Godot is already open, -W waits until it quits, -g keeps it in the background, -j launches it hidden, and --stdout and --stderr bring its output back to a file. Without them open drops the output, because Godot isn't a child process of your shell. The frame came back at 640 × 360 in the scene's own colours: a mean RGB of 188, 117, 82, the orange background with the blue box on it.

Delete override.cfg when the run ends. Godot reads it on every launch, so a run interrupted before the rm leaves the next normal launch with a window that never gets keyboard focus.

Movie Maker: a PNG sequence, then an MP4

Movie Maker renders every frame at a fixed rate, so the video's timing doesn't depend on how fast the machine renders:

open -n -W -g -j -a Godot.app --stdout run.log --stderr run.log \
  --args --path "$PWD" --write-movie "$PWD/movie/f.png" --fixed-fps 24 --quit-after 48

48 frames at 24 FPS (movie length: 00:00:02:00), recorded in 00:00:01 (200% of real-time speed).

It wrote f00000000.png to f00000047.png, with the audio next to them as f.wav. ffmpeg turns the frames into a video:

ffmpeg -framerate 24 -i movie/f%08d.png -c:v libx264 -pix_fmt yuv420p -crf 18 film.mp4

The result was 48 frames at 24 fps, 2.0 seconds long.

Not solved: focus

no_focus keeps the window from taking keyboard focus, but Godot still makes itself the active app when it opens its window. I polled the frontmost app during two runs. Godot was in front in 1 of 21 samples during the single-frame run and in 4 samples in a row during the Movie Maker run, which took about a second, and the app I was working in came back to the front each time Godot quit. In September a copy of the app bundle with LSUIElement set to true didn't help either. How long Godot stays in front during a longer recording, I haven't measured.

Limits

Godot 4.7.1 on macOS 26.5.2, one Mac, the Forward+ renderer. I didn't try the Compatibility renderer.
The off-screen position was tested with one display.

ulimit doesn't cap memory on macOS: stop a job before it swaps

Rodion Kazennov — Mon, 12 Oct 2026 14:31:35 +0000

On Linux a job's memory can be capped with ulimit -v, systemd-run -p MemoryMax= or a cgroup, and a job that grows too big fails on its own instead of taking the machine down. macOS has no systemd and no cgroups, and ulimit refuses. This is macOS 26.5.2:

$ /bin/bash -c 'ulimit -v 1048576'
/bin/bash: line 0: ulimit: virtual memory: cannot modify limit: Invalid argument
$ /bin/bash -c 'ulimit -m 1048576'
/bin/bash: line 0: ulimit: max memory size: cannot modify limit: Invalid argument

resource.setrlimit(resource.RLIMIT_DATA, ...) in Python raises ValueError, and in the shell where ulimit -m had failed, a script went on to allocate and touch 3 GiB. What macOS does instead is compress memory and write it to swap. A model that doesn't fit doesn't fail: it slows down, and so does everything else on the Mac.

So the questions worth asking change: is there room before a job starts, and is swap growing while it runs?

Check swap while a job runs

sysctl vm.swapusage             # compare "used" before and after a run
sysctl kern.memorystatus_level  # system-wide free memory, in percent

The process footprint, the number Activity Monitor shows, doesn't count pages that are already in swap. In one run of Qwen-Image-2.1 with diffusers' model CPU offload on my 48 GB M5 Pro, the footprint never went above 18.5 GB while swap grew by 9.6 GB. A chart of the footprint alone would have called that run a fit.

Stop a job before it swaps

stageload, a small library I wrote for loading models one stage at a time, ships a guard for this (pip install stageload):

stageload guard --wait-free 40 --swap-budget 8G -- python generate.py

It waits until kern.memorystatus_level is at least 40 %, then starts the command. If swap grows more than 8 GB over what was in use at the start, or free memory stays under 10 % for two samples, it sends SIGTERM to the command's process group and, five seconds later, SIGKILL to whatever is left. It needs no root, and the command and its process group are the only processes it ever stops. Exit code 3 means the guard stopped the command and 4 that it never found room to start it; otherwise you get the command's own exit code.

That is how the eager Qwen-Image run ended: it got through all 20 steps, the VAE decode took the footprint to 43.6 GB, swap grew by 8 GB, and the guard stopped it before the Mac stalled.

Two heavy jobs at once

A guard decides alone. Two guards that find room at the same moment both start their jobs, and each job was sized for a Mac with nothing else running. On 5 October one of my runs started in the gap between two video jobs of another script, and the next video job took swap past its budget within 20 seconds.

stageload run puts the jobs in one queue for the machine. It takes the guard's flags. Here two jobs hold 3 and 2 GiB, started from two terminals:

stageload run --who images -- python3 alloc.py 3 10    # holds 3 GiB for 10 s
stageload run --who upscale -- python3 alloc.py 2 4    # holds 2 GiB for 4 s

$ stageload queue
ram     0 running  images               pid 32488   since 2026-10-12T14:08:56+00:00  python3 alloc.py 3 10
ram     1 waiting  upscale              pid 32499   since 2026-10-12T14:08:58+00:00  python3 alloc.py 2 4

The second job starts when the first one ends, and then the guard's checks run as usual:

14:08:58Z queue: waiting in ram (1 ahead: images)
14:09:08Z queue: start in ram after 10 s, swap 6.0 GB, stop above 14.0 GB or under 10% available twice

$ stageload queue --history 2
done   ram    exit 0    images               waited 0 s, ran 10 s, peak 3.0 GB  python3 alloc.py 3 10
done   ram    exit 0    upscale              waited 10 s, ran 4 s, peak 2.0 GB  python3 alloc.py 2 4

Details that mattered on a shared Mac:

Jobs join a lane, ram by default. Lanes don't wait for each other, so a job that waits on a remote API quota can go in a lane of its own (--lane api --wait-free 0) and not hold up the ones that need memory.
Turns are fair between owners. The owner who started least recently goes next, so a script that queues twenty jobs takes turns with the others instead of holding the lane. The owner is --owner, or the part of --who before its first dash.
Each run writes a memory trace of the command and every process under it, and one line to ~/.stageload/history.jsonl with the wait, the run time, the peak footprint and swap.
Engines started outside the queue go in ~/.stageload/busy.txt, one pattern per line. Every run in the ram lane waits until none of them has been seen for 20 seconds.

Limits

The guard and the meter read macOS counters (libproc, sysctl), so they only run on a Mac.
The guard stops a job; it doesn't make the job smaller. On the model side, loading one model per stage is what took Qwen-Image-2.1 from 43.6 GB to 19.0 GB on the same Mac: How to run Qwen-Image-2.1 on a 48 GB Mac without swap.
For a safety net across the whole machine, macos-oom-guard runs as root and kills the largest process before the kernel panics. The two can run together.

How to run Qwen-Image-2.1 on a 48 GB Mac without swap

Rodion Kazennov — Sun, 11 Oct 2026 06:47:33 +0000

Qwen-Image-2.1 runs in diffusers through QwenImage21Pipeline. In bfloat16 its text encoder takes 16.3 GB, its transformer 13.3 GB and its VAE 1.3 GB, so the loaded pipeline came to 31.4 GB on a 48 GB Mac, and decoding a 1024 × 1024 image pushed it 11 GB higher. On that Mac, eager loading (the usual setup, with all three models on the GPU) and diffusers' model CPU offload both went into swap and never wrote an image. Staged loading, with one of the two large models in memory at a time, finished without swap.

The runs used an Apple M5 Pro with 48 GB, torch 2.14.0 and diffusers 0.41.0.dev0 from main. QwenImage21Pipeline also ships in the diffusers 0.41.0 release, which I did not run. Every run made one 1024 × 1024 image in 20 steps with seed 7, under a memory guard that stopped the run once swap had grown by 8 GB.

Eager loading goes into swap in the decode

The usual code loads all three models onto the GPU and keeps them there:

import torch
from diffusers import QwenImage21Pipeline

pipe = QwenImage21Pipeline.from_pretrained(
    "Qwen/Qwen-Image-2.1", torch_dtype=torch.bfloat16
).to("mps")
image = pipe(prompt=prompt, width=1024, height=1024, num_inference_steps=20).images[0]

It got through encoding and all 20 denoising steps at 31 to 33 GB. The VAE decode then took the footprint from 32.5 to 43.6 GB and swap grew by 8 GB, so the guard stopped the run before it wrote an image. PyTorch raised no out-of-memory error before that; the Mac went into swap instead.

Why model CPU offload does not help on a Mac

The answer diffusers has built in for a pipeline that does not fit is model CPU offload: each model waits on the CPU and moves to the GPU only while it runs.

pipe = QwenImage21Pipeline.from_pretrained("Qwen/Qwen-Image-2.1", torch_dtype=torch.bfloat16)
pipe.enable_model_cpu_offload(device="mps")

On a Mac the CPU and the GPU share one pool of memory, so a model that waits "on the CPU" still sits in the same RAM. In the one offload run, the process footprint never went above 18.5 GB, which looks like a fit. Swap grew anyway: by 3.5 GB during denoising and to 9.6 GB in the VAE decode, and the guard stopped the run where it had stopped eager. The footprint, the number Activity Monitor shows for a process, does not count pages that are already in swap, so it cannot show this.

Load one model per stage

The pipeline uses its models in turn: the text encoder only to encode the prompt, the transformer only in the denoising loop, and neither in the VAE decode. So the two large models never have to be in memory together. stageload keeps track of that: StagedModels loads a model the first time a stage asks for it and releases it when the pipeline enters a stage that does not list it.

from stageload import StagedModels, on_call

STAGES = {"encode": ["text_encoder"], "denoise": ["transformer"], "decode": []}
models = StagedModels({"text_encoder": text_encoder, "transformer": transformer}, stages=STAGES)

on_call(pipe, "encode_prompt", before=lambda *a, **k: models.enter("encode"))
on_call(pipe, "prepare_latents", before=lambda *a, **k: models.enter("denoise"))
on_call(pipe, "_unpack_latents", before=lambda *a, **k: models.enter("decode"))

text_encoder and transformer are functions that load each model with from_pretrained(..., subfolder=...) and move it to mps. The pipeline itself is built with text_encoder=None, transformer=None and the VAE, which stays loaded. on_call runs models.enter(stage) just before the pipeline methods where each stage begins, so the pipeline's code stays as it is. One more piece is needed: the pipeline reads the transformer's config before denoising starts, so pipe.text_encoder and pipe.transformer are stand-ins that answer .config from the checkpoint and load the model on any other use. The whole script, with the stand-ins and a memory trace, is bench/qwen_image.py, and the library installs with pip install stageload.

Both staged runs finished, in 94 and 124 s. The footprint peaked at 19.0 GB while encoding, at 16.2 and 18.6 GB in the two runs' denoising, and at 14.4 GB in the decode. Swap did not grow in either run, and free memory never fell below 51 %. Loading the two models took about 13 s per run, and releasing the transformer before the decode another 4 to 5 s. Counted from the moment the transformer was in memory to the start of the decode, the 20 steps took 70 s in one staged run, 99 s in the other and 77.5 s for eager; the traces do not show why the two staged runs differ. Both produced the same image, bit for bit.

Check a run for swap

A run fits when swap does not grow while it runs, whatever the footprint says. Two commands show it:

sysctl vm.swapusage             # compare "used" before and after the run
sysctl kern.memorystatus_level  # system-wide free memory, in percent

stageload's MemoryMeter writes the footprint, swap and free memory to a JSONL trace every 0.5 s, and stageload guard starts a command when there is room for it and stops it once swap has grown past a budget:

stageload guard --wait-free 40 --swap-budget 8G -- python generate.py

What I did not measure

VAE tiling: pipe.vae.enable_tiling() decodes the image in tiles, and the decode is where the guard stopped both eager and offload. I did not try it, so I cannot say whether it lets eager finish on this Mac.
Sequential CPU offload, quantized weights, and Macs with less or more memory than 48 GB.
Whether staged loading gives the same image as eager: eager never wrote an image on this Mac.

The measurements in more detail are in Qwen-Image-2.1 one stage at a time and Model CPU offload on a 48 GB Mac, and the traces are in the stageload repository.

Model CPU offload on a 48 GB Mac: 18.5 GB footprint and 9.6 GB of swap

Rodion Kazennov — Sun, 11 Oct 2026 05:44:25 +0000

The second stageload note ran Qwen-Image-2.1 on a 48 GB Mac two ways. The memory guard stopped eager loading in the VAE decode, and staged loading finished. diffusers has a third way built in, enable_model_cpu_offload, which keeps each model on the CPU and moves it to the GPU only while it runs. On 8 October I ran it once, with the same prompt, size, steps, seed and guard limits as the runs of 6 October.

By the process footprint, offload looked like staged: it peaked at 18.5 GB, staged at 19.0 GB. Swap tells them apart. Encoding took 8 s and added no swap. During the 87 s of denoising, swap grew by 3.5 GB and available memory fell to 27 %. The VAE decode took swap growth to 9.6 GB and available memory down to 22 %, and the guard stopped the run 105 s in, before it wrote an image. Staged added no swap in either of its two runs and finished in 94 and 124 s.

The footprint cannot show this, because it does not count pages that are already in swap. On a Mac the CPU and the GPU share one pool of memory, so a model kept "on the CPU" sits in the same RAM as the model that is running. Judged by footprint alone, offload would sit next to staged. Judged by swap, it sits next to eager, which the guard stopped at the same point after 8 GB of new swap.

What I could not show

This is one run. A second would have pushed the machine into swap again for an outcome the guard had already decided. I did not measure which pages went to swap, and I did not try offload on a Mac with more memory.

The script is bench/qwen_image_offload.py, and the trace is in the repository. stageload installs with pip install stageload.

Loading a PyTorch pipeline one stage at a time: Pixal3D on a 48 GB Mac

Rodion Kazennov — Mon, 05 Oct 2026 13:00:36 +0000

On 4 October a Pixal3D run on my Mac went into its texture stage, and within ten seconds the process grew from 27 to 44 GB. Available memory fell to 6 % and swap grew by 12 GB, so the guard I run heavy jobs under stopped it. The Mac has 48 GB. Before I had that guard, two Pixal3D runs, one of them next to other heavy work, ended with the Mac rebooting.

Pixal3D turns one image into a textured 3D mesh, and Pixal3D-mac is its port to Apple Silicon. The 1024_cascade pipeline runs seven models in turn: a flow model and a decoder for the coarse structure, two flow models for the shape at 512 and 1024, a shape decoder, and a flow model and a decoder for the texture. Around them work four image feature extractors, a background remover and a camera estimator. Each stage needs one or two of the seven models, and the port keeps all of them in memory from the first second to the last.

Why the memory does not come back

On Apple Silicon the CPU and the GPU share one pool of memory. Pixal3D's low-VRAM mode, which is on by default, keeps idle models on the CPU and copies the active one to the GPU. On a PC with a separate graphics card, that saves video memory. On a Mac the CPU copy and the GPU copy sit in the same RAM, so the mode keeps every model resident and adds a second copy of the active one. The four feature extractors also load the same DINOv3 backbone, four times.

Loading one stage at a time

stageload is a small library I wrote for this. It swaps the pipeline's dictionary of models for one that loads a model the first time a stage asks for it, and that releases every model the next stage does not list. Releasing moves each tensor of the module to PyTorch's meta device. That frees the storage even while other code still holds a reference to the module, and calling the module afterwards raises an error that names it and the stage that released it, instead of failing somewhere inside PyTorch.

The port's own run() executes unchanged. stageload wraps four of the pipeline's methods to learn where each stage begins: background removal, the first image conditioning, the conditioning of each shape and texture pass, and the final decoding. The four feature extractors are built so that they share one backbone.

One part of this raises no error when it goes wrong. Pixal3D seeds once at the start of a run and then draws the noise of every stage from the CPU random generator. Building a model runs its random initialisation, which draws from that same generator. A model built lazily in the middle of the run would therefore change the noise of every stage after it, and with it the mesh. stageload saves the generators' state before each load and restores it afterwards: torch's CPU, MPS and CUDA generators, Python's random and NumPy's global one. On a stand-in pipeline that seeds and draws noise the way the port does, a test checks that staged and eager runs produce the same latents bit for bit, and a control that turns the restore off sees them drift apart.

Not only Pixal3D

Nothing in the core of stageload knows about Pixal3D. A pipeline needs three things from it: a function that builds each model on its own, a list of the models each stage uses, and a call where each stage begins. In code you own, that call is one line, models.enter("decode"). In someone else's code, like this port, on_call attaches it to a method that already runs at that point, so the pipeline itself stays as it is. A text-to-image pipeline has the same shape as Pixal3D: a text encoder, a denoiser and an image decoder run one after another. The memory meter and the guard work for any program on a Mac. Pixal3D is the only pipeline I have measured so far; the README shows the core on a small two-model pipeline, and that example runs as a test.

What it changed

On this M5 Pro with 48 GB, I ran the port's example image through 1024_cascade with seed 7 and 2048-pixel textures, two runs per mode, each in its own process under the guard. "Eager" is the port's own loading and "staged" is stageload. Eager runs do not get through the texture stage on this machine within the guard's limits, so the two eager runs stop where it begins. The texture number for eager comes from the run on 4 October that went into it.

stage	eager, peak footprint	staged, peak footprint
setup	20.4 GB	2.9 GB
camera	23.2 GB	6.7 GB
structure	22.2 GB	10.9 GB
shape_512	26.6 GB	11.4 to 11.5 GB
shape_1024	30.5 GB	13.1 GB
texture	stopped by the guard at 44.2 GB	30.1 GB
decode	not reached	17.9 to 18.4 GB
export	not reached	69.6 to 70.2 GB

In every stage both modes ran, staged held 11.3 to 17.5 GB less. The eight loads, the seven models plus the shape decoder a second time for decoding, read 13.2 GB in 24 s out of about ten minutes per run.

Most of the texture stage's 30 GB is working memory: the texture model itself is 2.6 GB. When decoding began, stageload released it together with the feature extractors and emptied the MPS allocator's cache, and within two seconds the footprint was down to 4.5 GB in one run and 8.0 GB in the other.

The highest staged number, about 70 GB, comes in the export, after every model weight has been released. It is the port's mesh processing (remeshing, UV unwrapping, baking), which stageload does not touch. The footprint is the number Activity Monitor shows, and it counts memory macOS has compressed, so it can be larger than the 48 GB of RAM.

What I could not show

The first is whether staged loading changes the result. Every run saved a hash and a copy of each sampler's output. The first latent, the coarse structure, is the same bit for bit in all four runs. From the 512 shape stage on, the port does not repeat itself on MPS even with the same seed: the two eager runs differ by up to 1.77 in the shape latent, and a staged run differs from an eager one by 1.24 to 1.86. So the comparison says any change from staged loading is no larger than the port's own variation, measured on that single pair of eager runs. The texture latent and the final mesh were not compared at all, because eager runs never reach them here.

Building on the CPU did not help. stageload builds each model directly on the GPU, and that changes one tensor the checkpoint does not cover: the rotary frequencies of the sparse attention, computed when a model is built, come out up to 6e-8 apart. To see whether that explained the differences, I ran a staged pass that built every model on the CPU and moved it to the GPU, the way the port does. Its latents differed from the eager runs by 1.84 and 1.12, the same order as every other pair. Loading took 82 s instead of 24 s, and three stages peaked 2.6 to 3.8 GB higher while two came out lower. I went back to building on the GPU.

My own summary had a bug that inflated one number. It took each stage's peak from the moment the stage was recorded as started, but releasing the previous stage's models takes up to 1.7 s. One memory sample in that gap put the decode peak of the CPU-built run at 29.5 GB; counted from the end of the releases, it is 16.7. A code review caught it. A stage's window now begins when the releases its start set off have finished.

The guard

The runs went through a second part of stageload, stageload guard, because other heavy jobs run on this Mac too. It starts one command only when enough memory is available and no process matching a list of heavy jobs has been seen for a while. While the command runs, it stops the command's whole process group if swap grows past a budget or available memory stays under 10 %. It needs no root, and the only processes it ever stops are the ones it started.

The wait for quiet came from a failure. A chain of video jobs leaves short gaps between them, a run started in one of those gaps, and the next video job took swap past the budget within 20 s. In the bench every run started only after three minutes with no heavy job in sight.

On another image

The same staged run on a character from a game I am making took 416 s and loaded the same 13.2 GB in 37 s. Its texture stage peaked at 30.1 GB, as on the example image. Here is the input and the mesh it produced, rendered in Blender:

The code, the traces of every run and the scripts that drew these charts are in the repository. The Pixal3D adapter is tested against one commit of Pixal3D-mac.

What 30 open-source projects ask of AI-assisted contributions

Rodion Kazennov — Sat, 03 Oct 2026 13:40:04 +0000

Between 27 September and 2 October I sent fixes, bug reports and comments to twelve open-source projects. A coding agent did much of the work: Claude Code reproduced the bugs, wrote the patches and tests, and drafted most of the texts. I chose each issue and read every text, and nothing went out from my account until I had approved it.

Along the way the projects kept telling me how they want that kind of work done. spec-kit wanted the agent, the model, its settings and the extent of its help named in every AI-generated comment. MLX's pull request template opens with a ticked line: "I understand it is strictly prohibited to use AI to write PR description". So on 2 October I read the contribution rules of 30 repositories: the ones I had sent work to, and 21 more that I had not.

The short version: 19 of the 30 have a rule about AI, and 14 of those 19 rules appeared in 2026. Most make the person who submits responsible for the change. Fifteen ask you to say that you used AI, and ten want a person, not a model, to write the description, the comments or the commit message. The commit trailer that coding agents add by default is required by some of these projects and banned by others.

What I read

The sample is not random. Nine of the 30 are projects I sent work to that week: MLX, spec-kit, huggingface_hub, codebase-memory-mcp, Deskflow, agent-framework, awslabs/mcp, kaggle-cli and avoid-ai-writing. The other 21 are projects in AI tooling, developer tools and infrastructure, among them Docling, garak, TypeScript, Rust, Node.js and Kubernetes. The three remaining projects I sent work to, copilot-cli, PartCrafter and ltx-2-mlx, are not in the 30, and I found no AI rule in any of them.

In each repository I read CONTRIBUTING, the pull request and issue templates, AGENTS.md and CLAUDE.md, the code of conduct, and the guides and wiki pages these files link to, at the default branch on 2 October 2026. Every quote below links to its line at the commit I read, so the link shows what the file said that day even after it changes. To date a rule, I searched the history of its file for the first commit that contains it.

Who has a rule

19 of the 30 have a rule about AI in contributions: MLX, spec-kit, TypeScript, huggingface_hub, transformers, trl, peft, LangChain, Strands Agents, MLflow, garak, codebase-memory-mcp, Deskflow, workers-sdk, pydantic-ai, Rust, CPython, Node.js and Kubernetes.

I found none in nine: accelerate, awslabs/mcp, kaggle-cli, Docling, BeeAI, ADK for Python, NeMo Agent Toolkit, VS Code and React. Two more I did not count. agent-framework only warns that AI has raised the number of contributions, so reviews take longer, and avoid-ai-writing checks the style of prose rather than how it was produced.

A rule usually asks for several things at once:

The second bar is my reading: 12 of the 19 say in some form that the person who submits is responsible for the change and must understand it. huggingface_hub does it in two sentences: "Using AI to help write code is fine. Submitting AI-generated slop you cannot explain is not." CPython expects authors "to be able to explain their proposed changes in their own words", and Strands Agents tells contributors "you are the author of your pull request, not your agent."

When they appeared

CPython was first, with a short page in its developer guide in October 2024. Four followed in 2025: spec-kit, LangChain, Kubernetes and MLflow. The other 14 appeared in 2026, seven of them since June. codebase-memory-mcp added its rule eleven days before I read it.

The files are still changing. In 16 of the 19, a file that holds the rule was edited in September or on the first two days of October, though not every one of those edits touched the AI text.

Say so

Disclosure is the most common rule, and the projects differ on how much of it they want. For Kubernetes one sentence is enough: its guide says that including "This PR was written in part with the assistance of generative AI" in the description "is sufficient." TypeScript closes the PR without it: "If your PR appears AI-authored and you do not include this disclosure, your PR will be closed without review." spec-kit wants the agent, the model, the settings and the extent named in the pull request, again in each AI-generated comment, and as an Assisted-by: trailer on each commit an agent wrote.

Two projects put the stakes in one line. codebase-memory-mcp: "Disclosure is never held against a contribution. Finding out later is." Deskflow: "Being dishonest about AI use in contributions will result in a ban from the project."

CPython asks for less than the rest: "Disclosure of the use of AI tools in the PR description is appreciated, while not required."

A person writes the words

Ten projects let a model help with the code but want a person to write the text. Rust is the strictest: "LLM-created PR descriptions are banned. LLM-created GitHub comments are banned." The same goes for commits: "Commit messages must be authored by you, not your LLM."

Kubernetes and Node.js draw the line at review. Kubernetes: "When responding to review comments, you must do so without relying on AI tools." Node.js: responses to feedback "must not be automated by AI tools."

Others build it into their templates. MLX has the line quoted above, and a matching one for issues. Strands Agents gives its pull request template a "Human Overview" section that "An AI agent MUST NOT fill out". LangChain's template warns: "If you paste a large clearly AI generated description here your PR may be IGNORED or CLOSED!"

No bulk, and ask first

Seven projects ban bulk or automated submissions. TypeScript describes the workflow it refuses: "workflows in which an operator points an autonomous agent at GitHub, has it generate patches across many unrelated issues, and forwards the output to us as pull requests." LangChain's guide gives a test that fits any contribution: "If the effort required to create a pull request is less than the effort required for maintainers to review it, that contribution should not be submitted."

Six want an approval before the pull request. In peft it is a maintainer's comment containing @peft-triage approved. In Rust a change created by an LLM must be pre-arranged, which means that "a reviewer has communicated ahead of time that they are willing to review an LLM-created PR."

Three projects turn away newcomers who use agents. transformers asks "that first-time contributors do not use code agents to create issues or PRs", and trl "will not review fully AI-generated PRs from first-time contributors." Node.js asks new contributors to "avoid using AI agents to interact with the project", and it bans AI fixes for issues labelled "good first issue", which "are meant to help new human contributors, not an AI, learn about the code base".

Rust also caps the share of this work: "If more than half of PRs merged in a 6-week window are LLM-created, we disallow merging new LLM-created PRs until we go back below 50%, with a minimum cooldown of 10 days."

The trailer they disagree on

Coding agents often sign their work. Claude Code, for one, adds a Co-Authored-By: Claude … trailer to each commit and a "Generated with Claude Code" line to pull requests unless told not to. Nine projects have a rule about such trailers, and the rules point in opposite directions:

The sources: MLflow, garak, spec-kit, Node.js, Kubernetes, Rust, pydantic-ai, Deskflow and codebase-memory-mcp.

Kubernetes: "Listing AI tooling as a co-author, co-signing commits using an AI tool, or using the assisted-by, co-developed or similar commit trailer is not allowed." pydantic-ai says it in the file Claude Code loads when a session starts: "Never add yourself (Claude) as a co-author on commits." Rust's guide lists both default lines among its bad examples of disclosure: 🤖 Generated with Claude Code and Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>.

So the default trailer is what MLflow asks for and a rule break in Kubernetes, Rust and pydantic-ai. No setting is right everywhere. An agent has to read a repository's rules before its first commit there, and so does the person who runs it.

Rules written for the agent

Some of these rules address the agent directly, in AGENTS.md or CLAUDE.md, the files coding agents read when they start work in a repository. What they tell it:

pydantic-ai: "you are the first line of defense against low-quality contributions and maintainer headaches".
MLX: do not "write PR descriptions and commit messages for the user", answer comments on the user's behalf, push or open a pull request.
Rust: stop, "name the prohibited category, and tell the user to author it."
transformers: warn people who are not yet contributors, "including the risk of being blocked."
spec-kit: ask the operator before a fourth open pull request in the repository, "including during autonomous operation".
Strands Agents, to agents that run on a schedule: "work at a pace humans can follow and respond to."

These rules work only if the agent reads the file and follows it.

What happened to mine

Kaggle/kaggle-cli: PR #1206, streaming kernels output files through the shared downloader. Merged the same day.
conorbronsdon/avoid-ai-writing: PRs #352, #361 and #362, two detector fixes and a test. All three merged, each within a day.
huggingface/huggingface_hub: issue #5065, --env-file lost its first variable when the file started with a UTF-8 BOM. A maintainer opened the fix, #5066, 52 minutes later, and it was merged within two hours of the report.
microsoft/agent-framework: PR #8963, data URIs with parameters. Closed after three hours as a duplicate: an older open PR, #8918, had the same fix.
ml-explore/mlx: PR #4610, Metal RMSNorm and LayerNorm with negative-stride weights. Closed after two and a half hours: "Thanks for the PR but this would not be the ideal fix."
DeusData/codebase-memory-mcp: issue #2454 and PR #2456, a misleading hint on empty search results. Labelled a high-priority bug, waiting for review.
dgrauet/ltx-2-mlx: PR #167, last and negative frame indices for image anchors. The maintainer asked for one fix before merging, and I sent it on 3 October.
github/spec-kit, microsoft/agent-framework and awslabs/mcp: a proposed scope on #4213 and plans for a fix on #8909 and #4705. Waiting for maintainers.
deskflow/deskflow: the root cause of #10068, a crash on macOS. Labelled and assigned, no reply yet.
github/copilot-cli: issue #5038, the grep tool ignores n without the dash. Labelled, no reply yet.
wgsxm/PartCrafter: PR #46, running on Apple Silicon. No reply yet.

Five of the twelve have an AI rule: MLX, spec-kit, huggingface_hub, codebase-memory-mcp and Deskflow. In huggingface_hub I only opened an issue, and its rule is about pull requests. In MLX I wrote the pull request description and the commit message myself, as its rules require, and the description says what the agent did. My spec-kit comment carries the full disclosure that spec-kit asks for, and in codebase-memory-mcp the issue, the pull request and each comment carry its one line. Two of my codebase-memory-mcp replies went out on 28 September without that line, a week after the project added the rule; I added it on 1 October. Deskflow asks for a disclosure in pull requests. My comment there, which the agent drafted, went out without one; I added the line on 3 October.

Neither closing comment mentions AI. agent-framework closed my PR because an older open one had the same fix, which I would have found if I had searched before writing mine. The MLX maintainer judged the approach.

What I changed

Before writing a fix, I search the open pull requests and the issue's timeline for the issue number. The duplicate came from skipping that.
In large projects I post a plan as a comment and open no pull request until a maintainer answers. agent-framework, awslabs/mcp and spec-kit are at that stage now.
One open pull request per project at a time.
The text follows each project's rule. If a project bans AI-written descriptions, as MLX does, I write them myself. spec-kit and codebase-memory-mcp get their disclosure in the form they ask for, and a project with no rule gets no disclosure line.
No trailers unless a project asks for one. My commits carry my name only.
I do not send this kind of work to projects whose rules it would not meet. Rust, Kubernetes and Node.js ban AI-written comments or replies to review, transformers, trl and Node.js ask newcomers not to use agents, and TypeScript refuses queue-driven work.

Limits

This is one account over six days. The 30 repositories are my choice and lean towards AI tooling, where rules are more likely. The kinds are my labels, and one rule often fits several. Everything was read on 2 October 2026, and in 16 of the 19 the rule files changed in the month before, so parts of this will be out of date soon. The pinned links show what each file said that day.

All 106 quotes, the counts and a script that checks every quote against its file are in nefayran/oss-ai-rules.

This note was drafted with Claude Code (Claude Opus 5.5), which also collected the rule files and checked every quote against them.