GitHub Repo Eater

Ever wanted to ask a local LLM what a node pack's code actually does, only to realize you'd have to copy-paste a hundred files into the prompt box? That's the gap this thing fills. GitHub Repo Eater takes a repository URL, downloads the repo, flattens it into one big text blob, and hands it to your graph as a plain string - so you can wire it into a local LLM or API node and start asking questions about code you didn't write and don't want to read.

It's a tiny utility from a tiny pack (gabe-init/ComfyUI-Repo-Eater, basically one file and a README that says "compatible with gitingest"), and it's honest about being exactly that. No model files, no API key, no GPU load. The only heavy lifting happens on someone else's turf - gitingest, the same library behind gitingest.com's "turn any repo into a single text dump for LLMs" tool.

How it works

The node does four things, and the code is short enough to read in a minute:

1. Calls ingest(repo_url) from gitingest, which clones the public repo, skips binary and junk files, and returns a tuple: a summary, a file tree, and the concatenated content.
2. Saves that content to ComfyUI/output/repo_eater/<timestamp>_<reponame>.txt so you keep a copy even after the graph forgets it.
3. Counts tokens with tiktoken's gpt-3.5-turbo encoder.
4. Returns the content and the token count.

The IS_CHANGED method returns the URL, which means it re-runs when you change the repo - not on every queue, so ComfyUI's cache stays your friend. That's better behavior than half the plumbing nodes out there.

The inputs and outputs that matter

There's exactly one input: repo_url, a plain string field with a placeholder default. Paste the GitHub URL and you're done - nothing else to configure, which is either refreshing or suspicious depending on how many nodes you've installed this week.

The two outputs are what you'd expect:

• repo_content (STRING) - the whole repository as text. Wire this into a text-display node to eyeball it, or straight into an LLM node that takes a string prompt.
• token_count (STRING) - the formatted count (e.g. 12,345). This is the one you'll actually watch, because it's your context-window budget in one number.

Where people get burned

The token count is the trap, in two directions. First, it's measured with tiktoken's GPT-3.5-turbo vocabulary - a proxy for cost and context, not an exact count for whatever local model you're actually feeding. A Llama or Qwen tokenizer will land somewhere in the neighborhood but won't match. Treat it as "roughly this many tokens," not gospel.

Second: a mid-size repo is a lot of tokens. An LLM node with a 8k context window will choke on anything but a toy project. This node has no filter, no "just give me the README" mode, no size slider - you get the whole thing or the error string. For big repos, you'll want the repo_content string going into something that can chunk or summarize, not a raw chat model.

Real failure modes, from reading the code: no network or a private repo means gitingest fails, and you get the error message back as repo_content with token_count set to 0 - which reads like success if you only glance at the count. And since this is arbitrary Python that phones home to GitHub at runtime, the usual rule applies: it's open source and short, so read the file once before you trust it. That's a five-minute audit, not a burden.

Installing it

ComfyUI Manager, search "ComfyUI-Repo-Eater", install, restart. Or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/gabe-init/ComfyUI-Repo-Eater
# restart ComfyUI

Dependencies are just gitingest and tiktoken - pip installs them automatically. No models to download, no VRAM, no config. About the only thing it needs from you is an internet connection the first time you run it.

It's niche, and it's not the node you'll build your workflow around. But when you need to make an LLM read a repository, it turns a two-hour copy-paste session into one URL.