OneFileLLM: turning scattered sources into one XML file for LLM context

The gap between a source and a prompt

Most LLM work starts with the same chore: get the material into the context window. A repository is a tree of files. A pull request is a diff plus a comment thread. An arXiv paper is a PDF. A conference talk is a transcript. Each has its own fetch path, and each produces text in a different shape. OneFileLLM addresses that chore specifically. It takes a list of inputs on the command line, resolves each one to text through a source-specific handler, and writes everything into one structured XML file that is also copied to the clipboard. The README frames it as a content aggregator for LLMs, and the output format is the point: XML gives the model explicit boundaries between sources, which a flat concatenation does not. The intended user is someone preparing a single large context, not someone building a service. There is no server, no index, no database. The tool runs, produces a file, and exits.

Input routing: how one argument list becomes many fetchers

The architecture visible in the README is a dispatcher over input types. A positional argument is inspected and routed: a local path goes through file handling, a github.com URL goes through the GitHub API, an arxiv.org URL or an arxiv: identifier goes to the arXiv handler, a doi: prefix goes to a DOI resolver, a PMID: prefix goes to PubMed, a youtube.com watch URL goes to youtube-transcript-api, and anything else that looks like a web address goes to the crawler. The topics list confirms the dependency set: arxiv, doi, github, ipynb, pdf, pmid, pull-request, tiktoken, youtube-transcript-api. The tiktoken dependency is notable because it implies token counting is part of the pipeline, which matters when the whole purpose is fitting a bundle into a context window. GitHub handling is the most developed path in the documentation. A repository URL is fetched through the API, and a URL containing tree/ is parsed so the request carries a ref parameter, which is how branch and tag selection works. Pull request URLs and issue URLs are separate handlers, and issue URLs accept a state query parameter with all, open or closed. The README states that all is the default. That detail is worth noting because it means an unqualified issues URL will pull closed issues too, which can be a large amount of text you did not ask for.

Installation paths and the commands that matter

There are three ways in, and they differ in what you get. Cloning gives you the script: git clone https://github.com/jimmc414/onefilellm.git, then cd onefilellm, then pip install -r requirements.txt, after which you run python onefilellm.py with your inputs. Installing from PyPI gives you the package without the repository: pip install onefilellm, which the README says exposes both the CLI and a Python API. Installing in editable mode from a clone, pip install -e ., installs the onefilellm command so you can write onefilellm ./docs/ https://github.com/user/project/issues/123 instead of invoking the script. The README notes that all other arguments and options behave the same either way. For GitHub access the README recommends exporting a token: export GITHUB_TOKEN="your_personal_access_token". It calls this recommended rather than required, and the README does not state what happens without it, so rate limiting behavior on unauthenticated requests is something to confirm yourself. The Python API is a single entry point: from onefilellm import run, then run(["./docs/"]). That is the whole documented surface, and it takes the same list of sources as the CLI.

Formats, streams and the alias system

The -f flag overrides format detection for text input and accepts text, markdown, json, html, yaml, doculing or markitdown. The presence of two unusual values, doculing and markitdown, suggests conversion backends rather than plain parsers, but the README does not explain what either does, so treat the flag as useful for the common four and unverified for the other two. Input can also arrive through a stream or the clipboard. The README gives three stream examples: cat large_dataset.json | python onefilellm.py - --format json, curl -s https://api.github.com/repos/microsoft/vscode | python onefilellm.py -, and echo 'Quick analysis task' | python onefilellm.py -. The dash is the stdin marker, and pairing it with an explicit format is the pattern shown. The -c or --clipboard flag processes text already on the clipboard, and the README pairs it with --format markdown. The alias system is the part with the most leverage for repeat work. --alias-add NAME COMMAND_STRING stores a named bundle, so a single token can expand to several sources: the README shows an alias named modern-web holding a React repo URL, a docs URL and a Next.js repo URL. Aliases support {} placeholders, so gh-search can hold https://github.com/search?q={} and gh-user can hold https://github.com/{}. The README shows aliases being stored and used but truncates before showing a completed placeholder invocation, so the exact substitution syntax at call time is not fully documented in the supplied material.

The crawler has its own configuration surface

