PaperQuay: an Electron paper workspace that keeps translation, notes and an agent in one app
A desktop-first literature manager for PDF reading, translation, paper overviews, and AI agent workflows.
At a glance
- What is it?
- PaperQuay is an AGPL-3.0 desktop literature manager that pre-translates MinerU-parsed PDF blocks, stores notes and overviews in local SQLite, and exposes an OpenAI-compatible agent for library chores. It is worth a look if you already run your own model endpoint; it is not a Zotero replacement.
- Who is it for?
- Adopt PaperQuay if you read PDFs on a desktop, already have an OpenAI-compatible endpoint, and want translation, notes and a local RAG index in one process. Do not adopt it if you need a browser client, a mobile reader, or a drop-in Zotero replacement with live sync; the README describes Zotero import as an optional source, not a two-way bridge.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 14 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 switching problem PaperQuay is built around
The README frames the target user narrowly: graduate students, researchers and heavy paper readers who currently move between Zotero, a PDF viewer, a translation tool, a chat window and a separate note app. Each hop costs context. A translated paragraph in a browser tab is not linked to the page it came from, and a note written elsewhere loses its anchor in the PDF. PaperQuay's answer is to run all of those steps inside one Electron process, with a local SQLite database as the shared spine. The positioning is deliberately not "better Zotero". Zotero compatibility is described as optional rather than mandatory, which matters: the project imports collections, tags and PDF attachments, but the README does not present it as a live two-way sync. If your workflow depends on Zotero being the system of record across devices, that framing should give you pause before you migrate anything.
How the pieces fit: renderer, main process, and a local Node backend
The architecture is a standard Electron split, described in the README as Electron + React + TypeScript/Vite. The React renderer holds the library UI, the PDF reader, the Tiptap/ProseMirror note editor, the agent workspace and settings. The Electron main process plus a local Node.js backend own filesystem access, IPC, Zotero import, SQLite persistence, app updates and cross-platform packaging. PDF rendering goes through PDF.js. Storage is SQLite via sql.js together with sqlite-vec, which is what backs the local RAG retrieval. AI calls, including translation, paper overviews, agent tool use and RAG, all go out through OpenAI-compatible APIs, so the model choice is yours and the app does not ship a fixed provider. The interesting part is the parsing layer: translation is not applied to raw PDF text but to MinerU structural blocks, which is why the app can jump to a specific translated block instead of re-translating a selection and waiting.
Block-level translation versus the select-and-wait pattern
The README's comparison table is the clearest statement of the design bet. In the conventional pattern, you highlight text, a request goes out, and you wait with a visible API delay while the translation arrives. PaperQuay instead pre-translates MinerU structural blocks and caches them, so navigation to a translated block is instant. The second half of the bet is layout: rather than a two-column side-by-side view that forces constant eye movement, the original PDF stays visible and you navigate to translated blocks on demand. This is a real trade-off, not a free win. Pre-translation means you pay token cost and latency up front for blocks you may never read, and the quality of the whole feature is bounded by MinerU's parse. If MinerU mis-segments a two-column paper or mangles a formula, the translated block inherits that error, and the README does not describe a manual block-editing escape hatch. The v0.1.24 notes mention a configurable API base URL for MinerU, which is what makes a local MinerU deployment practical, but the parsing quality question stays with MinerU, not PaperQuay.
Getting it running from the repository
The README points to a First Run Workflow section and a Development section rather than printing a single install command in the text available here, so the honest instruction is to follow those two sections in the repository. What is documented concretely is the configuration surface: AI features connect through OpenAI-compatible endpoints, meaning you supply a base URL, a model name and runtime parameters in settings, and MinerU parsing accepts a configurable API base URL so a self-hosted MinerU instance can be pointed at instead of a hosted one. Storage is local SQLite, and the v0.1.24 notes state that changing the library storage folder migrates the existing directory structure and attachment paths into the new location, so the library is relocatable after the fact. Releases are tagged app-v0.1.25 (2026-08-11), app-v0.1.24 (2026-07-09) and app-v0.1.23 (2026-06-13), which is a roughly monthly cadence across those three. The last push to main was on 2026-09-02, so the repository is not archived and has been touched recently, but a single push date is not a maintenance guarantee.
Where PaperQuay is the wrong tool
The desktop-first framing is a constraint, not a slogan. There is no browser client and no mobile reader described in the README, so anyone who reads on a tablet or wants their library reachable from a work laptop without installing an Electron app is outside the intended shape. The second limitation is the model dependency. Translation, overviews, agent tool use and RAG all route through OpenAI-compatible APIs, which means the app is only as useful as the endpoint you point it at, and there is no bundled local model. If you have no endpoint and no budget for tokens, the AI half of the product is inert. Third, the agent features are described as assistance for batch rename, metadata completion, tagging and classification. That is a description of capability, not of accuracy. The README does not document a rollback path for a bad batch operation, and until you have verified that on your own library, treating agent-driven renames as reversible would be an assumption. Finally, the licence is AGPL-3.0-only, which is a genuine consideration if you plan to modify and distribute the app rather than use it personally.
How it differs from Zotero plus a translation plugin
The obvious alternative is staying in Zotero and adding a PDF translation plugin. The approaches diverge at the data model. Zotero is a reference manager first: items, collections and attachments are the primary objects, and reading is a view onto them. PaperQuay inverts that. The paper, its MinerU-parsed blocks, the cached translation, the Tiptap notes, the structured overview and the RAG index all live in one local SQLite database, and the reference metadata is one field among several rather than the organizing principle. That is why the app can link a note to a PDF position and a translated block to its source text in a way a plugin bolted onto Zotero struggles to do. The cost is ecosystem: Zotero has citation styles, group libraries and a plugin surface that PaperQuay does not claim. If your output is a manuscript with a bibliography, Zotero still owns that job. If your output is understanding a stack of papers quickly, PaperQuay's model fits better. The README also lists a knowledge graph with reference syncing, relation controls and export tools, which pushes further in the direction of a reading workspace rather than a citation store.
Maintenance cost and what AGPL-3.0-only means here
Two things drive the upgrade cost. The first is the release cadence: three tagged releases between 2026-06-13 and 2026-08-11, with the last push on 2026-09-02. Monthly-ish releases on a v0.1.x line mean the surface is still moving, and the v0.1.24 notes list changes across review export, knowledge graph, MinerU configuration, library storage migration and note synchronization. Storage migration in particular is the kind of change that touches your data directory, so a backup before upgrading is a reasonable habit rather than a paranoid one. The second is the external dependency on MinerU and on your model endpoint; neither is versioned by PaperQuay, so an upstream change on either side can alter behaviour without a PaperQuay release. On licensing, PaperQuay is AGPL-3.0-only. For individual research use that is unremarkable. If you fork it and offer it as a network service, the AGPL's source-availability obligations are the part to read carefully, and the licence identifier in the repository is the authoritative text rather than anything written here.
Editorial conclusion
Adopt PaperQuay if you read PDFs on a desktop, already have an OpenAI-compatible endpoint, and want translation, notes and a local RAG index in one process. Do not adopt it if you need a browser client, a mobile reader, or a drop-in Zotero replacement with live sync; the README describes Zotero import as an optional source, not a two-way bridge. Before committing, verify three things on your own machine: that your MinerU deployment answers at the configurable API base URL, that the app builds on your platform from the repository's development instructions, and that AGPL-3.0-only is acceptable for how you intend to distribute anything you modify.
Community notes