PCSplitSampling

Fair warning up front: this node isn't named in the pack's own README, and there's no description attached to it in the node registry either - so what follows is a straightforward reading of what its inputs and outputs actually are, not a restatement of documented behavior. It's a low-traffic, undocumented corner of the pack.

What the schema tells you

It's a MODEL patch - one required model in, one MODEL out - plus a required split_sampling toggle with exactly two choices: enable or disable. That shape (a model patch gated by an on/off switch) matches the general pattern the rest of this pack uses for behavior that has to hook into how sampling actually runs, rather than something that lives purely in prompt text. Given the name and where it sits alongside the scheduling nodes, the reasonable read is that it controls whether Prompt Control resolves a schedule's breakpoints by splitting a single sampling run into separate sequential sampler calls at each breakpoint, versus handling timing entirely through the SetConditioningTimestepRange approach the documented nodes use. Treat that as an informed guess rather than a documented fact, though - the pack doesn't spell it out, and nothing in the source material available here confirms the exact mechanism.

Inputs and outputs

Required: model and split_sampling (enum: enable, disable). Output: MODEL.

Installing it

Same install as every node in this pack - there's no separate step for this one specifically:

cd ComfyUI/custom_nodes
git clone https://github.com/asagi4/comfyui-prompt-control

Or via ComfyUI Manager, searching "ComfyUI Prompt Control". No model downloads involved.

Honest advice here

Given how little is documented about this specific node, the practical guidance is: don't build a workflow around it unless you've read the pack's source directly or confirmed the behavior yourself, and if you do use it, A/B it - run your generation with split_sampling set to enable and again with disable, same seed, and compare. If you don't see a difference for your particular schedule and sampler setup, it's safe to leave at whatever the default behaves as and not worry about it further. This is exactly the kind of node worth asking about directly in the project's GitHub issues if you need certainty - the maintainer is active and the README explicitly invites bug reports and questions about behavior that isn't obvious from the docs.

Why this kind of toggle would plausibly exist at all is worth spelling out, even without a confirmed mechanism. The core tension in prompt scheduling is that a schedule breakpoint like [cat:dog:0.5] is a fraction of the denoise range, but a KSampler runs as one continuous call under the hood - the pack's documented approach handles that by attaching a SetConditioningTimestepRange to each segment of conditioning and letting ComfyUI's sampler respect those ranges within a single call. An alternative implementation strategy for the same problem is to genuinely split the run into multiple, sequential sampler calls, handing the latent from one stage to the next at each breakpoint - which can behave differently around scheduler warm-up, noise carryover, and how some samplers (particularly ones with internal state across steps) treat a "continued" run versus one long unbroken pass. A toggle named split_sampling sitting right where it does, alongside the pack's other scheduling nodes, is consistent with letting you pick between those two strategies - but again, that's inference from the shape of the node, not something the pack states outright.

If you're chasing a specific artifact - a schedule breakpoint that looks like it's causing a visible seam, or a sampler that seems to reset something at each schedule transition - this is the node worth testing first, precisely because it's the one input in the whole pack that looks purpose-built to change how breakpoints interact with the sampling loop itself.