ComfyUI Detail Daemon reshapes the sigma schedule instead of the prompt

A port of a web UI extension

The project is a port of muerrilla's sd-webui-Detail-Daemon, and the original lives in a different host application, the Stable Diffusion web UI. The job is to adjust sigmas, which generally enhance details and possibly remove unwanted bokeh or background blurring, and the README is careful about the model support, saying it is particularly effective with Flux models but also works with SDXL, SD1.5, Qwen, Z-Image and likely other models. The same paragraph contains the warning that matters in practice, that if the values are taken too far the result is an oversharpened or HDR effect. The whole project is a single idea ported between two host applications, and the ports that survive the move are the ones that expose enough parameters to be tuned, which is why the node list is longer than you would expect for a single effect.

Five nodes for one adjustment

The node list is short and each entry has a distinct job. The Detail Daemon Sampler is the core, and it allows sampling with the schedule adjustment, keeping the noise levels injected the same while lowering the amount of noise removed at each step. The Detail Daemon Sampler GUI combines that sampler with a live interactive schedule graph in one node. The Detail Daemon Graph Sigmas node exists to graph the adjustment visually, and the README explains why it had to be a separate node, since it needed to function properly on its own, with the note that it does not actually change the sigmas used when generating, it only graphs them. Multiply Sigmas is a stateless alternative that multiplies all sigmas by a supplied factor, and it multiplies both the noise added and the noise denoised, which somehow adds detail with a factor less than one. The Lying Sigma Sampler is the third method of enhancing details. Example and testing workflows are linked from the README, and a video demo of the technique in action is credited to another creator.

Why changing the schedule adds detail

The explanation in the README is the part to understand before you touch a slider. Large features are established in earlier steps and small details take shape in later steps, so adjusting the amount in the earlier steps affects bigger shapes and adjusting it in later steps influences smaller fine details. The default adjusts mostly in the middle steps, which is a sensible compromise between the two. The core mechanism is stated for the sampler node, and it is precise. The noise levels injected stay the same, but the amount of noise removed at each step is lowered, and that is what effectively adds detail. That is a different lever from the one a prompt pulls. A prompt asks the model for a sharper subject, while this changes how much of the early noise survives to be denoised, and the two compose.

The parameters, and their recommended ranges

The parameter list is where the node stops being a black box. The main value, detail_amount, adjusts the detail in the middle of the generation process, and positive values lower the sigmas, reducing noise removed at each step, which increases detail, while negative values decrease detail or simplify the image. The recommended range depends heavily on the model, since Flux or Z-Image probably want between 0.1 and 1.0 or higher while SDXL probably wants less than 0.25, and the general guidance is that amounts between 0 and 1.0 work best. The start and end parameters say when the adjustment begins and ends as a fraction of the steps, with recommendations of 0.1 to 0.5 and 0.5 to 0.9. The bias shifts the detail amount in the middle steps forward or back in the process, the exponent changes the curvature of the adjustment with 0 as no curvature and 1 as smoothly curved, and start_offset, end_offset and fade adjust the beginning, the end and the whole curve, with start_offset explicitly not recommended. A smooth flag turns the curve smoothing on or off, and a cfg_scale_override of 0, the default, lets the sampler determine the CFG scale itself if it can, while any other value overrides it and should probably match the CFG used in the workflow.

The graph node, and why the graph is separate

The GUI node is the most interesting piece of interface work in the repository, and it works by making the schedule a thing you drag. It combines the sampler with a live interactive schedule graph, and you connect both the sampler and the sigmas, with the node outputting the wrapped sampler followed by the unchanged sigmas. The handles are colour coded by what they edit. Dragging the blue start handle edits start and start_offset, dragging either purple E handle vertically edits the exponent with both handles staying synchronised, the yellow peak handle edits bias and detail_amount, and the red end handle edits end and end_offset. Editing any numeric widget redraws the graph immediately, and double-clicking the graph resets the curve controls to their defaults. Two design details make this usable in practice. The horizontal axis is normalised from 0% to 100%, so the graph is usable before queueing and stays independent of the workflow's actual step count, and the graph state is derived from the node widgets and is preserved by ordinary ComfyUI workflow serialisation, so it survives a save and reload.

The sampler compatibility note

There is a caveat in the README that will save you an hour if you read it first. The Detail Daemon and Lying Sigma Sampler nodes work by default with custom sampler nodes such as SamplerCustomAdvanced, because that is where the sigmas can be intercepted. If you want to use them with non-custom sampler nodes such as KSampler or KSamplerAdvanced, you need to make a custom sampler preset using the BlehSetSamplerPreset node from another project, so that you can select the preset from the list in the sampler node. The README links to a discussion thread where that is worked through. The reason the core sampler node takes over sampling is the same reason the graph node had to be separate, that the adjustment has to happen between the sigma schedule and the denoising steps, and a node that does not expose its schedule gives you nothing to adjust.

Packaging for ComfyUI and the registry

The repository is a ComfyUI custom node package, with the top level holding the Python entry point, the node implementation, a web/ directory for the frontend part of the interactive node, an example_workflows/ directory, a node.zip archive, the icon image and the packaging files. The project file names the package comfyui-detail-daemon, gives the version as 1.2.0 and declares a single runtime dependency, matplotlib, which is there for the graphs. The interesting part is the tool.comfy section, which registers the node with the Comfy Registry using a publisher id, a display name and the icon URL, with a comment in the file noting that the section is used by that registry. That is a newer piece of infrastructure than most ComfyUI extensions target, and it means the node is installable through the registry rather than only by copying files into a custom nodes directory. The licence is MIT, the repository is not archived, the last push was on 2026-08-18, and no GitHub releases are published.

Editorial conclusion

ComfyUI Detail Daemon fits a ComfyUI user who has hit the limit of what the prompt can do for fine detail, since it acts on the sampling schedule rather than on the conditioning, and the graph node makes the change legible before you queue a job. It does not fit a workflow built on the plain samplers, because the nodes expect a custom sampler and the README sends you to a third party preset node to bridge the gap. It does not fit someone who wants a single control, because the effect depends on where in the schedule you apply it. Before you use it, read the parameter ranges per model, since the recommended detail amount is roughly a quarter of what Flux wants against what SDXL wants, and note the release state, with the package at 1.2.0 and no GitHub releases published.

Frequently asked questions

Official sources

1. Issues
2. Jonseed/ComfyUI-Detail-Daemon on GitHub
3. License: MIT
4. README