OneFileLLM: viele Quellen, ein XML-Block für den Kontext

Welches Problem der Sammelaufruf löst

Ein Sprachmodell bekommt seinen Kontext als Text. Wer ein Repository, eine API-Dokumentation und ein Paper gleichzeitig hineinreichen will, kopiert sonst aus drei Werkzeugen in drei Formaten zusammen. OneFileLLM setzt genau dort an: Die README beschreibt das Projekt als Kommandozeilenwerkzeug, das Daten aus verschiedenen Quellen zusammenführt und in eine strukturierte XML-Ausgabe schreibt, die automatisch in der Zwischenablage landet. Die Zielgruppe sind Entwickler, die diese Zusammenstellung von Hand betreiben, nicht Teams, die einen Dienst betreiben wollen. Der Aufruf ist ein Prozess, der einmal läuft und dessen Ergebnis man in ein Chatfenster oder eine Datei einfügt.

Der Ablauf vom Argument zur XML-Datei

Die Architektur ist ein Einzelprozess mit einer Liste von Eingaben. Jede Eingabe wird zuerst als Typ erkannt: lokaler Pfad, GitHub-URL, Webseite, YouTube-Link, arXiv- oder Sci-Hub-Verweis, DOI, PMID oder Alias. Für GitHub-Repositories parst das Werkzeug den tree/-Teil einer URL und schickt die Anfrage mit einem ref-Parameter, damit ein bestimmter Branch oder Tag geladen wird. Das ist der konkreteste Mechanismus, den die README offenlegt, und er erklärt, warum die Beispiele eine URL wie https://github.com/openai/whisper/tree/main/whisper verwenden. Für Textquellen entscheidet entweder die Dateiendung oder der Schalter -f, welche Verarbeitung greift. Am Ende steht ein XML-Dokument, das die Quellen in einer Reihenfolge hält, plus der Kopiervorgang. Wie die XML-Struktur im Einzelnen aussieht, geht aus dem bereitgestellten Material nicht hervor; dazu müsste man die Ausgabe eines echten Laufs ansehen.

Installation und die zwei Betriebsarten

Es gibt zwei Wege hinein. Der klassische ist ein Klon mit pip install -r requirements.txt, danach läuft der Aufruf als python onefilellm.py. Alternativ lässt sich das Paket direkt installieren, und die README nennt pip install onefilellm als Weg zu CLI und Python-API ohne Klon. Für die Nutzung als Kommandozeilenbefehl im Projektverzeichnis steht pip install -e . bereit, was den Befehl onefilellm statt python onefilellm.py ermöglicht. Aus Python heraus ruft man run(["./docs/"]) aus dem Modul onefilellm auf. Für GitHub-Zugriffe empfiehlt die README ein Personal Access Token in der Umgebungsvariable GITHUB_TOKEN. Wer das Token nicht setzt, arbeitet gegen die anonymen Ratenlimits der API; die README nennt das Token ausdrücklich als empfohlen, ohne die konkreten Limits zu beziffern.

Crawl-Optionen als eigentlicher Konfigurationsort

Der umfangreichste Teil der Hilfe sind die Crawl-Schalter. --crawl-max-depth und --crawl-max-pages begrenzen die Breite eines Website-Durchlaufs, --crawl-delay und --crawl-concurrency steuern das Tempo, --crawl-include-pattern und --crawl-exclude-pattern filtern Pfade. Dazu kommen Schalter, die Inhalte vor dem Ablegen bereinigen: --crawl-no-strip-js, --crawl-no-strip-css, --crawl-no-strip-comments und --crawl-no-clean-html schalten einzelne Bereinigungsschritte ab, --crawl-no-extract-headings und --crawl-no-include-code entfernen Überschriften beziehungsweise Codeblöcke, --crawl-include-images nimmt Bilder mit. --crawl-respect-robots und --crawl-restrict-path sind die beiden Optionen, die den Durchlauf auf den Ausgangspfad und auf die robots-Regeln begrenzen. Bemerkenswert ist die Richtung der Schalter: Die Bereinigung ist offenbar voreingestellt aktiv, und die no-Varianten heben sie auf. Wer den rohen HTML-Baum braucht, muss also aktiv widersprechen. Die Standardwerte für Tiefe, Seitenzahl und Verzögerung nennt die Hilfe nicht, sie stehen nur als Platzhalter für eigene Werte da.

Aliase, Platzhalter und Eingaben aus der Pipe

