Category: Local AI Operations

You load a quantized model, fire up llama-server or llama-cli, and the first few turns feel snappy. Then something strange happens: by the time the conversation reaches a few thousand tokens, generation crawls to a fraction of its original speed, memory usage climbs, and every prompt takes a painfully long “prefill” burst before the first token appears.

This is not a broken model, and it is not your GPU degrading. In the overwhelming majority of cases it is the KV cache—the growing attention state that stores every token already generated—combined with how you have (or have not) told llama.cpp to offload it and accelerate its computation. This article walks through the symptoms, the diagnosis, the exact flags to change, and how to verify the fix without guessing.

The Symptom: Fast Start, Then a Slow Crawl

The classic signature is easy to recognize once you know what to look for:

• Short prompts are fast. A single-turn query returns quickly because the KV cache is small and cheap to process.
• Long chats degrade. As the history grows, prompt processing (“prefill”) takes longer before the first generated token, and per-token generation drops.
• RAM usage grows. The KV cache scales linearly with context length, and if it has spilled off the GPU it is being read from system RAM on every decode step.
• The model eventually “forgets” or truncates. When the cache reaches the configured context size, llama.cpp triggers context shift: it drops the oldest tokens and reprocesses the remainder.

Any one of those is a signal, but the combination of growing memory plus longer prefill plus slower decode points squarely at KV cache management rather than at the model weights themselves.

Diagnosis: Separate Model VRAM from KV Cache

Before changing any flag, confirm where your memory is actually going. Run your server with the default settings and watch both GPU and system memory during a long session. On Linux use nvidia-smi for VRAM and free -h for RAM; if you are running the server under a manager such as Ollama, it exposes similar numbers in its own logs.

Two distinct regions matter here, because llama.cpp treats them differently:

• Model weights. The quantized tensors that get partially or fully offloaded to the GPU via --n-gpu-layers (short form -ngl). These are mostly static during inference.
• KV cache. The key and value tensors that grow with every token in the active context. Their size depends on context size, model dimension, and the KV data type you allow.

The single most common misconfiguration is loading the weights onto the GPU but leaving the KV cache — by default — unquantized and potentially split awkwardly across devices. By default the KV cache is stored at f16, which for a large context can consume more memory than the model weights themselves. Understanding this split is what turns the fix from trial-and-error into a deliberate configuration.

The Fix: Tune Offload, Flash Attention, and Context Shift

Here are the levers that matter, in order of impact.

1. Put the KV cache in the right device

-ngl / --n-gpu-layers controls how many of the model’s layers are offloaded to the GPU. The KV cache placement is tied to where the relevant layers live. A common “slow long-context” failure is loading only some layers to the GPU so that the KV cache ends up straddling GPU and CPU, forcing data movement on every decode step. If you want the KV cache to stay on the GPU, offload all layers (-ngl 99 or higher) so the K/V tensors are not split.

The inverse is also useful on memory-constrained cards: -ot / --no-offload-kqv keeps the K, Q, and V tensors on the CPU while the rest of the model runs on the GPU. This trades speed for lower VRAM and is a legitimate choice when you are trying to fit a large model into a small card with a long context.

2. Quantize the KV cache to shrink it

The single highest-leverage change for long-context degradation is quantizing the KV cache itself. llama.cpp exposes --cache-type-k and --cache-type-v (in some releases combined into a single --cache-type). Allowed values include f16, q8_0, and q4_0. Moving from f16 to q8_0 roughly halves the KV cache memory for a modest quality cost; q4_0 reduces it further with a larger quality trade-off.

This matters precisely because the KV cache, not the weights, is what balloons during a long chat. Quantizing it lets you hold a bigger context in the same VRAM, which postpones the moment context shift kicks in.

3. Enable Flash Attention for the attention math

-fa / --flash-attn switches attention to a fused Flash Attention kernel. On supported hardware this speeds up both prefill and decode and, importantly, lowers the memory footprint of the attention computation. If your GPU supports it, this is almost always a strict win for the long-context scenario that is causing the slowdown. If the build was not compiled with it, the flag will report as unavailable rather than silently failing.

4. Control context length and mmap behavior

