Model or dataset
papersgpt/papersgpt-for-zotero avatar
papersgpt/papersgpt-for-zotero

PapersGPT for Zotero: a local indexing engine with a cloud model on top

A powerful Zotero AI and MCP plugin with ChatGPT, Gemini 3.7, Claude Fable 5, Claude Opus 5, DeepSeek V4, Grok, OpenRouter, Kimi k3, GLM 5.3, SiliconFlow, GPT-oss, Gemma 4, Qwen 3.8

2,639 stars96 forksJavaScriptAGPL-3.0

At a glance

What is it?
PapersGPT is a Zotero plugin that builds a local structural index over a PDF library and routes questions to either hosted models or a local LLM. The interesting part is the index. The unverifiable part is the benchmark table.
Who is it for?
Adopt PapersGPT if your work lives in Zotero and you want retrieval over a whole library without shipping PDFs to a hosted indexing service, and if you are willing to accept AGPL-3.0 terms for a plugin running inside your reference manager. Do not adopt it if you need a documented, reproducible accuracy figure before you commit, because the README publishes throughput and latency numbers but no retrieval-quality evaluation.
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 5 days ago.
What is it written in?
Mainly JavaScript, 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 gap PapersGPT is aiming at: Zotero holds the corpus, but not the questions

Zotero stores references and PDFs. It does not answer questions across them. The common workaround is to export files into a separate tool, run an embedding job, and keep that second copy in sync. PapersGPT takes the opposite position: it installs inside Zotero as a plugin and does its parsing, indexing and searching on the same machine, per the README's statement that these operations "can be run offline." The audience the README addresses is explicit: researchers with large libraries, described as 100 to 10,000+ PDFs, who want synthesis across documents rather than chat with one file. That is a narrower and more defensible target than general note-taking assistance. The questions the README uses as examples are comparative ones, for instance comparing sample sizes and p-values across fifty clinical trials in a folder. That kind of query is where single-document chat tools fall over, because the answer requires evidence assembled from several sources and then attributed back to each one.

What actually runs locally and what leaves the machine

The architecture splits into two halves, and the split matters more than the model list. Parsing, indexing and searching are local. The README states there is no reliance on the cloud for those steps and that they work offline, including in Airplane Mode. The generation step is where a network call happens, unless you choose a local model. PapersGPT offers three ways to reach an LLM: bundled open-source models such as Gemma 4 12B and Qwen3.5 4B that download from Hugging Face when you pick the Local LLM option; a custom OpenAI-compatible endpoint; or an existing Ollama instance. Hosted providers named in the repository description include ChatGPT, Gemini, Claude, DeepSeek, Grok, OpenRouter, Kimi, GLM, SiliconFlow and Qwen. So the privacy claim in the README, described as "zero-byte" data leakage, only holds end to end when you stay on the local path. If you configure a hosted API key, your retrieved passages go to that provider. The README does not present it that way. It presents privacy and offline operation as features of the product, then lists hosted models as a core feature in the same document. Both are true, but they describe different configurations, and the README does not draw the line clearly.

Structural indexing versus embeddings, as the README frames it

The README positions the engine against "fuzzy" semantic search by embeddings and says the index is structural: it understands document structure, which the README argues makes cross-paper comparison logically sound. No detail is given about what the structure is, how chunks are formed, or how retrieval ranks candidates. That is the largest gap in the material. The claim is a differentiator, but without a description of the index format or a retrieval evaluation, a reader cannot check whether structural indexing beats a well-tuned embedding pipeline on their own corpus. What the README does describe concretely is the interface around retrieval: an entire-library search toggle, built-in prompts for summary, background, literature review, theoretical frameworks and future directions, and click-to-jump citations that take you to the specific paper behind a statement. The citation behaviour is the part with the clearest practical value. A synthesis you cannot trace is not usable in a literature review, and the README's own framing, that accuracy is useless without proof, is the right instinct.

Installing it: one xpi, then a model decision

Installation is a Zotero plugin install, not a package manager install. The README's quickstart says to download the xpi from the papersgpt-v1.2.0 release asset and install it as a Zotero plugin, pointing to the project site for detail. There is no npm, pip or docker step in the material. After install, the interaction points are the PDF viewer and the main Zotero window. From an open PDF, click the PapersGPT icon in the top menu, or use Command + Enter on macOS and Ctrl + Enter on Windows. For multiple documents, select several files or a collection in the main window, holding Ctrl on Windows or Command on macOS. For the whole library, check "Search entire library" in the PapersGPT panel. Model selection and API key entry happen in the plugin's model settings, with the README deferring to the project site for that page. The README also describes saving answers and insights out of a conversation and closing the panel with the red X. Two integration paths sit outside the panel: an MCP server that exposes the local knowledge base to agentic tools such as Claude Code, Cursor and Windsurf, and a SKILL.md file for agents connecting to the local Zotero library. The MCP documentation link in the README points at a different repository, docsagent/docsagent, which is worth noting before you plan around it.

