LanPaint: a training-free inpainting sampler for ComfyUI, and what its 'think mode' actually costs

The gap LanPaint targets: inpainting without an inpainting checkpoint

Most diffusion checkpoints are trained to generate an image from noise. Inpainting asks a different question: keep the pixels outside a mask, regenerate the pixels inside it, and make the seam between the two look like it was never there. The conventional answer is a dedicated inpainting checkpoint, trained with mask conditioning baked in. That works, but it means a second model download per architecture, and coverage depends on whether someone trained one for the model you actually want to use. The alternative family is training-free: keep the base checkpoint, and steer the sampling process so the unmasked region stays consistent with the original. LanPaint belongs to that second family. The README describes it as "universally applicable inpainting ability for every model" and says the sampler "lets the model think through multiple iterations before denoising", which is the project's own framing for spending extra compute to get a better boundary. The audience is therefore people who already have a ComfyUI graph and a checkpoint they like, and who would rather pay in sampling time than in a new model download or a fine-tune.

What 'think mode' means mechanically

The name is marketing-adjacent, but the underlying idea is stated plainly in the paper title: asymptotically exact and fast conditional sampling. Conditional sampling here means sampling from the diffusion model subject to a constraint, namely that the known region must be preserved. LanPaint inserts additional iterations before the ordinary denoising loop, and the README ties this directly to a dial the user controls: more thinking steps means more computation invested, and the project presents that as the lever for quality at the mask boundary. The repository does not spell out the sampler internals in the README text supplied, so the precise update rule has to come from the TMLR paper linked at the top rather than from the node documentation. What is visible is the shape of the interface: nodes named after the sampler with a step count attached to the thinking phase, for example the README's references to a K sampler with 3 or 5 steps of thinking in the Krea2 and Anima examples, and a custom sampler with 5 steps of thinking in the Ideogram4 example. Treat the step count as the primary cost knob, because that is how the project presents it.

Getting it into a ComfyUI graph

The repository is a ComfyUI extension, so the install path is the standard custom-nodes one: clone or copy the repository into ComfyUI's custom_nodes directory and restart ComfyUI, then load one of the workflow examples. The README's Quickstart and How to Use Examples sections are the authoritative source for the exact node wiring, and the examples directory carries per-model folders, for instance Example_21 and Example_25 for Z-Image and Z-Image-Base, Example_26 for Anima, Example_27 for Ideogram4, Example_28 for Krea2, and Example_29 for the MiniMax H3 video and audio pipeline. Several of those folders ship files literally named to be dragged into ComfyUI, with names like Load_Me_in_Loader and Drag_Me_to_ComfyUI, which is a deliberate convention rather than an accident. The mask is supplied through the normal Loader path, and the README notes that masks can be exported back into the video file itself for the MiniMax H3 case. There is no configuration file documented in the supplied material; the settings live on the nodes. If you are on the Diffusers stack rather than ComfyUI, the README points to a separate repository, LanPaint-Diffusers, maintained by a different author, so the API surface there is not the one described here.

The compute bill and the boundary artefact

Extra iterations before denoising are not free, and the README is explicit that this is the intended exchange: invest more computation time for better inpainting quality. On a short 20-step sampling run, adding 5 thinking steps is a meaningful proportional increase, and on video, where the README's Wan 2.2 example covers 81 frames, the same multiplier applies across every frame. That is the honest case against LanPaint for interactive work: it is a quality dial, not a speed dial, and v2.1.0's new schedule mechanism is described as an acceleration rather than a change in that fundamental trade. The second limitation is documented by the project itself. The v2.1.0 notes point readers to issue 80 if inpainting results show a "weird (glowing / broken) mask boundary". A project that ships a release note directing users to a known boundary artefact is telling you the artefact exists. Whether it appears depends on the model and the mask, and I cannot tell you from the repository alone how often it triggers. The third constraint is breadth versus depth: the example list is long and heterogeneous, spanning image models, video, and an audio-capable pipeline, and each entry implies its own compatibility surface. A wide model list maintained by a small project is a coverage claim, not a guarantee, and the MiniMax H3 fix in v2.1.0 is a reminder that upstream ComfyUI changes can break specific model paths.

