TL;DR: os error 1455 is Windows refusing to promise memory, not running out of it. Your commit limit is RAM + pagefile, and loading a 20GB+ checkpoint on a 16GB machine blows past it — even while Task Manager shows free RAM. Set a custom pagefile (start at 32GB max on a 16GB box) and the error disappears.

What you’ll be able to do after this guide:

• Read the two shapes of error 1455 — ComfyUI’s runtime (os error 1455) and PyTorch’s import-time [WinError 1455] — and know which fix each one needs.
• Watch your commit charge hit the commit limit in real time, so you size the pagefile from measurement instead of forum folklore.
• Shrink the model-load spike itself with fp8 and GGUF variants, so a 16GB laptop stops needing a 64GB pagefile in the first place.

Honest take: this is the rare “just change one Windows setting” fix that genuinely works — but if you’re feeding 23.8GB FLUX checkpoints to a 16GB laptop, the pagefile is a tourniquet. The real fix is fp8/GGUF model variants or more RAM.

ComfyUI dies mid-workflow with this, usually right at the model-loading node:

The paging file is too small for this operation to complete. (os error 1455)

It’s one of the most reported Windows errors in local image generation, and the standard advice around it is half-wrong: this is not a VRAM problem, it’s not (exactly) a RAM problem, and adding --lowvram won’t fix it. It’s a Windows virtual memory accounting problem, and once you understand the one rule behind it — the commit limit — the fix takes five minutes.

Tested against ComfyUI v0.28.0 (July 2026); the mechanics are identical back to every 0.3.x build and apply equally to Stable Diffusion WebUI, Ollama’s Python tooling, and any PyTorch script on Windows.

The two shapes of error 1455