• -c / --ctx-size sets the maximum tokens of history the KV cache can hold. Setting it too high wastes VRAM reserved up front; setting it too low causes premature truncation. Match it to your actual use (for example 4096 or 8192 for RAG, larger only if you genuinely need it).
• --no-mmap disables memory-mapping of the model file and instead loads it fully into RAM. This can improve stability on some systems at the cost of higher startup RAM and longer load time, but it does not affect the KV cache directly—apply it only if you observe page-cache thrashing or load-time issues.
• Context shift / --no-context-shift controls what happens when the cache fills. By default llama.cpp shifts the context (drops the oldest tokens and re-processes). This re-processing is one of the visible “stalls” users describe. Disabling context shift forces a full recompute of the entire history, which is almost always worse; instead, reduce the likelihood of hitting the limit by quantizing the cache and sizing the context correctly.

Common Pitfalls That Look Like This Bug but Are Not

Before you conclude it is the KV cache, rule out a few lookalikes:

• Thermal throttling. A card that boosts for the first minute and then throttles under sustained load produces the same “fast then slow” curve. Check nvidia-smi clocks and temperature before blaming the cache.
• Model weights partly on CPU. If you set -ngl too low, every layer left on the CPU serializes the pipeline. This is a weights-offload problem, not a KV cache problem, though the two are often confused because both are fixed by raising -ngl.
• Context size grossly oversized. Reserving a 32K context on an 8GB card leaves little room for anything else and can cause the GPU to spill or the OS to swap, both of which look like slow degradation.
• Concurrent workloads. If another process—say a ComfyUI image pipeline—is competing for the same 16 GB card, both will degrade. Always confirm GPU exclusivity when benchmarking.

Verifying the Fix

Change one flag at a time and measure, so you know which change actually helped:

1. Run a fixed multi-turn prompt of a known token length with your baseline flags and record the prefill time and tokens-per-second shown in the server log.
2. Apply --cache-type-k q8_0 --cache-type-v q8_0 and re-run the identical prompt. Note the change in decode speed and the lower VRAM reported by nvidia-smi.
3. Add -fa and re-run. Confirm the flag was accepted (the log states whether Flash Attention is active) and note the prefill improvement.
4. Finally, load a genuinely long context near your -c limit and confirm the server no longer stalls on context shift the same way.

If decode speed improves but prefill is still slow, you have fixed the cache but still need better attention (step 3). If memory drops but speed does not improve, your bottleneck is elsewhere—return to the pitfalls list and re-check clocks and layer offload.

Putting It Together: A Practical Starting Point

A reasonable baseline for a 16 GB card running a ~14B quantized model with a moderate context looks like this (flags shown as llama.cpp accepts them):

llama-server -m models/model-Q8_0.gguf \
  -ngl 99 \
  -c 8192 \
  -fa \
  --cache-type-k q8_0 \
  --cache-type-v q8_0

Adjust -ngl down (and consider --no-offload-kqv) only if you hit CUDA out of memory during load or when the context grows. Adjust the context size down if you still see stalls. The point is not any single magic value; it is understanding that the long-conversation slowdown is a cache problem, and that the cache is something you can deliberately size, quantize, and accelerate.

Conclusion

When a local model starts fast and ends slow, the weights are almost never the culprit—the KV cache is. By separating model memory from cache memory, quantizing the cache, enabling Flash Attention, and right-sizing your context, you can hold longer conversations without the telltale crawl. Make one change at a time, measure with real logs, and you will know exactly which lever fixed it.

For more on the lower-level mechanics of quantized models and GGUF loading, see our guide on llama.cpp CUDA out-of-memory and layer offload, and for tuning ComfyUI’s own GPU memory under the same constrained card, see our guide to ComfyUI VRAM launch flags.

Primary Documentation

For the current, authoritative definitions of these flags—including --cache-type-k/v, --flash-attn, --n-gpu-layers, and context-shift behavior—consult the official llama.cpp repository and documentation. Flag names and defaults change between releases, so verify them against the exact version you have installed.

One of the most common first-run failures in a Wan2.2 workflow has nothing to do with the 14B diffusion model at all. The queue starts, the model loads, and then the whole graph stops at the text-encoder node with a message that is easy to misread. This article explains why the Wan2.2 umt5-xxl text encoder so often fails to load, what the filename and directory rules actually are, and how to fix the mismatch without re-downloading a single 5GB checkpoint.

