ReadAny: KI-Lesegerät mit lokalem Vektorspeicher, RAG-Chat und WebDAV-Sync

Welches Problem ReadAny adressiert

Das README stellt drei Fragen an den Anfang: Warum vergesse ich, was ich gelesen habe? Warum liegen meine Notizen verstreut? Warum kann ich nur nach Stichwörtern suchen? Diese drei Punkte beschreiben das Zielprofil genauer als jede Funktionsliste. Angesprochen sind Lesende mit großen, über Jahre gewachsenen Bibliotheken, die ihre Markierungen und Notizen bisher in getrennten Werkzeugen verwalten und beim Wiederfinden auf ihr Gedächtnis für exakte Begriffe angewiesen sind.

Der Lösungsansatz ist eine lokale Wissensbasis: Bücher, Markierungen und Notizen bleiben auf dem Gerät, die Einbettungen werden laut README lokal erzeugt und in einem lokalen Vektorspeicher abgelegt. Damit grenzt sich das Projekt ausdrücklich von Readern ab, die Inhalte zur Auswertung in eine Cloud hochladen. Wer hauptsächlich Belletristik liest und nie Notizen macht, gewinnt hier wenig. Der Nutzen entsteht erst, wenn ein Bestand an Sachtexten, Fachliteratur oder Recherchematerial zusammenkommt, den man später abfragen will.

Hybride Suche: Vektorabruf plus BM25

Das README beschreibt die Suche als Kombination aus Vektorabruf und BM25. Das ist der technisch interessanteste Teil, weil beide Verfahren unterschiedliche Schwächen haben. Ein reiner Vektorabruf findet Passagen, die inhaltlich passen, auch wenn kein einziges Wort der Anfrage im Text vorkommt. Er ist aber schlecht darin, seltene Eigennamen, Produktbezeichnungen oder exakte Zitate zu treffen, weil solche Token im Einbettungsraum kaum Gewicht haben. BM25 verhält sich umgekehrt: Es trifft exakte Terme zuverlässig, scheitert aber bei Umschreibungen.

Die Kombination ist damit kein Marketing-Zusatz, sondern eine Fehlerkorrektur. Wer in einem Fachbuch nach einem konkreten Modellnamen sucht, verlässt sich auf den BM25-Anteil; wer sich nur an die Idee erinnert, auf den Vektoranteil. Wie die beiden Ergebnislisten gewichtet oder fusioniert werden, geht aus dem vorliegenden Material nicht hervor. Das ist eine offene Stelle: Ohne Kenntnis der Gewichtung lässt sich nicht beurteilen, ob die hybride Suche in der Praxis besser abschneidet als ein reiner Vektorabruf. Das README gibt dazu keine Zahlen, und ich habe keine Messung vorgenommen.

Der Chat als RAG-Schicht über dem Lesekontext

Der Chat ist laut README an den Lesekontext gebunden: Das System kennt die aktuelle Leseposition, markierten Text und vorhandene Markierungen. Das ist eine bewusste Einschränkung gegenüber einem allgemeinen Chatfenster. Die Antworten sollen sich auf das beziehen, was gerade gelesen wird, und Quellen im Text lokalisieren. In der Praxis heißt das: Der Abruf erfolgt nicht über die gesamte Bibliothek, sondern über einen eingegrenzten Ausschnitt, was die Trefferqualität erhöht und die Kontextlänge klein hält.

Zusätzlich nennt das README ein Skills-System mit eingebauten Fähigkeiten (Summarizer, Concept Explainer, Character Tracker) und der Möglichkeit, eigene Skills anzulegen. Das ist ein Erweiterungspunkt, kein fertiges Produkt: Wer eigene Skills schreiben will, muss sich mit dem Format auseinandersetzen, und dazu liefert das README in der vorliegenden Fassung keine Spezifikation. Die Übersetzung ist separat gelöst und läuft entweder über ein KI-Modell oder über DeepL, mit 19 unterstützten Sprachen.

Installation und Ersteinrichtung

Der Bezug läuft über fertige Pakete: .dmg für macOS (Apple Silicon und Intel getrennt), .msi für Windows, .AppImage für Linux, eine .apk für Android und ein TestFlight-Zugang für iOS. Unter macOS gibt es zusätzlich den Homebrew-Weg:

brew tap codedogQBY/readany brew install --cask readany

