AI File Sorter: Dateinamen per LLM, aber erst nach der Freigabe
Cross-platform desktop application for content-aware file organization and renaming. Supports local and remote LLMs, preview-based workflows, and fully user-controlled changes.
Auf einen Blick
- Was ist das?
- AI File Sorter ist eine C++-Desktop-Anwendung, die Dateien anhand ihres Inhalts kategorisiert und umbenennt. Lokale Bild- und Textmodelle, optionale Remote-APIs, ein Review-Schritt vor jeder Änderung und AGPL-3.0 als Lizenz. Die Dokumentation ist an mehreren Stellen dünn, das Sicherheitsmodell dagegen klar.
- Für wen ist es gedacht?
- Wer eine lokale, review-basierte Ablage für Bild-, Dokument- und Medienordner sucht und bereit ist, sich mit Modell-Backends und Vulkan, CUDA oder Metal auseinanderzusetzen, findet hier ein Werkzeug mit nachvollziehbarem Sicherheitsmodell. Wer vollautomatische, unbeaufsichtigte Massenverarbeitung ohne Freigabeschritt braucht, ist hier falsch.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich C++, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem liegt zwischen Downloads und NAS
Der Auslöser ist ein konkreter Alltagszustand: ein Ordner mit Dateien, deren Namen nichts über den Inhalt sagen. IMG_2048.jpg, ein Scan ohne Titel, ein Track mit kryptischem Dateinamen. Wer solche Ordner später durchsucht, sortiert oder archiviert, arbeitet gegen die Namen an. Genau dort setzt das Projekt an. Das README nennt als Zielordner ausdrücklich Downloads, externe Laufwerke und NAS-Speicher.
Der Ansatz ist nicht, feste Regeln zu schreiben. Das README formuliert den Unterschied selbst: statt sich nur auf feste Regeln zu verlassen, kombiniere die App KI-Vorschläge mit optionalen Whitelists, kürzlich ähnlichen Ergebnissen und den vom Nutzer freigegebenen Entscheidungen. Das ist der eigentliche Kern. Es geht nicht um einmaliges Umsortieren, sondern um eine Ablage, die aus bestätigten Entscheidungen lernt.
Angesprochen sind Einzelpersonen und kleine Teams, die ihre Dateien auf dem eigenen Rechner oder auf einem angeschlossenen Laufwerk behalten wollen. Das README macht die Zielgruppe über die Datenschutzaussage implizit klar: bei einem lokalen Modell bleiben Dateien, Dateinamen, Bilder und Metadaten auf dem Computer, Telemetrie wird nicht gesendet. Eine Internetverbindung braucht es nur, wenn ein Remote-Modell gewählt wird.
Vier Schritte, drei Analysepfade
Die im README dokumentierte Abfolge ist kurz: Ordner oder Laufwerk auswählen, Dateien und bei Bildern den Bildinhalt mit dem gewählten lokalen oder remote Modell analysieren lassen, Kategorie- und Umbenennungsvorschläge erzeugen, dann prüfen und anpassen, bevor etwas geändert wird. Erst nach der Bestätigung werden die nötigen Ordner automatisch erstellt und die Dateien einsortiert.
Unter der Haube sind es drei verschiedene Analysewege, die je nach Dateityp greifen. Für Bilder arbeitet ein visuelles LLM am Bildinhalt, das README nennt als Beispiel den Weg von IMG_2048.jpg zu clouds_over_lake.jpg. Für Dokumente wertet ein Text-LLM den Textinhalt aus und schlägt daraus einen klareren Namen vor. Für Audio und Video wird kein Modell auf den Inhalt angesetzt, sondern die bereits eingebetteten Metadaten gelesen: liegen Jahr, Interpret, Album oder Titel vor, entsteht daraus ein Vorschlag wie 2024_artist_album_title.mp3.
Diese Trennung ist wichtig für die Erwartungshaltung. Bei Medien ist der Vorgang im Kern eine Metadaten-Extraktion mit Formatierung, keine inhaltliche Interpretation. Wer eine Audiodatei ohne brauchbare Tags hat, bekommt aus diesem Pfad nichts Sinnvolles. Bei Bildern und Dokumenten hängt die Qualität des Vorschlags dagegen am gewählten Modell, und das README benennt die Backends nicht als austauschbare Details, sondern als Teil der Systemanforderung: Vulkan, CUDA und Apple Metal tauchen als eigene Plattform-Logos auf.
Installation und der erste sichere Lauf
Die Installation läuft über die üblichen Wege. Für Windows verweist das README auf den Microsoft Store, für Linux und macOS auf plattformspezifische Abschnitte der Dokumentation. Wer aus Quellen baut, findet im Repository die Abschnitte Installation und Testing, letzterer mit optionalen headless Live-LLM-Tests.
Bemerkenswerter als die Installationswege ist die Empfehlung zum ersten Lauf. Das README rät ausdrücklich, mit einem kleinen Testordner zu beginnen statt mit einem ganzen Archiv oder Laufwerk: 20 bis 50 Dateien aus Downloads, Screenshots, Fotos oder Dokumenten in einen temporären Ordner kopieren, die Analyse laufen lassen und die Review-Tabelle ansehen, bevor irgendetwas angewendet wird. Diese Empfehlung ist nicht Beiwerk, sie ist die eigentliche Betriebsanleitung für den Einstieg.
Für den Rückweg nennt die Dokumentation einen konkreten Menüpunkt: Edit -> Undo last run. Wer also versehentlich bestätigt, hat einen benannten Weg zurück. Ob dieser Undo über mehrere Läufe hinweg funktioniert oder nur den letzten Lauf abdeckt, sagt das Material nicht. Das ist eine der Stellen, an denen man vor dem ersten produktiven Einsatz selbst nachsehen muss.
Für die Modellwahl sind lokale Backends der Standardpfad, Remote-Nutzung ist optional. Das README beschreibt getrennte Abschnitte für einen OpenAI API key, einen Gemini API key und eine custom OpenAI-compatible API. Wer keinen lokalen Rechner mit passender GPU hat, kann also ausweichen, gibt dann aber die lokale Verarbeitung auf.
Whitelists, Cache und die Grenze des Lernens
Das Projekt wirbt mit Konsistenz über die Zeit. Der Mechanismus dahinter sind drei Dinge, die zusammenwirken: Kategorie-Whitelists, ein Kategorisierungs-Cache und die vom Nutzer freigegebenen Entscheidungen. Das README hat für alle drei eigene Abschnitte, darunter Categorization cache and learned behavior und Category whitelists.
Das ist der interessanteste Teil des Designs, und gleichzeitig der, über den das vorliegende Material am wenigsten aussagt. Es steht nicht da, wie der Cache aufgebaut ist, wie lange er gilt, ob er pro Ordner oder global wirkt und wie ein Modellwechsel ihn beeinflusst. Wer die App produktiv einsetzt, sollte das vorher klären, weil davon abhängt, ob ein einmal falsch gelernter Vorschlag dauerhaft wiederkehrt.
Ein zweiter Punkt betrifft die Whitelists. Sie sind als optional beschrieben, und genau darin liegt ihr Wert: sie setzen eine Obergrenze für das, was das Modell vorschlagen darf. Wer eine feste Kategorienstruktur braucht, etwa für eine Ablage mit definierten Ordnernamen, kann das Modell damit einengen. Ohne Whitelist entscheidet das Modell über die Kategorienamen, und die Konsistenz entsteht dann allein aus dem Cache und den bestätigten Entscheidungen.
Das README erwähnt außerdem eine Kategorie-Sprachauswahl. Wer Dateien in einer deutschsprachigen Struktur ablegt, kann die Kategorienamen also in der eigenen Sprache erzeugen lassen, statt englische Ordnernamen zu bekommen.
Wo das Werkzeug das Falsche ist
Die erste echte Einschränkung steht im README selbst, wenn auch indirekt: der Ablauf ist auf Freigabe ausgelegt. Jede Änderung passiert erst nach Bestätigung. Das ist gut für Sicherheit und schlecht für Skalierung. Wer zehntausende Dateien ohne Sichtung durchlaufen lassen will, arbeitet gegen das Design. Die Review-Tabelle ist der Flaschenhals.
Die zweite Einschränkung betrifft die Hardware. Lokale visuelle Backends brauchen eine passende GPU-Umgebung, und das README listet Vulkan, CUDA und Metal als eigene Kompatibilitätsdimensionen auf, inklusive eines eigenen Systemkompatibilitäts-Checks und eines Benchmark-Dialogs. Dass es einen Benchmark-Dialog gibt, ist ein Hinweis darauf, dass die Leistung je nach Maschine stark schwankt. Wer auf einer älteren Maschine ohne brauchbare GPU arbeitet, wird den Remote-Pfad brauchen, und damit fällt das Datenschutzargument.
Die dritte Einschränkung ist die Plattformform. Es ist eine Desktop-Anwendung in C++, kein Dienst, keine Bibliothek, keine CLI. Wer Dateiablage in eine bestehende Pipeline einbauen will, etwa als Schritt in einem Backup-Job, findet hier keinen Ansatzpunkt. Der Weg führt über die grafische Oberfläche.
Viertens: bei Audio und Video liefert die App nur dann etwas, wenn die Tags brauchbar sind. Das README beschreibt den Pfad ausdrücklich als Nutzung der bereits gespeicherten Metadaten. Fehlen sie, gibt es nichts zu extrahieren, und das Modell wird auf diesen Dateityp nicht angesetzt.
Alternative: rclone und feste Regeln
Der naheliegende Vergleich ist ein regelbasiertes Werkzeug wie rclone, das Dateien nach Namensmustern, Endungen und Zeitstempeln verschiebt. Der Unterschied liegt nicht in der Funktion, sondern in der Entscheidungsquelle. rclone entscheidet nach Kriterien, die der Nutzer vorab formuliert hat. AI File Sorter entscheidet nach einem Modellurteil über den Inhalt und lernt aus bestätigten Fällen nach.
Das ist ein echter trade-off, kein Qualitätsunterschied. Eine rclone-Regel ist reproduzierbar, testbar und in einer Pipeline ausführbar. Ein Modellvorschlag ist keine dieser drei Dinge. Dafür sieht eine Regel nicht, dass ein Bild Wolken über einem See zeigt, und sie kann einen namenlosen Scan nicht nach seinem Inhalt benennen. Wer Dateien nach Inhalt ablegen muss, kommt mit Mustern nicht weit. Wer Dateien nach bekannten Kriterien ablegen muss, braucht kein Modell, und ein Modell macht die Sache dort nur unzuverlässiger.
Ein zweiter Unterschied ist der Ort der Ausführung. rclone läuft headless auf einem Server oder NAS. AI File Sorter ist eine Desktop-Anwendung. Wer auf einem NAS aufräumen will, muss die Dateien also erst auf einen Rechner mit Oberfläche bringen oder den Remote-Modellpfad nutzen. Das README nennt NAS als Zielspeicher, beschreibt aber keinen Serverbetrieb.
Wartung, Versionen und AGPL-3.0
Die Release-Historie im Material ist dicht: v1.9.0 am 5. August 2026, v1.9.1 am 6. August, v1.9.2 am 14. August. Der letzte Push liegt auf dem 9. September 2026. Drei Releases innerhalb von neun Tagen deuten auf eine aktive Phase hin, in der nach einem größeren Sprung nachgezogen wird. Ob das ein Muster ist oder eine Ausnahme, lässt sich daraus nicht ableiten. Wer plant, die App langfristig einzusetzen, sollte sich die Changelog-Datei im Repository ansehen, die das README als eigenen Abschnitt führt.
Der Wartungsaufwand liegt weniger im Programm als in seiner Umgebung. Lokale Bildmodelle müssen beschafft und mit den Backends Vulkan, CUDA oder Metal zum Laufen gebracht werden. Das README hat dafür einen eigenen Abschnitt Required visual LLM files. Wer diesen Schritt einmal erledigt hat, hat Ruhe, bis ein Modellwechsel ansteht. Wer Remote-APIs nutzt, hängt dagegen an externen Anbietern und an deren Preisen und Schnittstellen.
Lizenzseitig steht das Projekt unter AGPL-3.0. Diese Lizenz verlangt, dass abgeleitete Werke, die über ein Netzwerk genutzt werden, ebenfalls unter AGPL gestellt und im Quelltext verfügbar gemacht werden. Für die private Nutzung auf dem eigenen Rechner ist das ohne praktische Bedeutung. Wer die App dagegen in einen Dienst einbetten und anderen über ein Netzwerk zugänglich machen will, sollte das vorher mit der eigenen Rechtsabteilung klären. Das ist keine Rechtsberatung, sondern nur der Hinweis auf die Stelle, an der die Lizenz relevant wird.
Für den Unterbau gilt: C++ mit Qt-nahen Abhängigkeiten je nach Plattform bedeutet, dass ein Selbstbau auf einem neuen System mehr Aufwand ist als das Herunterladen eines Installers. Das README führt für Windows den Microsoft Store und für Linux und macOS eigene Installationsabschnitte.
Redaktionelles Fazit
Wer eine lokale, review-basierte Ablage für Bild-, Dokument- und Medienordner sucht und bereit ist, sich mit Modell-Backends und Vulkan, CUDA oder Metal auseinanderzusetzen, findet hier ein Werkzeug mit nachvollziehbarem Sicherheitsmodell. Wer vollautomatische, unbeaufsichtigte Massenverarbeitung ohne Freigabeschritt braucht, ist hier falsch. Vor dem ersten Lauf lohnt es sich, die Dokumentation zu den Modell-Dateien zu prüfen und den Test mit 20 bis 50 kopierten Dateien zu fahren, den das README unter Safe First Run beschreibt.
Community-Notizen