The benchmark table is the weakest evidence in the repository

The README publishes a scalability table: 1,000 PDFs at 4.2 GB indexed in 51.5 seconds with 13.1 ms average query time and 353 MB RSS; 10,000 PDFs at 42 GB indexed in 421 seconds with 19.5 ms average query time and 2.21 GB RSS, producing a 901 MB index. It also states the extension is "engineered in Native C++," while the repository's primary language is listed as JavaScript. Those two statements can coexist only if the C++ component is a compiled part of a JavaScript extension, and the material does not explain the split or say which parts are native. Treat the numbers as vendor-reported until you can reproduce them. There is no stated hardware specification in the README itself, only a pointer to a separate benchmark.md and "System Specs." Indexing time and query latency depend heavily on disk, CPU and document composition, and a corpus of 10,000 scanned PDFs is not the same workload as 10,000 text-layer PDFs. The more useful figure for a prospective user would be retrieval accuracy against a labelled set of questions, and that is absent. A fast index that returns the wrong passages is worse than a slow one that returns the right ones, and nothing in the material lets you distinguish between those cases before installing.

AutoPilot, and the batch job you are trusting it with

AutoPilot is described as defining a research goal and letting the model batch-process 1,000+ papers overnight, writing insights into Zotero Notes. This is the feature most likely to cause damage at scale, because it runs unattended over a corpus and writes into your library. The README does not say how results are labelled, whether runs are resumable, whether Notes are overwritten on a second run, or what happens when a model call fails partway through a thousand documents. Those are the questions to answer before pointing it at a real collection. The same caution applies to the whole-library search toggle: retrieval over 10,000 documents with a hosted model means a large volume of extracted text leaving your machine, one query at a time. Neither AutoPilot nor whole-library search is inherently wrong, but the README's privacy framing does not account for the hosted-model case, and a reader could reasonably come away thinking all of it stays local.

Where a different tool is the better answer

If your question is about one paper, Zotero's own PDF reader plus a general chat assistant is a smaller dependency than a plugin with a local index and a model backend. If your corpus is small, say a few dozen PDFs, the indexing layer buys you little; the setup cost of choosing a model, entering keys and waiting for a first index outweighs the retrieval benefit. If you need auditable, reproducible retrieval for a systematic review, a scripted pipeline built on an embedding model and a vector store you control gives you a retrieval log and tunable parameters, whereas PapersGPT exposes no ranking controls in the material. The honest comparison is not PapersGPT versus another Zotero plugin. It is PapersGPT versus building the pipeline yourself: the plugin trades control and transparency for an install that takes minutes and an index that runs on your laptop.

Licence, maintenance and what to check before you commit

PapersGPT is licensed AGPL-3.0. For a Zotero plugin you install and use locally, the practical effect is that the source is available and modifications you distribute carry the same licence. If your institution wraps this in an internal service that other people interact with over a network, the AGPL's network clause is the part to read, and that is a question for your legal team rather than for this article. On maintenance: three releases landed between 2026-08-05 and 2026-08-28, and the last push to the main branch is dated 2026-09-07, so the project is active on the evidence available. That also means the model list in the description, which names versions like Claude Opus 5, Gemini 3.7 and DeepSeek V4, will drift faster than the plugin's own code, and provider-side deprecations are the likely source of breakage. There is no upgrade path described in the README, no migration note for the index format between v1.0.0 and v1.2.0, and no statement about whether an existing index must be rebuilt after an update. Before you commit a large library to it, install the xpi on a test profile with a small collection, run one comparative query across several papers, and click through the citations to confirm they land on the passages you expect. That check takes minutes and tells you more than the benchmark table does.

Editorial conclusion

Adopt PapersGPT if your work lives in Zotero and you want retrieval over a whole library without shipping PDFs to a hosted indexing service, and if you are willing to accept AGPL-3.0 terms for a plugin running inside your reference manager. Do not adopt it if you need a documented, reproducible accuracy figure before you commit, because the README publishes throughput and latency numbers but no retrieval-quality evaluation. Before installing, verify three things yourself: the xpi attached to papersgpt-v1.2.0 on the releases page, whether your Zotero version loads unsigned or third-party plugins, and whether the local LLM download path pulls Gemma 4 12B or Qwen3.5 4B from Hugging Face on a machine where that is permitted.

Official sources

  1. License: AGPL-3.0
  2. papersgpt/papersgpt-for-zotero on GitHub
  3. Project website
  4. README
  5. Releases
Community notes

Community notes