BigPlayer Checkpoint State
Tell the LLM what's already loaded — before it writes you a prompt
- preset_config
- preset_config
BigPlayer Checkpoint State is one of the three "state-indication" nodes in the pack, and they all exist for one purpose: to tell the LLM what your workflow already has, so it doesn't write you a prompt that ignores it. This node does not load a checkpoint, apply anything, or touch your model files. It records a choice and hands it to the root as context.
You get two dropdowns: checkpoint_name and refiner_checkpoint_name. Both list your installed checkpoints plus a <none> option, and both default to <none>. Pick your base model; pick a refiner if you're running a two-pass refiner setup, or leave it alone. The <none> default is deliberate - a state node should never force a choice, and an empty value just adds no context.
How it fits the workflow
The output is preset_config (a BIGPLAYER_PRESET_CONFIG wire, colored purple by the pack's web JS so you can follow it across the graph). State nodes chain: wire Checkpoint State's preset_config into LoRA State or ControlNet State to accumulate a combined picture, then connect the last one into the root's optional preset_config input. When the root builds its request, that context renders as "Workflow preset state provided explicitly: - Checkpoint: ..." inside the prompt, and the LLM is told to craft its prompts around that checkpoint's quirks and prompting preferences.
That last part is the whole point. Prompting style is checkpoint-dependent - an Illustrious finetune wants tag-style prompting and a quality vocabulary, while an LLM-encoded model wants a structured instruction. When the LLM knows which checkpoint is actually in the chain, it writes for that model instead of guessing. The pack's design phrase for this is "work forward from explicit, user-provided workflow state," and this is the checkpoint half of it.
When you'd use it vs. Checkpoint Picker
Easy confusion, worth naming. BigPlayer Checkpoint Picker asks the LLM which checkpoint would suit a new request. Checkpoint State tells the LLM what's already loaded. If you're prompting for your existing setup, use State. If you're exploring "which model fits this idea best," use Picker. They combine fine - State for the current base, Picker for the alternative, you decide.
Install and troubleshooting
Pack install: ComfyUI Manager, search "BigPlayer Prompting", or git clone https://github.com/josh-ent/comfyui-bigplayer-llm-nodes into ComfyUI/custom_nodes, then restart. Deps are just httpx and pydantic; no model downloads. If your new checkpoints aren't showing in the dropdown, restart ComfyUI - the list is resolved at node load. And remember: unless you chain it into the root, this node's output does nothing. The context only matters when the LLM can see it.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| checkpoint_name | COMBO | <none> | Selected base checkpoint, or <none> to leave unspecified. |
| refiner_checkpoint_name | COMBO | <none> | Optional refiner checkpoint, or <none> to leave unspecified. |
| preset_configopt | BIGPLAYER_PRESET_CONFIG | Optional preset config emitted by another BigPlayer state-indication node. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| preset_config | BIGPLAYER_PRESET_CONFIG | — |