Nach dem Start nennt das README drei Schritte: Bücher per Drag and Drop importieren, per Doppelklick öffnen, und optional die KI konfigurieren. Der KI-Schritt ist der einzige mit echtem Konfigurationsaufwand. Zur Auswahl stehen OpenAI, Claude, Gemini, Ollama, DeepSeek und eigene, kompatible Anbieter. Für den lokalen Betrieb ist Ollama der naheliegende Endpunkt, weil dann weder Abruf noch Einbettung das Gerät verlassen.

Die Einrichtung der Synchronisierung erfolgt über WebDAV, mit automatischer Hintergrundsynchronisierung und einer Konfliktauflösung, die das README als intelligenten Merge bei gleichzeitigen Änderungen beschreibt. Welche Konflikte dabei wie behandelt werden, etwa ob Markierungen und Notizen getrennt zusammengeführt werden, lässt sich aus dem Material nicht ableiten. Wer auf mehreren Geräten parallel arbeitet, sollte das vor dem Produktiveinsatz mit zwei Testgeräten prüfen.

Formate, Import und die TXT-Eigenheit

Unterstützt werden EPUB, PDF, MOBI, AZW, AZW3, FB2, FBZ, CBZ, TXT und UMD. Wichtiger als die Liste ist ein Detail im README: TXT und UMD werden beim Import nach EPUB konvertiert, damit Lesen, Notizen, Suche und Synchronisierung darauf funktionieren. Das ist eine pragmatische Entscheidung, die das Datenmodell vereinheitlicht. Sie hat aber eine Folge, die man kennen sollte: Der Import ist kein reiner Kopiervorgang, sondern ein Verarbeitungsschritt. Bei großen Textdateien entsteht dabei ein zusätzliches EPUB im Bibliotheksverzeichnis, und die Konvertierung kann bei ungewöhnlich formatierten Quellen danebengehen. Das README sagt nichts über Fehlerbehandlung an dieser Stelle.

Für Comics und Bildbände ist CBZ vorgesehen. PDF ist gelistet, aber aus dem Material geht nicht hervor, ob Textextraktion, Markierungen und semantische Suche bei PDF dieselbe Qualität erreichen wie bei EPUB. Genau das ist bei PDF die übliche Bruchstelle, weil Layout, Spalten und Scans die Extraktion erschweren. Wer seine Bibliothek überwiegend als PDF hält, sollte das mit einem einzelnen Band testen, bevor er den gesamten Bestand einliest.

Wo ReadAny das falsche Werkzeug ist

Die erste Grenze ist die Lizenz. Die Metadaten melden NOASSERTION, das README verlinkt eine LICENSE-Datei, ohne deren Inhalt wiederzugeben. Für private Nutzung ist das selten ein Problem. Wer ReadAny in ein Produkt einbetten, forken und weiterverbreiten will, hat hier keine belastbare Grundlage und muss die Datei selbst lesen. Ich gebe dazu keine rechtliche Einschätzung ab, aber der Unterschied zwischen einer permissiven und einer Copyleft-Lizenz ist für diesen Anwendungsfall erheblich.

Die zweite Grenze ist der KI-Teil selbst. Das Projekt liefert die Infrastruktur, nicht das Modell. Ohne konfigurierten Anbieter bleibt von der semantischen Suche und dem Chat nichts übrig. Wer keinen API-Schlüssel verwalten und keine lokale Ollama-Instanz betreiben will, für den ist ReadAny ein gewöhnlicher Reader mit ungenutztem Zusatzgewicht. Dazu kommt die Hardware-Seite: Lokale Einbettungen über einen längeren Zeitraum sind rechenintensiv, und das README quantifiziert weder den Zeitaufwand noch den Speicherbedarf des Vektorspeichers. Wer eine Bibliothek mit tausenden Bänden einlesen will, sollte mit einer kleinen Teilmenge beginnen und den Ressourcenverbrauch beobachten.

Die dritte Grenze betrifft die Wartung. Zwischen v1.3.4 und v1.3.6 liegen jeweils etwa ein bis zwei Monate, mit v1.3.6 vom August 2026 als jüngster Version. Die Abstände sind regelmäßig, aber die Release Notes liegen im Material nicht vor. Ob ein Update das Vektorspeicher-Schema ändert und eine Neuindizierung erzwingt, lässt sich daraus nicht ablesen. Genau das ist bei einem lokalen Speicher der teure Fall, weil eine Neuberechnung aller Einbettungen Stunden dauern kann.

