Local AI Images and Video: Why ComfyUI Keeps Coming Up ​

We · October 2026

This is the sixth article in the "AI Tech Explainers" series. Running an Open Model on Your Own Computer: What the Four Layers of Tools Each Do followed the language-model line; this one applies the same layering to images and video. Its line that software does not produce models—the model files are the asset—has a counterpart here, and Where Model Files Come From: Repos, Community Quants, and Licenses is where that was argued. No product reviews, no rankings, no download or sign-up links.

AI moves fast. The tools, models and numbers in this article describe where things stand right now and are for reference only; all figures were checked in October 2026, and exact capabilities and license terms follow each project's official site and its code and model repositories.

First, a premise to correct: this layer does not compete on image quality ​

The first question most people ask when choosing a tool is "which one makes prettier pictures". That question has no answer, because image quality does not live at this layer. The same model file, run inside any interface, produces the same thing—what decides the level of the picture is that file (and how large a version of it you can fit), and what decides the experience is the interface.

So we suggest trading the selection question for four that can actually be answered: how soon do I get to use a new model, can this result be repeated exactly next time, how hard does my machine's VRAM get squeezed, and when something runs wrong, can I see the middle steps.

These four also explain the single biggest shift of focus at the image and video layer over the past two years: why almost every newly released model can run inside this one piece of software, while several once-popular interfaces increasingly show up as "it will not load".

ComfyUI image workflow template

Three routes, and where each stands ​

There is no ranking in this table, only direction. The state of the second route can be pinned to release dates you can check in the code repositories (queried October 25, 2026): A1111's last official release was February 2025; the Forge repository written by that same original author stopped being pushed in mid-2025; Fooocus's official version stopped in August 2024. Over the same period ComfyUI shipped two versions back to back in mid-October, and Invoke—another project off the node route—released a new version that same week. The star counts on those old repositories are still very high—large numbers of people are still using them, and they no longer follow the new models forward; both of these are true at once. The form route today is mainly held up by community-driven successor projects: small in scale, but still updating.

Why almost every new model lands here first ​

This is the part the article most wants to make clear. The answer is not "the community is more enthusiastic". It is four engineering reasons you can put your finger on.

First, the way weights are laid out happens to match the way it reads them. When a model lab releases open weights, they usually come as several separate files sorted by role: the backbone that does the computing, the text encoder that reads your words, and the decoder component (VAE) that turns the result back into pixels. The reason is that weight-hosting platforms cap a single file's size, so a model of tens of GB must be cut into pieces. A node-based interface is built from three different loading blocks, each reading one kind of file—its internal structure is the same shape as the vendor's release structure. The older single-page interfaces, by contrast, expect one complete everything-in-one-file bundle, so every time a new architecture arrives somebody has to volunteer a merge and a rewrite first—and that step stalled a great many attempts.

Second, the framework side steps in and repackages the weights itself. Now, whenever a release gets any attention, the official organization opens a matching repack repository on the weight-hosting site: the directories sorted into backbone, text encoder, decoder component, style modules (LoRA) and vision control models, usually with ready-made example workflows attached—you follow the directory, drop the files into the matching local spots, and it works. The Wan-family video models, Z-Image, MOSS-Image, Qwen-Image, Lightricks' LTX and MiniMax's video models all went this way (checked October 2026). MOSS-Image, released just last week, is a live example: within days its community-site downloads reached the million range (as reported publicly), and most people's first successful run came purely from the ready-made directory structure and example workflows in that repack repository. The practical meaning is this: whether you can run a new model stopped being a question of conversion and became a question of clicking download.

Third, "supported on the day it goes open source" has become a standard line in the release post. When Qwen-Image 2.1 shipped—a 7B image weight that folds text-to-image, image editing and transparent-channel output into one model—its support statement listed five or six frameworks at once, and this layer was among them. When MiniMax H3 shipped—a 33B video model with a synchronized audio track generated natively—its official support included four template sets for text-to-video, image-to-video, first-and-last-frame control and reference images, and a pruned, quantized version landed the same day so consumer GPUs could run it too. Turn the vendors' calculus over and it says: to have local users actually playing with a model on day one, wiring into this layer is the best return per unit of effort, because it does not wait for an interface redesign. Vendors keep choosing to come first, and that is exactly why this ecosystem keeps its one-length lead.

Fourth, VRAM and quantization are solved at the framework layer. Chunked offloading when a big model will not fit in VRAM, 8-bit and 4-bit low-precision loading, GGUF-style compressed formats made for local machines—all of it is maintained centrally by the core plus a set of community repositories. So things like "running a video model of ten-plus billion parameters on 12GB of VRAM" or "the quantized build producing clips on an entry-level card" do not need to be implemented again by every application. The compression and offloading explained in Parameters, Quantization, VRAM: Why “It Fits” Is Not “It Runs” work the same way on the image and video side—the framework does it for you.