Where it sits next to a native inpainting checkpoint

The obvious comparison is a model trained for inpainting, such as the inpainting variants that ship for popular base architectures. The difference is where the mask information enters. A trained inpainting checkpoint has seen masked inputs during training, so the mask is part of the model's conditioning and the sampler can stay a standard one. LanPaint keeps the sampler but changes it, injecting the conditional constraint at sampling time so an unconditioned checkpoint behaves as if it understood the mask. That buys model coverage: any checkpoint the sampler can drive becomes an inpainting model, which is the whole point of the word universal in the README. It costs you the thing training buys, which is a learned prior over how masked regions should be filled. A trained inpainting model has seen millions of examples of holes being filled; LanPaint is reasoning its way there from the base model's existing knowledge plus extra iterations. For a model with strong generative priors and a clean mask, that can be enough. For a model that has never seen the kind of content you are asking it to synthesise inside the hole, extra thinking steps do not manufacture knowledge that was never there. The other alternative worth naming is simply using a different tool for the job: if your need is object removal on a single well-supported architecture, a dedicated inpainting checkpoint is less machinery and fewer moving parts.

Licence, maintenance and the cost of staying current

LanPaint is GPL-3.0. That matters if you intend to redistribute it or ship it inside a product, because the GPL's copyleft terms attach to derivative distribution in a way that permissive licences do not. I am not giving legal advice here; if you plan to bundle this into something commercial, that question belongs with someone qualified to answer it. On maintenance, the release cadence visible in the repository is active: 1.5.5 in late June 2026, 2.0.0 in early August, and 2.1.0 a few days later, with the last push on the same day as the newest release. The 2.0.0 to 2.1.0 gap being three days suggests a fast patch cycle rather than a slow, stable one, and the v2.1.0 notes mention fixing MiniMax H3 support on the latest ComfyUI, which tells you the project tracks upstream ComfyUI closely and therefore inherits its breakage. Budget for periodic updates rather than a set-and-forget install. The upgrade cost is mostly re-validating workflows after a ComfyUI or node update, not migrating configuration, since there is no config file to migrate.

Who should wire this in, and what to check first

LanPaint is a reasonable fit if you run ComfyUI, you have a checkpoint you like that has no inpainting variant, and you are willing to spend sampling time on the boundary. The video and audio pipeline for MiniMax H3, and the Wan 2.2 video examples, are the parts that are hardest to replicate with a plain inpainting checkpoint, because dedicated video inpainting models are scarcer than image ones. It is a poor fit if your workflow is interactive or latency-sensitive, if you only need one architecture that already has a good inpainting checkpoint, or if you need a supported API surface with a stability guarantee. Before committing, run one of the bundled examples for your exact model family rather than adapting a graph from a different one, and check the output at the mask boundary specifically, since that is where the project's own release notes say problems show up. If you hit the glowing or broken boundary, issue 80 is the reference the maintainers point to. The paper is the place to go for the sampler's actual update rule; the README is a usage document and does not attempt to be one.

Editorial conclusion

Adopt LanPaint if you already run ComfyUI and want inpainting from checkpoints you have, rather than downloading and managing a separate inpainting model per architecture. Skip it if your workflow is latency-bound or you only ever need a single well-supported base model, where a native inpainting checkpoint is simpler. Before wiring it into a pipeline, verify three things: that your ComfyUI version matches what v2.1.0 expects, that your specific model family appears in the examples directory, and whether the glowing or broken mask boundary described in issue 80 shows up in your output, since that is the failure mode the release notes point at.

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. scraed/LanPaint on GitHub