Int To String

ComfyUI is strict about types - an INT output won't connect to a STRING input, full stop, no matter how obviously a seed number or a counter would fit into a filename or a prompt as text. That strictness is deliberate (it's what keeps a graph from silently passing garbage between incompatible nodes), but it means you hit these mismatches constantly once a workflow gets past a handful of nodes. Int To String is the smallest possible fix for that: one integer in, the same number as text out.

The whole node. integer_value is your INT input - a seed, a counter, whatever numeric value you need represented as text. string_value is the output, the same number cast to STRING.

Installing it. Search "comfyui_gr85" in ComfyUI Manager, or from a terminal:

cd ComfyUI/custom_nodes
git clone https://github.com/veighnsche/comfyui_gr85

Restart ComfyUI. No models, no dependencies - this is as lightweight as a custom node gets.

Where this actually earns a spot in your graph. Feeding a seed value into GR85_SaveTextFile's filename fields, embedding a counter or index into a prompt string for logging purposes, or wiring a numeric value into any node in this pack - GR85_ShowText, GR85_ContainsWord - that only accepts STRING. It's not a node with any depth to it, but it's the kind of connector piece that shows up constantly once you start building graphs with more than a couple of nodes, and having a dedicated one saves you from reaching for a heavier general-purpose type-conversion pack just to cast one integer.

One thing worth knowing. If the number you're converting needs specific formatting - leading zeros for a consistent filename counter, for instance - this node doesn't expose a padding or format option, it's a plain cast. For that kind of formatted output you'd want a node built for it specifically (GR85's own GR85_SaveTextFile and GR85_SaveImageFile handle their own zero-padding internally via filename_number_padding, for example) rather than expecting Int To String to format the number for you first.

Don't overthink where to put it in a graph, either - it has no side effects and no state, so it's safe to drop in wherever a type mismatch shows up as a red, unconnectable wire. If you find yourself reaching for it more than a couple of times in the same workflow - once for a seed into a filename, again for a counter into a caption - that's usually a sign you're building something that would benefit from a GR85_ShowText node nearby too, so you can actually see the string values as they flow rather than trusting the cast blind.