Shape 1 — runtime, while loading a model. This is the ComfyUI version. Real reports from the ComfyUI tracker: a 16GB-RAM laptop with an RTX 3050 (4GB) hits it loading flux1-schnell-fp8.safetensors in a UNETLoader node (issue #7550), and a 16GB-RAM machine with an RTX 4060 Laptop (8GB), Python 3.12.10 and PyTorch 2.7.0+cu128 hits it loading an SDXL checkpoint (issue #8065). Note the pattern: 16GB system RAM, big checkpoint, error at load time.

Shape 2 — import-time, before anything loads. The PyTorch version, thrown the moment Python imports torch:

OSError: [WinError 1455] The paging file is too small for this operation
to complete. Error loading "C:\...\site-packages\torch\lib\<some>.dll"
or one of its dependencies.

This one plagued trainers for years (the canonical thread is ultralytics/yolov3 #1643) because every worker process that imports torch maps the CUDA DLLs again, committing gigabytes per process before a single tensor exists. Same Windows rule, different trigger.

30-second diagnosis

What you see	When it fires	Real cause	Fix
(os error 1455) in a ComfyUI node	Loading a checkpoint/UNET	Commit limit too low for the load spike	Bigger pagefile (Fix 1), smaller model format (Fix 3)
[WinError 1455] ... Error loading ...torch\lib\*.dll	import torch, or when DataLoader workers spawn	Each Python process commits GBs of CUDA DLL space	Fewer worker processes (Fix 4) + bigger pagefile
Pagefile already “system managed” but error persists	Any of the above	Auto-growth is capped by free disk (1/8 of volume size)	Free disk space or move the pagefile (Fix 2)
Error appears only when running two AI apps at once	Second app starts	Combined commit of both apps exceeds the limit	Close one, or raise the pagefile ceiling

Why Windows refuses while Task Manager shows free RAM

Windows makes a hard promise for every private memory allocation: it guarantees there is somewhere to put the data — physical RAM or pagefile — before the allocation succeeds. The total of those promises is the commit charge, and the ceiling is the commit limit: physical RAM + all pagefiles combined (Microsoft’s page file documentation).

When a new allocation would push the commit charge past the commit limit, Windows denies it. Error 1455 is that denial. Crucially, Microsoft’s own troubleshooting guide notes the system can hit the commit limit while plenty of physical memory is still free (out-of-committed-memory guide) — commit is a promise ledger, not a measure of what’s in use. That’s why “but I have 6GB of free RAM!” doesn’t save you.

The math on a typical 16GB machine: Windows’ system-managed pagefile grows to three times RAM or 4GB, whichever is larger — but never more than one-eighth of the volume’s size, and it only expands when the commit charge reaches 90% of the current limit (Microsoft page file sizing rules). On a nearly full 256GB C: drive, that 1/8 cap can pin your pagefile far below what a 23.8GB flux1-dev.safetensors load spike needs on top of Windows itself, your browser, and ComfyUI’s Python process. A fast spike can also outrun the auto-grow logic — the allocation fails before the pagefile finishes expanding.

Watch it happen before you fix it

Open Task Manager → Performance → Memory and find the Committed pair (e.g. 14.9/18.3 GB). Queue your failing workflow and watch the left number race toward the right one. If the error fires as they meet, you’ve confirmed the diagnosis in one run — no guessing.

For the numbers in a terminal, PowerShell:

Get-CimInstance Win32_PageFileUsage | Format-List Name,AllocatedBaseSize,CurrentUsage,PeakUsage

Typical output on a box that’s been hitting 1455:

Name              : C:\pagefile.sys
AllocatedBaseSize : 4864
CurrentUsage      : 3210
PeakUsage         : 4791

All values are MB. PeakUsage bumping against AllocatedBaseSize while your total commit sits near the limit is the smoking gun: the pagefile ceiling — not your RAM stick — is what’s failing your workflow.

Fix 1: set the pagefile yourself

The five-minute fix. You’re raising the commit limit so the load spike fits.

1. Press Win+R, run sysdm.cpl.
2. Advanced tab → Performance Settings… → Advanced tab → Virtual memory Change…
3. Uncheck “Automatically manage paging file size for all drives.”
4. Select the drive that has free space (C: by default), choose Custom size.
5. Set Initial size and Maximum size, click Set, then OK, then reboot.

Sizing: there is no magic universal number — the right ceiling is “peak commit charge during your heaviest load, plus headroom.” As working rules of thumb (our guidance, not a Microsoft spec):

System RAM	Initial size	Maximum size	Handles
16GB	16384 MB	32768 MB	SDXL, FLUX fp8, most LoRA work
16GB (FLUX fp16 / video models)	32768 MB	65536 MB	20GB+ checkpoints, Wan-class video
32GB	8192 MB	32768 MB	Nearly everything; spikes only
64GB+	4096 MB	16384 MB	Safety net; you’ll rarely page

Set the initial size high rather than relying on growth — expansion during a fast model load is exactly the race that loses. After rebooting, re-run the failing workflow and watch Committed again: if peak commit lands comfortably under the new limit, you’re done. And never select “No paging file” to “save SSD wear” — that sets your commit limit to bare RAM and makes 1455 (and outright crashes) more likely, per Microsoft’s own guidance.

Fix 2: the disk-space trap

Two ways disk space silently re-breaks Fix 1:

• The 1/8 rule. A system-managed pagefile won’t grow beyond one-eighth of the volume size. A cluttered 256GB C: drive with 20GB free can’t host the pagefile a FLUX workflow needs, no matter what the dialog says.
• Custom sizes need real free space. Setting a 64GB maximum on a drive with 30GB free fails at expansion time — and you’re back to 1455 mid-load.

If C: is tight, put the pagefile on a second SSD: in the same Virtual Memory dialog, select the other drive, give it the custom size, and set C: to a small 1024–4096 MB file (Windows likes having one on the boot volume for crash dumps). Keep the pagefile on an NVMe drive, not a hard disk — when Windows does page, the difference is felt in seconds versus minutes. Our NVMe guide for local AI covers drive choice, and if it’s Ollama models eating your C: drive, move them with OLLAMA_MODELS instead of shrinking the pagefile.

Fix 3: shrink the spike instead of raising the ceiling

A pagefile makes the promise ledger balance; it doesn’t make paging fast. If your workflow only survives on a 64GB pagefile, generation will crawl every time Windows actually swaps. Better: commit less.

• Run fp8, not fp16. flux1-dev.safetensors in fp16 is a 23.8GB file (Comfy-Org distribution); the fp8 checkpoint is roughly half that, and the load spike shrinks with it. On 4–8GB laptop GPUs you were never getting fp16’s benefit anyway.
• Use the fp8 text encoder on 16GB machines. ComfyUI’s own FLUX guidance is to use the fp16 t5xxl encoder only if you have more than 32GB of system RAM, and t5xxl_fp8_e4m3fn otherwise (ComfyUI FLUX examples).
• GGUF quants for the tightest boxes. Q4-class GGUF UNETs cut both the file and the commit spike to a quarter of fp16.
• One AI app at a time. ComfyUI + an LLM server + a browser full of tabs all count against the same commit limit. Close what isn’t generating.

If a workflow fundamentally exceeds your machine — 16GB RAM and a 4GB laptop GPU asked to run fp16 FLUX or a video model — rent the one-off instead: a RunPod GPU instance for an afternoon costs less than the hours you’ll spend swapping.

Fix 4: the import-time variant (trainers and scripters)

If you get [WinError 1455] at import torch or when a training run spawns DataLoader workers, the multiplier is process count: every worker re-imports torch and re-commits the CUDA DLL space. Set num_workers=0 (or 1–2, testing upward) in your DataLoader and the total commit drops by gigabytes (ultralytics/yolov3 #1643).

You’ll also find fixNvPe.py recommended in older threads — a script that rewrites the NVIDIA DLL headers so they stop demanding pagefile-backed commit up front (cobryan05’s gist, referenced in the MMDeploy FAQ). Treat it as history: NVIDIA addressed the DLL flagging in the CUDA 11.7 era, and on a 2026 stack (PyTorch 2.7+cu128) you should fix the pagefile and process count, not patch DLLs.

When the answer is hardware

The honest ladder, cheapest first: pagefile (free, five minutes) → fp8/GGUF model variants (free, better quality-per-GB than swapping) → RAM. If you’re on 16GB and generating regularly, a Corsair Vengeance 64GB DDR5 kit removes the whole class of problem, and our system RAM guide walks through how much you actually need. If your pagefile has to live somewhere fast, a Samsung 990 Pro 2TB also solves the model-storage crunch that caused the disk-space trap above.

Related ComfyUI failures with their own guides: CUDA out of memory (that one is VRAM), “Torch not compiled with CUDA enabled”, black image output, and stuck on “Reconnecting” — which is what error 1455 often looks like from the browser, since the Python backend dies and the frontend just loses its WebSocket. If you’re setting up fresh, start from the ComfyUI Windows setup guide.

FAQ

Is error 1455 a VRAM problem? No. It fires on the CPU/system-memory side, usually before weights ever reach the GPU. --lowvram and friends don’t touch it. If your error says CUDA out of memory, that’s the other guide.

Why did this start after I downloaded one new model? Because that model’s load spike was the first to cross your commit limit. A 6.9GB SDXL checkpoint fits under a 16GB machine’s default limit; a 23.8GB FLUX fp16 file doesn’t.

Does a big pagefile wear out my SSD? Committed-but-unused pages are a bookkeeping entry, not writes. You pay real writes only when Windows actually pages — which Fix 3 minimizes. A modern NVMe drive’s endurance rating dwarfs pagefile traffic from a hobby rig.

Can I just disable the pagefile since I have 32GB of RAM? Don’t. Commit limit becomes RAM alone, so every allocation promise must fit in 32GB even if most of it is never touched — model loads that would have sailed through now fail. Keep at least a small pagefile.

Task Manager says only 60% memory used and it still crashes. How? “Memory in use” is physical occupancy; 1455 is about the Committed ledger. Check the Committed pair in Task Manager’s Memory panel — that’s the number that hit its ceiling.

Recommended Gear

Products linked in this guide:

• Corsair Vengeance 64GB DDR5 — the permanent fix for 16GB machines that generate daily
• Samsung 990 Pro 2TB — fast NVMe home for models and, if needed, the pagefile

Sources

• Introduction to the page file — Microsoft Learn
• How to determine the appropriate page file size for 64-bit versions of Windows — Microsoft Learn
• PerfGuide: Out of system committed memory — Microsoft Learn (TechNet archive)
• (os error 1455) — ComfyUI issue #7550
• Error 1455 — ComfyUI issue #8065
• WinError 1455 loading torch DLLs — ultralytics/yolov3 issue #1643
• FLUX Examples (text encoder RAM guidance) — ComfyUI_examples
• Comfy-Org flux1-dev distribution (23.8GB fp16 checkpoint) — Hugging Face
• MMDeploy FAQ (fixNvPe.py / CUDA 11.7 note) — open-mmlab

Last updated July 21, 2026. Windows behavior described applies to Windows 10 and 11; verify pagefile settings after major Windows updates.