Text Iterator

Most LLM API calls have a context limit, and even models with huge context windows tend to get worse at paying attention to everything in a very long input. Text Iterator solves the "I have a whole document and need to process it in pieces" problem by splitting the input into chunks and stepping through them one at a time across repeated graph executions - you queue the workflow once per chunk, and this node advances to the next piece each time, rather than you manually copy-pasting sections into a prompt box.

file_content is the full text you're iterating over - the whole document goes in here, not one chunk at a time; the node itself does the splitting. chunk_size (default 1024) and chunk_overlap (default 0, both optional) control how that splitting happens, the same tradeoff you'd see in any text-chunking tool: smaller chunks mean more, more-focused calls to your LLM but more total API round-trips; overlap helps avoid slicing a sentence or idea right at a chunk boundary if that matters for your use case. iterator_mode picks how the node advances through chunks: sequential walks forward one chunk per run, random picks a random chunk each time (useful if you want variety rather than completeness - sampling a document instead of processing all of it), Infinite loops back to the start once it runs out rather than stopping, and sequential_flagout is the sequential mode paired more explicitly with the is_end output for driving a loop that needs to know when it's actually finished. is_reload resets the iterator back to the start - flip it if you've changed file_content and want the node to re-chunk and restart from the beginning instead of continuing wherever it left off. is_enable is the standard toggle.

Two outputs: file_content - despite sharing a name with the input, this is the current chunk, not the whole document - and is_end, a boolean telling the rest of your graph whether you've reached the last chunk. That second output is what makes automation possible: wire it into whatever's controlling your queue (or into a String Logic / conditional node) so your workflow knows to stop looping once the whole document has been processed, rather than you watching the run count and guessing when it's done.

Installing it means installing the pack: search "comfyui_LLM_party" in ComfyUI Manager, or git clone https://github.com/heshengtao/comfyui_LLM_party into custom_nodes and restart, then run pip install -r requirements.txt from inside the pack folder using ComfyUI's own Python (portable installs: python_embeded\python.exe -m pip install -r requirements.txt).

The thing that trips people up is state. This node has to remember which chunk you're on across separate runs, which means its behavior depends on execution history, not just the current inputs - if a workflow feels like it's "stuck" repeating the same chunk, or skipping ahead unexpectedly, check whether is_reload got toggled on by accident, or whether you changed file_content between runs without meaning to (a changed input generally forces a re-chunk, which resets your position). If you're relying on this for a real batch-processing job, is_end is genuinely the piece to build your stopping logic around - don't just run the graph a fixed number of times and hope it lines up with your chunk count.