Why the Text Encoder Fails First

Wan2.2 is a latent video-diffusion family that depends on a large multilingual text encoder, commonly referred to as umt5-xxl, to convert prompts into conditioning for the diffusion model. Unlike the smaller CLIP-based encoders used by SD1.5 and SDXL, umt5-xxl is a big transformer on its own. In its fp8 form it still weighs roughly 5.7GB, and in many distributions it ships as a separate .safetensors file rather than being bundled into the diffusion checkpoint.

Because it is a separate file, the loader node has to resolve it by name, and the name has to resolve to a file inside a specific directory. When either the filename or the directory does not match what the node expects, the node fails before any sampling happens. The error usually looks like the model “is not there” even though it clearly exists on disk.

The Three Things That Must All Agree

A text-encoder load succeeds only when three independent values line up. When diagnosing a failure, check each one in order.

• The file actually exists on disk, in the directory ComfyUI scans for text encoders.
• The filename in the node matches the file on disk exactly, including case, underscores, and the .safetensors extension.
• The loader node type matches the encoder format — a CLIP loader, a WanVideo-specific text encoder loader, or a generic loader.

Almost every “text encoder not loading” report on a Wan2.2 workflow reduces to one of these three values drifting out of sync, most often after a model was downloaded under a slightly different name than the workflow template expected.

The fp8 Filename Contract

Wan2.2 community workflows and the Comfy-Org official releases use a consistent naming scheme for the text encoder. The fp8 quantized encoder is typically distributed as umt5_xxl_fp8_e4m3fn_scaled.safetensors, while the higher-precision variants drop the fp8 token or use a different precision suffix. The important detail is that the name is a contract, not a suggestion: a workflow authored against umt5_xxl_fp8_e4m3fn_scaled.safetensors will not silently accept a file named umt5-xxl-enc-fp8_e4m3fn.safetensors even though the two are the same underlying encoder.

The same consistency applies to the diffusion models. The Comfy-Org Wan2.2 release files follow a pattern like wan2.2_t2v_high_noise_14B_fp8_scaled.safetensors and wan2.2_t2v_low_noise_14B_fp8_scaled.safetensors, where the _high_noise_ and _low_noise_ tokens select different noise-level experts of the same 14B model. Understanding this naming discipline makes it much easier to spot when a migrated workflow still points at an old filename.

Diagnosing the Mismatch Step by Step

Start with the directory, because that is the failure that looks most like a “missing model.” ComfyUI scans specific folders under the models directory: text encoders live under models/text_encoders/, not under models/clip/ and not under models/diffusion_models/. A diffusion model placed in the text-encoder folder, or a text encoder placed in the diffusion-models folder, will not appear in the dropdown of the node that is supposed to load it.

Next, confirm the exact string the workflow is asking for. In the UI, click the loader node and read the value of its model or clip_name field. In API-driven flows, find the node with "class_type": "CLIPLoader" (or the WanVideo text-encoder loader) and read its clip_name input. Compare that string character-for-character against the filename on disk.

Finally, verify the loader matches the encoder. umt5-xxl is a T5-family encoder, so it belongs in a loader that expects a T5/umt5 format, not the clip_l/clip_g dual-loader used for SDXL. Mixing these up produces a state-dict or dtype error at load time rather than a clean “not found.”

The Most Common Fixes

Once you have located the mismatch, the fix is usually one of three small, reversible edits:

• Rename the file to match the workflow’s expected name (or update the node’s value to match the file you have). Renaming the file is the safer choice when you have multiple workflows sharing one encoder, because a single canonical name keeps all of them working.
• Move the file into models/text_encoders/ if it landed in the wrong directory during download.
• Switch the node to the correct loader type if the encoder was mapped through a CLIP-specific node.

None of these requires re-downloading the 5.7GB encoder. The checkpoints are identical bytes; only the name and location are wrong.

A Note on Precision and VRAM