Wiederkehrende Kombinationen lassen sich als Alias ablegen: --alias-add mcp "https://github.com/anthropics/mcp" speichert eine einzelne Quelle, ein Alias darf aber auch mehrere URLs enthalten. Mit geschweiften Klammern entstehen Vorlagen, die beim Aufruf gefüllt werden, etwa gh-search mit https://github.com/search?q={}. --alias-list und --alias-list-core zeigen die vorhandenen Einträge, --alias-remove löscht sie. Neben Argumenten nimmt das Werkzeug auch Standardeingabe: cat large_dataset.json | python onefilellm.py - --format json, ebenso curl-Ausgaben. Mit -c oder --clipboard liest es umgekehrt den aktuellen Inhalt der Zwischenablage. Der Schalter -f kennt text, markdown, json, html, yaml, doculing und markitdown und überschreibt die Formaterkennung, was nötig wird, wenn eine JSON-Datei ohne Endung durch die Pipe kommt.

Wo das Werkzeug an seine Grenzen stößt

Die Ausgabe ist ein einzelnes XML-Dokument. Das ist bequem für den einen Kontextblock, aber schlecht, wenn man einzelne Quellen später ersetzen, neu abrufen oder versionieren will; jede Änderung erzeugt einen neuen Gesamtlauf. Dazu kommt die Abhängigkeit von fremden Diensten. arXiv, GitHub, YouTube und beliebige Webseiten ändern ihre Antworten, drosseln Anfragen oder verlangen Anmeldung. Die README zeigt für fehlgeschlagene Quellen keinen Umgang: kein Schalter für Wiederholungen, kein Teilausgabe-Modus, keine Liste der ausgelassenen Quellen. Wer wissen will, ob eine Quelle tatsächlich im XML gelandet ist, muss das Ergebnis selbst durchsehen. Ein weiterer Punkt ist der Umfang: Ein großes Repository oder ein tiefer Crawl kann den Kontext eines Modells weit überschreiten. Die Topics nennen tiktoken, was auf eine Token-Zählung hindeutet, doch die bereitgestellte Hilfe enthält keinen entsprechenden Schalter. Ob und wie das Werkzeug kürzt, lässt sich aus dem Material nicht belegen.

Was andere Werkzeuge anders machen

Der naheliegende Vergleich ist ein Dokumentenlader-Framework wie LlamaIndex oder LangChain mit seinen Readern. Diese zerlegen Quellen in Chunks, hängen Metadaten an und schreiben sie in einen Index oder Vektorspeicher, aus dem zur Abfragezeit nur die passenden Teile geholt werden. OneFileLLM macht das Gegenteil: alles auf einmal, in einer Datei, ohne Index und ohne Abfrageschicht. Der Vorteil liegt auf der Hand, wenn der Kontext klein genug ist und man ihn vollständig sehen will. Der Nachteil ist derselbe Punkt von der anderen Seite: Es gibt keine Auswahl zur Laufzeit, und die Zwischenablage als Hauptausgabekanal ist an eine interaktive Sitzung gebunden. Für einen nächtlichen Job, der einen Index pflegt, ist das falsche Werkzeug gewählt.

Pflegeaufwand und Lizenz

Das Projekt steht unter der MIT-Lizenz. Das ist die permissivste der gängigen Varianten: Nutzung, Änderung und Weitergabe sind erlaubt, solange Copyright-Hinweis und Lizenztext beiliegen. Wer den Code in ein eigenes Produkt einbettet, muss diesen Hinweis also mitführen. Eine rechtliche Einschätzung ist das nicht, nur die Beschreibung dessen, was die Lizenzkennung üblicherweise bedeutet. Zum Pflegeaufwand lässt sich aus dem Material wenig Sagen: Es gibt keine abgerufenen Releases, der letzte Push liegt laut Metadaten im Juni 2026, das Repository ist nicht archiviert. Die Abhängigkeiten sind der eigentliche Kostenfaktor, denn sie zeigen nach außen auf fremde Dienste. Ändert YouTube sein Transkriptformat oder GitHub seine API, muss das Werkzeug nachziehen. Wer es produktiv einsetzt, prüft vor einem Upgrade am besten einen gemischten Aufruf mit allen genutzten Quellentypen, statt sich auf die Versionsnummer zu verlassen.

Redaktionelles Fazit

Sinnvoll ist OneFileLLM für Entwickler, die Kontext für ein LLM von Hand zusammenstellen und dabei viele heterogene Quellen in einem Aufruf mischen wollen, etwa ein Repository, eine Doku-Seite und ein arXiv-Paper. Wer eine Pipeline mit reproduzierbaren Fehlern, Retry-Logik oder versionierten Zwischenständen braucht, sollte vorher prüfen, ob die XML-Ausgabe und der Abbruch bei fehlgeschlagenen Quellen ausreichen. Vor dem Einsatz lohnt ein Testlauf mit einer kleinen, gemischten Eingabe und dem Format json, um zu sehen, wie das Werkzeug mit einer Quelle umgeht, die es nicht abrufen kann.

Offizielle Quellen

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