How cheap a node is to write, and why developers show up ​

If the last section explained why vendors come first, this one explains why it always catches the loose ends the vendors never got to.

Adding one new block costs almost nothing. A node is essentially one class that declares three things: what type of input it eats, what type of output it spits, and which method it calls to do the work; then one more line registers it. Drop the file into the plugin directory and the program scans and loads it at startup—no core code changes, no compilation, nobody's approval needed. A block that inverts an image runs to the order of a few dozen lines. The newer APIs also made data like images, intermediate state and video into standard, validated types, so when something breaks the error names the block and the input.

That low threshold directly determines the shape of the ecosystem: any lab, any technical artist who knows a few lines of Python can turn the one missing step into a block, and somebody else is using it the next day. The order of magnitude the official page gives: over 60,000 custom nodes and thousands of community workflows (the publisher's own figures, checked October 2026, kept as an order of magnitude). That count and its speed at catching new models are not two advantages—they are two faces of one thing.

There is one more mechanism, easy to miss and the one that matters most to studios: the picture on the canvas is itself the interface. A saved workflow is a JSON file, and the same file can be loaded into the interface for a human or submitted as it stands as one request to the local API. Which means a designer's flow can be wired into a batch script, or into a production pipeline, without touching its structure—this is the dividing line between "a personal toy" and "a pipeline that delivers", and it is why teams are willing to pay the learning cost. Stack on top that the official command-line tool, the node registry with version management and security scanning, and the partner nodes that bring closed services into the same graph (the industry already plugs cloud image and video services, and 3D generation, in as nodes), and this layer has in fact become the general execution environment for visual generation: pictures, clips, audio, 3D—all can appear on one canvas. Even the kind of agent described in What Is MCP? Why It Became the Connection Standard for AI Tools works this way—it does not draw anything itself; it translates "what I want" into one call to this layer, and the long chain of nodes stays the same chain.

For designers, the pull is really four concrete things: the workflow is a file, and files travel—it saves as JSON, and can even hide inside the extra information attached to a finished image, so another person drags it in and it runs, without asking you "which plugins did you install, how did you tune the parameters"; there are far more ready-made flows than you expect—official templates plus the community workflow sites, and most people's daily reality is downloading somebody else's flow and swapping the prompt and the size; complexity can be hidden—take a two-hundred-block graph and expose only two or three inputs, switching back to the full view when you need it; "using someone else's" and "building your own" are two views of one piece of software; you do not have to change where you work—canvas drawing software, editors and 3D tools all have plugins that call this layer as a backend.

Our view: saying "node graphs are too hard" is no longer an accurate assessment. The hard part was never reading a diagram—it was setting up the environment, hunting for files, filling in missing plugins. And those three are precisely the parts that got the most attention in the past two years.

Images and video are now the same software ​

This is the layer's biggest change in those two years: making pictures locally and making clips locally use the same software and the same model catalog. The only difference is which output you want, and the output type decides how heavy a load your machine has to carry.

First, what is happening. On the image side, the new models—FLUX.3's Image Klein, Qwen-Image 2.1, MOSS-Image—share three traits: generation and editing live in the same weights, you can feed in several reference images at once, and a language model reads your prompt (which is why the official advice is to write a full paragraph of description rather than pile up keywords—also why the two-year-old tutorials suddenly stopped working). On the video side, the community's verdict when it took stock of the first half of 2026 was that open-source video models had started competing on local usability—first guarantee it runs on a consumer GPU, then talk about the quality ceiling. Put the two together and the result is: they are no longer two pieces of software, but two kinds of flow inside one.

Below are the open-source models you most often meet locally now (both tables run roughly from recent releases back to the previous generation—not a ranking, and not a recommendation; figures checked October 2026; different tiers from the same vendor can carry completely different licenses, so always go by the repository LICENSE):

That last row deserves a few more sentences, because to this day a great many people start from it, and the reason it won then and the reason it fell behind now are actually two faces of one thing: the install base grew too thick for anyone to replace wholesale, and that same thickness is the baggage that keeps it from taking on a new structure.

Why everybody piled things onto it back then. Stable Diffusion 1.5 came out in the second half of 2022. At the time, playable text-to-image was either a closed service stuck behind a web queue that gave you no files, or something that did not fit on a home GPU at all. It was the only working model you could download, run on your own computer, and modify. And it was small—the backbone is under 2GB, so an 8GB VRAM card was enough, and many people's machine, previously used only for gaming, instantly became a picture machine. That was the first reason it spread. What actually turned it into an ecosystem was a discovered way of using it: train a small patch (a LoRA) on a few dozen images and you could pin down one face, one art style, one outfit. So "the artist's own style", "a certain character's face", "a certain material" all became small downloadable files that anyone else could mount and use—the hundreds of thousands of style modules on the community sites were overwhelmingly built around 1.5 and SDXL, and that stock is still being mounted and used today. The other half was ControlNet—a set of control modules that turn line art, body pose and depth maps into hard constraints: it made "color inside this line art", "pose it like this", "compose by depth" standard moves, and artists could for the first time slot generation into their own process instead of changing seeds like a lottery. And one invisible thing: it was the first model everybody wrote tutorials for. The vocabulary still in use today—steps, sampler, prompt weighting, negative prompt—all settled around it, and everyone who came after copied that language down. SDXL is the enlarged version of the family, one notch up in resolution and quality, at the cost of eating VRAM; many people's division of labor was "1.5 to practice faces and styles, XL for the final render". By SD3.5 the official side had switched to a new architecture and was trying to bring text understanding in too; composition instruction-following and quality were both better, but the community did not move across—changing architectures meant the entire pile of LoRAs and control modules in hand went void, and training tools and workflow templates all had to be redone. A model truly starts aging not when its quality loses to someone else's, but when the cost of everything around it suddenly goes up.

Why it is no longer the first choice now. However thick that accumulation is, that is how hard its structural assumptions are to change: this family's flow is "one complete weight + a keyword prompt + a sampler", and today's requirement is "generation and editing in the same model, reference images fed in, the picture described in whole natural-language sentences". The two do not line up. In felt terms that is three specific holes: the text inside pictures is basically unusable—Chinese especially, where signs and titles often come out as twisted strokes; to change an existing picture all you have is the local-repaint patch-work, not a model that actually edits; and new-architecture abilities do not descend from the sky into an old weight—this family's models stopped iterating long ago, and the only thing that can still be updated is the software loading them, while the software that updates most eagerly has long since pointed its attention at the newer models up front. So today it looks like an old platform with a very thick pile of standing assets: it still runs, it is still pleasant to use, but new projects no longer start from it.

One more sentence of explanation on the video side—why the two 2025 releases are ranked toward the back and still kept: whether a video model is good to use locally depends not only on its quality at release, but on how much community modification surrounds it. The two Wan versions, precisely because they came out early with a permissive license, now have quantized builds, VRAM-optimized builds, and image-to-video and first-and-last-frame control templates all filled in; many people's "first locally generated clip" still uses them. HunyuanVideo 1.5 is similar—its whole pitch is "easier to fit at the same quality". The newest releases lead on capability, but their companion workflows often need a few more months—which is exactly what the reminder below points at.

The output type decides how heavy a load you carry, and one table makes that clear:

That is, five seconds of video costs two orders of magnitude more than one image. That is not the software's problem; it is the task's. So the second question of tool choice should not be "am I doing images or video", but "which output can this machine of mine carry"—for how to trade VRAM, RAM and waiting time, article three of this series did the same arithmetic; on the video line it only gets harsher.

And one warning to add: the day a model goes open source is not the day you can run it on low VRAM. Quantized builds, pruned builds and example workflows often show up days or even weeks later, and that gap is precisely the position the community repacking and node maintenance described earlier is filling.

Three questions to place yourself ​

1. Do I need to repeat one thing reliably this time, or just make a picture now and then? The first is worth learning the flow properly, even wiring the workflow into a script; the second is fine with a form-style interface or a ready-made template.
2. Which output can this machine of mine carry—one image, or a video clip? That question decides how much you have to install, and it matters more than which software you pick.
3. Am I going to use somebody else's flow or build my own? If borrowed, run it once first to see which extra files it downloads and whether a missing one dies with an error; if built, keep the saved file as an asset.

Interfaces change; workflows stay ​

The tools at this layer turned over faster in the past two years than the language-model layer: a batch of once-most-popular interfaces stopped following the new models, new architectural assumptions kept appearing, and each month brought a new open-source model. We do not recommend betting the choice on which software is hotter, because that changes every few months.

What is worth betting on is the two things that already belong to you: the model files you collected and the workflow files you got straight. The first carry across software; the second record how you intend to do the job—they can be handed to a colleague, re-run exactly on a new machine, and make sure each pitfall you hit this time gets hit only once. As for "open it and it works", the direction matches Where Model Files Come From: Repos, Community Quants, and Licenses: you can already see solutions that package the environment, the dependencies and the common models together, aiming at something like one-click install and out-of-the-box use. What they address is exactly the first hurdle of this layer—not that you cannot draw, but that you have not yet straightened out that machine. The next article applies this layering method to the third category: speech AI is really three things, and what each of hearing it, saying it and sounding like someone is competing on—see Speech AI Is Really Three Things: Hearing It, Saying It, Sounding Like Someone.