The filename also encodes precision, which matters for people on tight VRAM budgets. The recommended order of preference for Wan models, from highest quality to smallest footprint, is generally fp16, then bf16, then fp8-scaled, then plain fp8. The scaled suffix indicates a per-tensor scaling calibration that recovers some of the quality that naive fp8 quantization loses. If you are moving a workflow from a cloud GPU to a 16GB local card, selecting the _fp8_scaled encoder rather than the fp16 encoder is often the difference between a graph that fits and one that exhausts VRAM before the diffusion model even loads.

For a deeper look at fitting large diffusion models onto consumer cards, see our guide to Wan2.2 Animate 14B on 16GB VRAM, and for the broader stack the model belongs to, read our overview of the open-source video generation stack.

Verifying the Fix

After correcting the name, directory, or loader, do not just wait for the image. The text encoder runs first and fails fast, so a successful fix shows up quickly: the loader node’s dropdown will now list the file, and the queue will advance past the encoding stage to the sampling stage. In the console or API response, watch for the text-encoder node to complete without a state-dict or “not found” error, then confirm the diffusion model begins sampling.

If the error still names the same file, re-read the exact string the node is asking for — the lingering problem is almost always a residual character difference (an underscore versus a hyphen, or a missing _scaled suffix) rather than a genuinely corrupt model.

Conclusion

The Wan2.2 text-encoder “not loading” error is a filename-and-directory problem, not a hardware or download problem. The fix is to make the file’s name, its directory, and the loader node agree — a rename, a move, or a node swap — and to keep in mind that the fp8_scaled vs fp16 choice encoded in the filename has real VRAM consequences on local hardware.

Primary Documentation

For the authoritative reference on Wan model files and precision variants, consult the WanVideoWrapper repository documentation and the official ComfyUI documentation. Verify the exact expected filenames against the version of the workflow and wrapper you have installed, because naming can shift between releases.

What the “Reconnecting” Overlay Actually Means

If you have used ComfyUI for more than a few days, you have almost certainly seen it: a small overlay in the corner of the canvas scrolling the word “Reconnecting” while the graph refuses to run. It can last a second, or it can sit there indefinitely. Either way, it means the same thing — the browser tab has lost its live connection to the ComfyUI server that is rendering your workflow.

