ReadAny: a local-first e-book reader that answers questions about your library
AI-powered cross-platform e-book reader with semantic search, RAG chat, local vector store, notes, TTS, and WebDAV sync.
At a glance
- What is it?
- ReadAny is a TypeScript e-book reader for desktop and mobile that pairs EPUB and PDF reading with local embeddings, hybrid vector plus BM25 retrieval, and RAG chat. The interesting part is not the chat window, it is where the vectors live and what that costs you.
- Who is it for?
- Adopt ReadAny if you read long-form EPUB or PDF material on more than one device, you already pay for an OpenAI, Claude, Gemini or DeepSeek key (or run Ollama locally), and you want highlights and notes to stay in a SQLite file you control. Do not adopt it if you need DRM-protected commercial e-books, if you expect the AI features to work with no provider configured at all, or if you want a single machine-readable licence grant before shipping it inside a company image.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 5 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem ReadAny targets: reading produces notes you cannot search by meaning
Most e-book readers treat a book as a document to render. Search means substring matching, notes mean a separate pane, and nothing connects a highlight in chapter three to a question you have in chapter nine. ReadAny's README frames the gap in three questions: why do I forget what I read, why are my notes scattered, why can I only search by keywords. That is a knowledge-management complaint, not a rendering complaint, and the feature list follows from it. Semantic search, RAG chat, highlights, Markdown notes, and export to Markdown, HTML, JSON, Obsidian and Notion are all retrieval and capture features. The reading surface is table stakes.
The audience is therefore narrower than the download table suggests. A reader who finishes one novel a month and never annotates gets nothing from a vector index. The tool is aimed at people who accumulate non-fiction, technical books, papers in EPUB or PDF form, and who want to ask a question against the whole library rather than one file. The README's own comparison table puts ReadAny against Calibre, KOReader and Apple Books, and the only rows where ReadAny claims a check mark that the others do not are AI chat, semantic search, local vector store, WebDAV sync and a skills system. Calibre wins on format count, fifteen against ten or more. That trade is the whole product in one line: fewer formats, more retrieval.
How the retrieval actually works: embeddings, a local vector store, and BM25 side by side
The README describes hybrid retrieval, vector search combined with BM25. Those two mechanisms fail in opposite directions. A dense vector index maps a query and a passage into the same embedding space, so a search for how a character changes over a series can surface passages that never use the word change. BM25 is a lexical scorer, so it reliably finds an exact term, a proper noun, a code identifier, that an embedding model may smear into a nearby concept. Running both and merging results is the standard answer to the fact that neither alone is sufficient, and the README states the hybrid is what backs semantic search.
The second design decision is where the index lives. ReadAny advertises a local vector store and local embeddings, and the topics list SQLite and vector-search. The practical consequence is that indexing runs on your machine, the vectors sit in a local database file, and the retrieval step for search does not require a network round trip. Chat does, unless you point it at Ollama. So the privacy claim is precise rather than total: your books, highlights and notes are not uploaded for indexing, but the passages selected as context for a chat answer go to whichever provider you configured. The README's privacy row says local vector store, fully offline capable, and offline capability is real only in the Ollama configuration.
Above retrieval sits a skills system. The README lists built-in skills for summarization, concept explanation and character tracking, plus custom skills. A skill is the prompt and context-assembly layer: which passages get pulled, how they are ordered, what the model is asked to do with them. That is a sensible place to put the variability, because the retrieval layer stays fixed while the task changes. The README does not document the skill file format, so treat custom skills as a feature you will have to learn from the app rather than from the documentation.
Installing ReadAny: Homebrew on macOS, direct downloads elsewhere
The README gives one package-manager path and a table of direct downloads. On macOS the Homebrew route is two commands:
brew tap codedogQBY/readany brew install --cask readany
The tap and cask names are lowercase and differ from the repository owner string, which is worth noticing because a mistyped tap fails with a confusing error. For everything else the README points at the releases page: a .dmg for Apple Silicon, a separate .dmg for Intel, a .msi for Windows, an .AppImage for Linux, and an .apk for Android. iOS is distributed through TestFlight at a join link, not through the App Store, which means the iOS build is a beta channel and enrolment is a step you have to complete before the app exists on your phone.
The three-step quick start is import, read, configure AI, and the README marks the AI step optional. That ordering matters. You can install ReadAny, drag in an EPUB, and read it with highlights, notes, TTS and statistics without configuring any provider. The provider list is OpenAI, Claude, Gemini, Ollama, DeepSeek and custom OpenAI-compatible endpoints. Ollama is the only entry in that list that keeps the whole pipeline on your hardware, so if the offline claim is what drew you in, Ollama is the configuration that delivers it. Translation is separate and supports either an AI provider or DeepL across nineteen languages.
Sync is WebDAV, not a hosted service. The README advertises auto sync in the background and merge for concurrent edits. That is a meaningful constraint as much as a feature: you supply the WebDAV endpoint, and the quality of conflict resolution is something you will judge against your own editing pattern, not against a vendor SLA.
Where ReadAny stops being the right tool
The format list is ten entries, and the README is explicit that two of them are conversions rather than native support: TXT and UMD are imported by converting them to EPUB so that notes, search and sync work on them. Conversion is a reasonable choice, but it means the reader is operating on a generated file, and any fidelity loss in that step propagates into your highlights and your vector index. If your library is mostly plain text, you are paying a conversion tax on every import.
DRM is the harder boundary. Nothing in the README mentions DRM-protected content, and the format list is EPUB, PDF, MOBI, AZW, AZW3, FB2, FBZ, CBZ, TXT and UMD. AZW and AZW3 are Kindle container formats, but the presence of the extension in a support list says nothing about whether encrypted files from a store will open. If your reading is purchased and DRM-locked, assume ReadAny is not the tool until you have verified otherwise on your own files.
The AI features have a second failure mode that the marketing framing hides. Semantic search depends on an embedding model, and chat depends on a completion model. The README does not state which embedding model is used, whether it is bundled, or what happens to the index when you change providers. Changing an embedding model invalidates every vector you have already computed, because vectors from different models are not comparable. That is a general property of vector stores, not a ReadAny bug, but the documentation as supplied does not say how the app handles it, so the safe assumption is that a provider switch means a re-index and you should confirm that before building a large library.
Finally, the skills system and the local vector store are the two features with the least documentation in the README. Both are listed as capabilities with no configuration reference. That is a gap you should weigh against the fact that the rest of the feature set, reading, highlighting, TTS, statistics, sync, is conventional and well understood.
Calibre and KOReader solve a different half of the problem
Calibre is the obvious comparison and the README makes it directly, claiming fifteen or more formats against ReadAny's ten plus. The difference in approach is not a feature count, it is what the application is for. Calibre is a library manager first: it catalogs, converts, tags, and moves books onto devices, and its reader is one component of that pipeline. ReadAny is a reader first, with the vector index and the annotation store as the center of gravity. If your problem is a thousand files in eleven formats that need metadata, conversion and device transfer, Calibre is the mature answer and ReadAny's AI layer does not compensate for the missing catalog tooling.
KOReader is the other useful contrast. It runs on e-ink hardware, which is where a lot of long-form reading actually happens, and the README's own table credits it with limited TTS and no AI chat or semantic search. ReadAny's platform list is macOS, Windows, Linux, iOS and Android. There is no e-ink target. So the two tools are not competing for the same reading session: KOReader for a device with a month of battery, ReadAny for a laptop or phone where an embedding index and an API call are cheap.
Against Apple Books, the difference is the local vector store and the export formats. Apple Books keeps you inside Apple's ecosystem and gives you no portable annotation file. ReadAny's Markdown, HTML, JSON, Obsidian and Notion exports are the escape hatch, and for anyone who already lives in Obsidian that export path is probably the single most useful line in the README.
Licence status, maintenance signals, and what a NOASSERTION label means in practice
The repository metadata reports the licence as NOASSERTION, which is the string GitHub emits when it cannot match the LICENSE file to a known licence. That is not the same as having no licence, and it is not the same as having a permissive one. It means the terms are whatever the file on the main branch says, and a reader of this article cannot tell you what those terms are. If you are evaluating ReadAny for personal use, read the file and move on. If you intend to redistribute it, bundle it into a corporate image, or build on the source, the licence is the first thing to resolve, and this article cannot resolve it for you.
Maintenance signals visible in the supplied material are the release cadence and the version numbering. The releases listed are v1.3.4 in June 2026, v1.3.5 in July 2026 and v1.3.6 in August 2026, roughly monthly, with the last push to the repository dated September 2026. The README also announces a v2.0 update that brings the iOS and Android apps, which is a larger jump than the patch numbers around it and suggests the mobile clients arrived as a separate effort from the desktop line. The gap between the v1.3.x release tags and a v2.0 announcement in the README is worth checking on the releases page before you pick a build, because the two numbering schemes are not obviously the same track.
Upgrade cost is dominated by the index rather than the binary. Replacing an application binary is cheap on every platform listed. Rebuilding a vector index over a library is not, and it is the operation most likely to be triggered by an upgrade that changes the embedding model or the index schema. The README does not describe index migration, so the practical advice is to keep your source book files in a directory you control and treat the local database as regenerable. WebDAV sync adds a second consideration: if the sync format changes between versions, your other devices are the test.
Editorial conclusion
Adopt ReadAny if you read long-form EPUB or PDF material on more than one device, you already pay for an OpenAI, Claude, Gemini or DeepSeek key (or run Ollama locally), and you want highlights and notes to stay in a SQLite file you control. Do not adopt it if you need DRM-protected commercial e-books, if you expect the AI features to work with no provider configured at all, or if you want a single machine-readable licence grant before shipping it inside a company image. Before installing, open the LICENSE file on the main branch and read it, because the repository metadata reports NOASSERTION and that is not a licence you can act on. Then check the releases page for a build matching your platform, since the README lists macOS, Windows, Linux, iOS via TestFlight and Android APK as separate downloads rather than one universal package.
Community notes