Der Vergleich mit Calibre und KOReader

Das README stellt ReadAny neben Calibre, KOReader und Apple Books. Der Unterschied liegt nicht im Funktionsumfang, sondern im Ansatz. Calibre ist in erster Linie eine Verwaltungs- und Konvertierungssoftware: Metadaten pflegen, Formate umwandeln, Bibliotheken sortieren. Der Lesefluss ist dort ein Anhängsel. KOReader ist das Gegenteil, ein schlanker Reader für E-Ink-Geräte, der auf Ressourcenschonung und Anpassbarkeit ausgelegt ist und laut Vergleichstabelle nur eingeschränktes TTS bietet.

ReadAny setzt den Schwerpunkt auf die Auswertung des Gelesenen. Chat, semantische Suche, Skills und Statistik sind Funktionen, die bei Calibre und KOReader in der Tabelle fehlen. Der Preis dafür ist eine schwerere Anwendung: Electron oder Tauri auf dem Desktop, React Native auf Mobilgeräten, dazu ein Vektorspeicher und ein Modell-Endpunkt. Wer einfach nur lesen will, auf einem alten E-Ink-Gerät, mit langer Akkulaufzeit, ist bei KOReader besser aufgehoben. Wer seine Notizen aus zehn Jahren in einem durchsuchbaren Bestand zusammenführen will, hat bei Calibre nichts, was dem entspricht.

Ein Punkt aus der Tabelle ist irreführend: Calibre wird bei der Formatunterstützung mit über 15 Formaten geführt, ReadAny mit über 10. Das ist keine Schwäche, sondern eine Folge der Ausrichtung. Entscheidend ist, ob die eigenen Formate dabei sind, nicht die Zahl.

Betrieb, Updates und was vorher zu klären ist

Der Betrieb ist auf lokale Daten ausgelegt. Bücher, Markierungen, Notizen und der Vektorspeicher liegen auf dem Gerät; WebDAV ist optional und überträgt die Bibliothek zwischen Geräten. Wer WebDAV nutzt, sollte sich im Klaren sein, dass die Synchronisierung dann über einen eigenen Server läuft, nicht über einen Dienst des Projekts. Die Datenhoheit bleibt beim Nutzer, die Verfügbarkeit hängt aber an der eigenen Infrastruktur.

Die Exportwege sind breit: Markdown, HTML, JSON, Obsidian und Notion. Das ist relevant für die Frage, wie stark man sich bindet. Notizen, die sich nach Obsidian exportieren lassen, sind auch dann noch nutzbar, wenn ReadAny nicht mehr weiterentwickelt wird. Der Vektorspeicher dagegen ist nicht portabel, er lässt sich nur innerhalb der Anwendung verwenden. Wer die semantische Suche als langfristiges Archiv betrachtet, sollte die Markdown- oder JSON-Ausgabe als eigentliche Datenbasis ansehen und den Vektorspeicher als jederzeit neu erzeugbaren Index.

Vor dem Umstieg sind drei Dinge zu klären. Erstens der Inhalt der LICENSE-Datei, sofern eine Weitergabe geplant ist. Zweitens die Qualität der PDF-Extraktion an einem eigenen Beispieldokument. Drittens das Verhalten der Konfliktauflösung bei parallelen Änderungen auf zwei Geräten. Alle drei Punkte sind aus dem vorliegenden Material nicht abschließend zu beantworten.

Redaktionelles Fazit

ReadAny passt zu Lesenden, die ihre Bibliothek lokal halten wollen und bereit sind, einen OpenAI-kompatiblen, Claude-, Gemini-, DeepSeek- oder Ollama-Endpunkt selbst zu konfigurieren. Wer eine klare Lizenz für eine kommerzielle Weitergabe braucht, sollte vorher die LICENSE-Datei prüfen, weil die Metadaten NOASSERTION melden. Wer schnellen Beistand bei der Fehlersuche erwartet, sollte den Issue-Bereich sichten, denn dazu sagt das Material nichts. Prüfe zuerst, ob der gewählte Embedding-Anbieter über die konfigurierte Endpunkt-URL erreichbar ist; ohne diesen Schritt bleibt die semantische Suche funktionslos, während der Reader selbst weiterläuft.

Offizielle Quellen

1. codedogQBY/ReadAny on GitHub
2. Issues
3. Project website
4. README
5. Releases