The ComfyUI frontend is not a static web page. The moment the server starts, it exposes a WebSocket endpoint (by default ws://127.0.0.1:8188/ws) that the browser opens alongside the normal HTTP page. This socket is what pushes live progress updates, node execution status, preview images, and error messages back to the canvas in real time. When that socket drops, the frontend has no way to know that a generation is still running, so it shows the “Reconnecting” indicator while it repeatedly tries to re-establish the link.

The key thing to understand is that “Reconnecting” is a symptom, not a root cause. It tells you that the client lost the backend, but it does not tell you why. The distinction matters, because the fix for a crashed server is completely different from the fix for an overloaded browser tab, and mixing them up will send you in circles.

For a broader look at how the ComfyUI frontend and its HTTP API fit together, see our earlier breakdown of the open-source video generation stack on consumer hardware.

The Three Most Common Root Causes

When you strip away the noise, a persistent “Reconnecting” state almost always traces back to one of three things. Diagnosing which one you are dealing with should be your first step, before you change a single setting.

1. The Backend Process Actually Crashed

The most serious cause is the simplest to confirm. If the Python process running ComfyUI dies — from an out-of-memory kill, a custom node that raises an unhandled exception, or a hardware reset — the WebSocket closes instantly and the browser will spin “Reconnecting” forever, because there is nothing left to reconnect to.

Look at the terminal window where you launched ComfyUI. If it shows a traceback, a Killed message, or simply returned to the shell prompt, the server is down. This is common on 16GB-class cards when a video model like the Wan2.2 series pushes memory past the limit and the OS OOM killer steps in. The overlay is not the problem — the crash is.

2. A Long-Running or Blocking Operation on the Main Thread

ComfyUI executes prompt turns on the main event loop in many configurations. While a workflow is running — especially a heavy video generation or a node that does a lot of CPU-bound preprocessing — the server may not respond to the WebSocket heartbeat quickly enough. The browser interprets the silence as a dropped connection and flips to “Reconnecting,” even though the generation is still chugging along fine.

This is why the overlay often appears and disappears on its own without you touching anything. The socket reconnects, the frontend catches up on progress, and everything continues. It looks alarming but is frequently harmless.

3. Custom Nodes or a Slow Start Blocking Server Readiness

A related but distinct cause shows up at startup, not during generation. Every custom node package in your custom_nodes directory is imported when the server boots. Some of these packages — particularly larger ones or ones with heavy dependencies — take a long time to import. While imports are still running, the HTTP server may accept the page request but the WebSocket handler is not yet ready, so the first thing you see is “Reconnecting.”

Community reports on the ComfyUI desktop issue tracker describe exactly this: a desktop install that takes minutes to reach the UI, driven by a handful of slow custom node packs competing for import time. Disabling the offender in the Manager and restarting is usually enough to confirm it.

A Step-by-Step Diagnostic Path

Work through these in order. Each one either fixes the problem or narrows down where it lives, and none of them require guessing.

Step 1 — Confirm whether the server is still alive. Navigate to http://127.0.0.1:8188/ in a fresh tab. If the page loads but the graph never connects, check the terminal for a traceback. If the terminal shows a clean running state, the backend is up and the problem is on the connection side.

Step 2 — Watch the terminal during the “Reconnecting” episode. Trigger a generation and keep an eye on the console. If you see progress logs continuing while the overlay spins, you are looking at cause #2 (a blocking operation) and the connection will recover. If the logs stop dead, you are looking at cause #1.

Step 3 — Test the WebSocket in isolation. The browser’s own developer console (F12 → Network → WS) will show the WebSocket frames and any error. A clean 1006-style abnormal closure points at the server or an intermediary; a series of failed name resolutions points at the address being wrong (for example, accessing localhost from a different machine).

Step 4 — Isolate custom nodes. If the overlay appears mainly at startup or when a specific node runs, launch ComfyUI with custom nodes temporarily disabled and start re-enabling them one batch at a time. This is the fastest way to pin a single pathological package.

Step 5 — Check the transport, not the server. If you are reaching ComfyUI through a reverse proxy, running it in a container, or accessing it from another machine, the WebSocket is the first thing that breaks. Confirm that your proxy forwards the /ws upgrade correctly, and that you are using the same hostname the browser used to load the page.

Common Pitfalls That Keep the Error Around

A few failure modes look like the reconnect problem but are actually misdiagnosed, and they will keep throwing you off until you recognize them.

Accessing localhost from a remote browser. ComfyUI binds to 127.0.0.1 by default. If you open the UI from another machine using localhost:8188, you are pointing at your own machine, not the server. Use the server’s actual IP or hostname, and add --listen to the launch command if you need it to accept non-local connections.

VPNs, VPN kill-switches, and Tailscale. The WebSocket is a long-lived connection. If your VPN re-keys or a Tailscale interface flaps mid-generation, the socket drops and the overlay appears even though both the browser and server are healthy. This matches multiple community reports where the error only happens on certain network paths.

RAM/VRAM exhaustion rather than a real crash. On consumer hardware, a video model bumping into the VRAM ceiling can stall the process long enough to trigger the overlay without actually terminating it. If your “Reconnecting” correlates with heavy Wan2.2 or similar workloads, check your memory situation first — the fix may be a smaller resolution or a different set of VRAM launch flags rather than anything network-related.

Windows kernel timer resolution. Some Windows users report that the overlay is far more frequent when the system timer is at a coarse resolution, which delays WebSocket heartbeats. Running ComfyUI on a power plan that keeps the CPU at full clock, or disabling aggressive sleep, has resolved intermittent reconnects for a subset of reports on the official ComfyUI GitHub discussions.

How to Verify the Fix Actually Worked

You should not declare victory just because the overlay stopped flashing for a minute. A real fix survives a repeatable test.

1. Run a known-good workflow end to end. After applying any change, submit a simple generation and confirm the progress bar updates continuously from start to finish with no overlay flicker.

2. Stress the socket with a long task. The blocking-operation cause only shows up on long generations. Run a heavier workflow — a multi-step upscale or a short video clip — and watch for the overlay during the longest step. A healthy connection should stay silent the whole time.

3. Check the terminal for a clean close. When you stop ComfyUI, the process should exit without a traceback. A stack trace on shutdown is a sign that a custom node is still misbehaving and will likely bite you again.

4. Confirm network stability for remote setups. If you access ComfyUI remotely, run a couple of generations back to back and watch for the overlay appearing at regular intervals. Periodic drops on a fixed cadence almost always point to the transport (proxy, VPN, or Wi-Fi), not the server.

Conclusion

The “Reconnecting” overlay is ComfyUI’s way of telling you the live socket between browser and backend has gone quiet. On its own it is harmless — it often clears the moment the server catches up. But when it sticks, it is a signal that something specific is wrong: the backend crashed, the main thread is blocked, a custom node is delaying startup, or the network transport between you and the server is flapping.

The fastest path to a stable connection is to stop treating it as one generic error and instead pin down which of those categories you are in, using the diagnostic order above. Confirm the server is alive, isolate custom nodes, check the WebSocket transport, and only then worry about deeper memory or system-tuning issues. Do that, and the overlay goes from a recurring source of dread to a one-line signal you can read in seconds.

For the full context on how ComfyUI’s frontend, WebSocket, and HTTP API work together — including how to drive them programmatically — see our guide to automating ComfyUI over its API. For current, version-specific details on the interface and its configuration, refer to the official ComfyUI documentation.

Why ComfyUI “Randomly” Breaks After an Update

One of the most frustrating ComfyUI experiences goes like this: everything was working yesterday, you ran an update, and suddenly the same workflow that produced clean images now throws a confusing error — often something about float16 and float32 not matching, or an operation that “expected half” but “got float”, or a node silently returning zeros and producing black output.

The instinct is to blame ComfyUI core. In most cases, that instinct is wrong. ComfyUI itself is a stable, well-tested base. What breaks is almost always a custom node that sits on top of it — a plugin whose author has not yet caught up with a change in ComfyUI’s internals, or a plugin that patches model precision in a way that conflicts with newer inference paths.

This article walks through a concrete, repeatable diagnostic workflow for finding which custom node broke your install and neutralizing it, so you can stop reinstalling ComfyUI from scratch every time an update changes the ground under your feet.

Read the Startup Log Before Touching Anything

The single most valuable diagnostic artifact you already have is ComfyUI’s console output at startup. Custom nodes load during boot, and when one fails to import cleanly, ComfyUI usually prints an explicit (IMPORT FAILED) marker followed by the node package path and the underlying Python traceback.

The pattern looks similar to this:

### Loading: ComfyUI-Custom-Scripts (x.x.x)
### Loading: ComfyUI-FreeU (y.y.y)
(IMPORT FAILED): /path/to/ComfyUI/custom_nodes/ComfyUI-FreeU
Traceback (most recent call last):
  ...
AttributeError: module 'comfy.samplers' has no attribute 'FreeU2'

An (IMPORT FAILED) line is a smoking gun. The node package listed right after it could not be initialized at all, which means every node it provides is missing from your workflow — often causing “invalid node type”, “type undefined”, or the model-loading error you later see when a required node simply never registered.

If you are on a desktop install, launch ComfyUI from a terminal and scroll the boot output. If you run headless through a service, check wherever stdout is captured (your supervisor or systemd journal). Do not skip this step — many people spend hours re-downloading models when the answer was already printed on line 30 of a log they never read.

The dtype-mismatch Error Is Usually a Plugin, Not a Model

A specific class of error that surfaces after updates is a dtype mismatch: messages reporting that a float16 tensor was passed where float32 was expected, or that an operation “could not be run with the given precision.” Users frequently assume this means their checkpoint is corrupted or the wrong precision variant was downloaded.

In practice, this kind of error is often the signature of a custom node that hooks into the sampling or model-loading pipeline and assumes a fixed precision. A documented example is FreeU variants: the advanced FreeU nodes patch model weights during sampling, and if they were written against an older ComfyUI patch system, an update that changes how those patches are applied can surface as a confusing dtype error rather than a clean crash. The fix reported by users was not “downgrade your model” but “remove the stale plugin” — after which generation worked again. If you are new to local AI, our guide to running the ComfyUI VRAM launch flags explains how --lowvram and --normalvram interact with exactly these model-loading paths.

The general lesson: if a workflow ran fine on one model precision and now throws dtype errors after an update, suspect the nodes that touch the model or sampler. Bisect them before you touch the model files.

Bisect custom_nodes to Isolate the Culprit

ComfyUI loads every folder under custom_nodes/, so the fastest isolation technique is a binary search over those folders rather than guessing one by one. (The official ComfyUI docs on custom nodes confirm that any directory placed there is auto-imported at startup, which is exactly why a bad plugin can take down otherwise-healthy workflows.)

A reliable approach:

1. Snapshot a known-good baseline. Move every custom node folder into a temporary directory outside custom_nodes/ so ComfyUI boots with zero plugins. Confirm the core UI loads and a trivial built-in workflow (e.g. empty-latent-image to KSampler) runs. This establishes that core itself is healthy.
2. Re-add in halves. Move half the folders back, restart, and load your broken workflow. If it fails, the culprit is in that half; if not, move the other half back.
3. Recurse. Keep halving the responsible set until you reach a single folder.

You can also use ComfyUI-Manager rather than moving folders manually. ComfyUI-Manager (from the official Comfy-Org/ComfyUI-Manager repository) lists installed custom nodes and lets you disable or enable them from the UI, and it surfaces import errors and available Git updates for each package. Using its disable toggle for the same bisection is faster and avoids accidental folder damage, though the manual folder approach works even when Manager itself fails to load.

Key point: restart ComfyUI after each enable/disable change. Import-time failures and registration order are evaluated at boot, so toggling a toggle without restarting tells you nothing.

Fix It: Update, Pin, or Remove

Once you have identified the offending node, you have three realistic options, in order of preference:

• Update the node. Most actively maintained nodes ship a fix for a breaking ComfyUI change within days. Run the updater in ComfyUI-Manager, or git pull inside the node’s folder. This is the strongest fix because you keep the functionality.
• Pin to a compatible ComfyUI commit. If the node is abandonware but you genuinely need it, you can roll ComfyUI core back to the last commit that worked with it (using git checkout in the ComfyUI repo) and freeze custom_nodes updates. This buys time but leaves you vulnerable to security and feature lag.
• Remove or disable it. If the node is unused or has been superseded, disable it. A node you installed on a whim and never used is precisely the kind of plugin that quietly breaks the whole install later.

Resist the reflex to reinstall ComfyUI from scratch. A clean reinstall may temporarily remove the broken plugin, but if your workflows depended on it (or on any of the other nodes you lose), you will either reintroduce the bug or spend hours rebuilding state you could have preserved with a five-minute bisection.

Prevent It From Happening Again

A few habits make the next update painless:

• Keep a startup-log baseline. After a known-good boot, save the console output. The next time something fails, diff the new log against the baseline and look at what changed — usually an IMPORT FAILED or a new warning is the first clue.
• Update deliberately, not eagerly. Do not blindly click “update all” in ComfyUI-Manager. Update core and nodes separately, test after each, and keep a mental note of which nodes you actually use so you can disable the rest.
• Prefer maintained nodes. Before installing a node, glance at its repository for recent commits and open issues mentioning the ComfyUI version you run. A node whose last commit is two years old is a time bomb on the next core update.
• Version-pin a working environment. For production or repeatable pipelines, snapshot the Git commit of both ComfyUI core and each custom node you depend on, so you can reproduce a working stack on demand.

ComfyUI’s flexibility comes from the custom-node ecosystem — and that ecosystem is also the most common source of “mysterious” post-update failures. Learning to read the boot log and bisect custom_nodes/ turns a day-long panic into a ten-minute cleanup.

Conclusion

When ComfyUI breaks after an update, the problem is rarely the model and almost never the base application. It is a custom node that no longer matches the version of core it was written for. Trace the (IMPORT FAILED) markers in your startup log, bisect the custom_nodes/ folder to isolate the culprit, then update, pin, or remove it. Treat a dtype-mismatch error as a sign to inspect the nodes touching your sampler and model loader — not as a reason to redownload checkpoints. Do this before you reach for the nuclear “reinstall everything” option, and you will recover faster and keep your working pipelines intact.