DocumentChunkRecursionFilterNode

Every chat model has a context window, and your research paper or log file doesn't care. DocumentChunkRecursionFilterNode is the pack's workaround: a recursion filter that slices a long document into chunks and processes them one per agent iteration, so you can hand a 50,000-character document to a model whose window is a fraction of that. It doesn't summarize in one pass - it walks the document, one manageable bite at a time.

This pairs with AgentNode the same way BasicRecursionFilterNode does: you build the filter here, then connect it to the agent's recursion_filter input. The agent drives the loop; this filter decides what chunk goes into each round.

How it works

When you run the node, it takes your document text and cuts it into chunk_size-character pieces (document[i:i+size]). The output filter is stateful: every time the agent calls it, it hands out the next chunk, formats it into your recursion_prompt template, and calls the completion function (LLLM_provider) to process it. On the final chunk it returns "Document processing complete."

The node prints progress to the console as it goes - Processing chunk 3/12 - and it also prints how many chunks it expects, which is your hint for tuning the agent.

Template placeholders:

• {chunk} - the current slice
• {prompt} - the original user prompt
• {completion} - the previous chunk's completion
• {date} - today's date

The inputs

• LLLM_provider (required) - a CALLABLE (prompt in, completion out), normally from LiteLLMCompletionProvider.
• document (required) - the full text. Could be wired from a text node or file loader.
• chunk_size (default 512) - characters per chunk. Smaller chunks = more calls, less memory pressure.
• recursion_prompt (optional) - the per-chunk processing template. The default just repeats the chunk and asks for processing; you'll want to replace it with something domain-specific (analyze, extract facts, flag issues…).
• inner_recursion_filter (optional) - a filter applied before each chunk's processing, for chaining pipelines.

Output: Recursion Filter (LLLM_AGENT_RECURSION_FILTER) → AgentNode.

Installing

Same pack, same story - ComfyUI Manager, search "ComfyUI_LiteLLM", or:

cd ComfyUI/custom_nodes
git clone https://github.com/Hopping-Mad-Games/ComfyUI_LiteLLM
cd ComfyUI_LiteLLM
pip install -r requirements.txt

Restart, set a provider key. It registers under ETK/LLM/LiteLLM as "Document Chunk Processor."

Where people get burned

The classic mistake is mismatching max_iterations with the number of chunks. If the agent's max_iterations is smaller than the chunk count, the document never finishes - the filter runs dry and prints "No more chunks to process." If it's much larger, you burn calls on empty rounds. The node prints the expected chunk count to the console; set the agent's max_iterations to match it (the pack's own guide says the same). Second, a 512-character chunk is roughly 100–150 tokens - comfortable, but you get lots of calls for a long document, and each is a billable API hit. Chunk size is a cost lever, not just a memory lever. And the default recursion prompt is a placeholder, not a plan - it literally just echoes the chunk back. For real work, write a template that tells the model what to do with each chunk, or you'll pay for a very thorough pass-through.