When an input is a general web page, the crawler options apply, and there are many of them: --crawl-max-depth, --crawl-max-pages, --crawl-user-agent, --crawl-delay, --crawl-include-pattern, --crawl-exclude-pattern, --crawl-timeout, --crawl-concurrency, --crawl-restrict-path, --crawl-follow-links, --crawl-respect-robots, and a set of toggles for images, code blocks, heading extraction, HTML cleaning, JavaScript stripping, CSS stripping, comment stripping, PDFs and EPUBS. Two of these deserve attention. --crawl-respect-robots implies robots.txt compliance is a switch rather than a fixed behavior, which is a design choice with ethical and practical consequences: a user can turn it off. --crawl-concurrency and --crawl-delay interact, and neither has a documented default in the supplied material. Running a crawler against documentation sites without knowing those defaults is the kind of thing that produces a block or a complaint. The README's own examples target python.org, react.dev, docs.stripe.com and kubernetes.io, all large sites with real infrastructure behind them. The existence of --crawl-include-images alongside --crawl-no-include-code indicates the crawler can emit non-text content into the bundle, which will consume tokens without necessarily helping the model. --help-topic with values basic, aliases, crawling, pipelines, examples or config is the documented way to get detail the main help text omits.

Where it stops being the right tool

The clearest limitation is that OneFileLLM produces a snapshot. Every run re-fetches. There is no cache described in the README, no incremental update, and no index. For a repository you consult once before a long prompt, that is fine. For a codebase you query daily, you are paying the full fetch cost every time, and you are re-copying the same content to the clipboard. The second limitation is source coverage by handler. Each input type has a dedicated fetcher, and the quality of the bundle depends entirely on that fetcher. A GitHub repository comes through the API with a token. A Sci-Hub paper, which the repository description mentions, has no documented command in the README examples, and the legal position of that path is not addressed anywhere in the supplied material. The third limitation is scale. The tool is built to assemble one large context, and the tiktoken dependency suggests token awareness, but nothing in the README describes chunking or splitting. If the aggregate exceeds the model's window, the README does not say what happens. The fourth is that XML output is a fixed choice. There is a format flag for input parsing, not for output shape, so a pipeline expecting JSON has to post-process. Anyone who needs retrieval over a changing corpus, or who wants embeddings and a vector store, is looking at a different category of tool.

The alternative: gitingest and repo2txt

The closest comparison is a repository-to-text tool such as gitingest or repo2txt. The difference in approach is scope versus depth. Those tools take a single repository and produce a digest of it, often with file-size filtering and a tree summary, and they are good at exactly that one job. OneFileLLM takes a heterogeneous list: a repo, a pull request, an issue list, a paper identifier, a YouTube URL and a documentation site can all appear in the same invocation, and the output is one XML document with source boundaries. If your problem is understanding one codebase, a repo-only tool is simpler and has fewer moving parts. If your problem is assembling a context that spans a codebase, the discussion around it, and the paper it implements, OneFileLLM is doing work the single-repo tools do not attempt. The trade-off is that each additional source type is another fetcher that can break independently, and the README's examples are the only evidence of what each handler returns.

Maintenance cost, licence and what to check first

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the standard permissive arrangement, and it means you can vendor the tool into an internal workflow without a licensing conversation. It is not legal advice; check the LICENSE file in the repository for the exact text. Maintenance cost is dominated by the fetchers, not the core. Every external source is a moving target: GitHub API behavior, arXiv and DOI resolution, YouTube transcript availability, and the HTML structure of any documentation site you crawl. A tool with this many source handlers accumulates breakage at the rate of its sources. The repository shows no retrieved releases in the supplied material, so there is no versioned release cadence to rely on, and updates arrive through the main branch. Practical verification before you depend on it: run the CLI against one input of each type you plan to use, confirm the XML structure is what your downstream prompt expects, and check whether the GITHUB_TOKEN path changes what you get back. For crawling, read the --help-topic crawling output to learn the actual defaults for concurrency, delay and robots handling, because the README does not state them and those defaults determine whether a documentation crawl is polite or not.

Editorial conclusion

OneFileLLM fits engineers who need a one-shot context bundle from a known set of sources: a repo plus a pull request plus a paper, assembled before a long prompt. It does not fit anyone who needs incremental updates, a persistent index, or retrieval over a corpus that changes daily, because the output is a snapshot written to a file and the clipboard. Before adopting it, verify two things in your own environment: that the GitHub token path works for the repositories you care about, and that the crawl defaults (concurrency, delay, robots handling) match what the sites you scrape will tolerate.

Official sources

1. Issues
2. jimmc414/onefilellm on GitHub
3. License: MIT
4. README