Cache Global Parameters
Share one set of prompt params across the graph
- STRING
The rest of JNodes' parameter system works by threading a text list from node to node - you plug your prompt into a reader, and the reader scans it. That's fine in one place. It gets annoying when you want the same <params:...> values available in five different corners of a big graph and you're dragging the same wire everywhere. Cache Global Parameters fixes that: it parses a parameter list once and stashes it in a named global "group," so any reader anywhere in the graph can pull from that group without a wire connecting them.
If you build large workflows and you've felt the pain of spaghetti wires carrying the same text to a dozen spots, this is the node that cuts them. It's a convenience node, not a headline feature, but in a sprawling graph it's the difference between tidy and unmanageable.
How it works
You give it a parameter list - the same <params:name:value> text format the whole system uses - and a group name. It parses those tags and caches the result under that group. From then on, other JNodes parameter readers configured for the same group read the cached values instead of needing the text passed in directly. One node writes the cache; many nodes read it, no wiring between them.
The default parameter_list in the field shows the format: <params:my_string_variable:string> on one line, <params:my_number_variable: 0.5> on the next. One tag per line, and the parsing_key decides what prefix to look for.
The inputs and outputs that matter
parameter_list- the multiline text holding your<params:...>tags. This is the source of truth that gets cached.group- the name of the cache bucket (defaults toDefault). Readers pointed at this group name see these values. Use distinct group names if you want more than one independent set.parsing_key- the tag prefix to match, defaults toparams. Leave it alone unless you've deliberately changed your tag convention.
The output is a STRING - the parameter list, so you can still chain it onward if you want. But the real product is the side effect: the cached group that readers elsewhere can reach.
How to install it
ComfyUI Manager, search JNodes, install, restart. Or:
cd ComfyUI/custom_nodes
git clone https://github.com/JaredTherriault/ComfyUI-JNodes
pip install -r ComfyUI-JNodes/requirements.txt
No models needed.
Common issues & troubleshooting
A reader can't find the value. The group name has to match exactly between this node and the readers. A typo in either place and the reader falls back to its default. Keep the names copy-pasted, not retyped.
Execution order surprises. Caching is a side effect, so the cache has to be populated before the readers run. In a graph where ComfyUI hasn't been given a reason to execute this node first, a reader can run against an empty or stale group. If a value goes missing intermittently, make sure this node is actually in the execution path ahead of the readers rather than dangling off to the side.
Values not updating between runs. Because it's a cache keyed by group name, confirm you're editing the same group you're reading. Two nodes writing different groups with the same intent is a classic self-inflicted miss.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| parameter_list | STRING | <params:my_string_variable:string> <params:my_number_variable: 0.5> | — |
| group | STRING | Default | — |
| parsing_key | STRING | params | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STRING | STRING | — |