llm-for-zotero: a research agent that lives inside the Zotero PDF reader
An open-source research agent system for your Zotero library.
At a glance
- What is it?
- This Zotero 7/8/9 plugin puts chat, summarization, figure inspection and library-wide agent workflows into the reader pane, with a choice of API providers, local models, WebChat, Codex App Server or Claude Code as the backend. The interesting part is not the chat box, it is the agent layer that reads and edits the library itself.
- Who is it for?
- Adopt it if you already keep your reading in Zotero and want the model to work against the library rather than against a pasted PDF. Skip it if you need a stable, fully documented agent API, or if Claude Code Mode is the reason you are here, since the README labels that path experimental and without native Zotero API operations.
- 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 1 day 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 gap it fills: reference managers store PDFs, they do not read them
Zotero is good at collecting. It is indifferent to what is inside the collection. The usual workaround is to export a PDF, paste it into a chat window, lose the citation anchor, then copy the answer back into a note by hand. llm-for-zotero removes the copy step by rendering the assistant inside the Zotero PDF reader itself. The README describes the target as asking questions, summarizing papers, inspecting figures, comparing sources and saving notes without leaving the library. The audience is narrow and identifiable: researchers who already run Zotero 7, 8 or 9, who keep more than a handful of papers, and who want answers tied back to a passage rather than to a model's memory. It is not a general document chat app. Everything it does is anchored to items that exist in a Zotero library, and the features that matter most, library-wide search and tagging, only make sense once that library is large enough to be hard to navigate manually.
Architecture: a Zotero plugin with a pluggable backend and an agent loop
The project is TypeScript and is built on the Zotero Plugin Template, which the README credits via badge. That template supplies the standard plugin scaffolding: a bootstrap file, a preferences pane registered under Preferences -> llm-for-zotero, and UI injected into the reader. The model layer is abstracted behind provider protocols. The README lists four: responses_api, openai_chat_compat, anthropic_messages and gemini_native. That abstraction is what lets the same sidebar talk to a hosted API, a local OpenAI-compatible server, ChatGPT WebChat, Codex App Server, or Claude Code. Above the transport sits Agent Mode. According to the README it is cache-aware: it preserves stable paper context, prior read evidence and coverage state across longer turns, then compacts old transcript history when the context window fills. That is the design decision worth noting. Rather than re-sending the whole conversation, the agent keeps a small set of durable state and discards the rest, which is what makes multi-step library operations affordable in tokens. The Claude Code path is architecturally different: it runs Claude Code as a separate conversation system through a local bridge, and the README states it does not yet support native Zotero API operations. So the plugin has two tiers, one that can act on the library and one that can only talk.
Getting it running: xpi install, provider config, Test Connection
Installation is manual. Download the latest .xpi from the Releases page, then in Zotero open Tools -> Add-ons -> gear icon -> Install Add-on From File, select the .xpi, and restart Zotero. Configuration happens in Preferences -> llm-for-zotero: pick a Provider, paste the API Base URL, the secret key and the model name, then click Test Connection. The README's Quick Start gives exactly this sequence. Two details are easy to miss. First, you can register several providers and models and route different tasks to different ones, for example a multimodal model for figures and a text model for summaries. Second, the conversation panel exposes model-specific reasoning levels plus hyperparameters named temperature and max_tokens_output. If you would rather not use an API key at all, the README points to WebChat or Codex App Server as starting points; Codex App Server is described as the recommended Codex path for ChatGPT Plus subscribers and is configured from the Agent tab, running through a local codex app-server runtime. The README does not, in the material available here, spell out the exact preference keys for the WebChat bridge, so treat that setup as something to read from the linked documentation page before you commit to it.
Agent Mode and Skills: where this stops being a chat sidebar
Agent Mode is the part that distinguishes the project from the many PDF chat plugins. The README lists its scope as library-wide read, search, tagging, metadata, import, note-editing and organization workflows. Read that list literally: the agent can modify your library, not just answer questions about it. Skills are the extension point for that behaviour. The plugin ships with 8 built-in skills and a portal for creating your own, which means the research workflow is configurable rather than fixed. This is also where the risk concentrates. An agent that can tag, edit notes and reorganize items is operating on data that may have taken years to assemble, and the README does not describe a dry-run mode, an undo log, or a staging area for proposed changes. The cache-aware context handling mitigates token cost, not correctness. If you enable Agent Mode, the sensible posture is to point it at a test collection first and watch what it writes. The project is at v3.9.6 with three releases in the ten days before the last push, so the agent surface is moving quickly, which cuts both ways: fixes arrive fast, and behaviour you rely on today may shift.
Notes, citations and MinerU: the parts that touch your filesystem
Two subsystems reach outside Zotero. File-Based Notes writes Markdown to local folders, and the README names Obsidian, Logseq and any plain Markdown directory as targets. That is a plain-text escape hatch: your annotations survive even if you later abandon the plugin. The second is MinerU PDF parsing, described as higher-fidelity extraction for tables, equations and figures, with support for local mineru-api servers and a file manager covering bulk parsing, cache repair, sync packages, tags and parsing filters. The existence of cache repair in that list is informative. Parsing pipelines fail, caches go stale, and the project has built UI for it rather than pretending it does not happen. Citation handling is deliberately conservative: the README says citation labels stay conservative until page locations are verified, while quote-based citations can jump back to the matching Zotero passage. That is the right trade-off. A citation that jumps to the wrong page is worse than one that admits it only knows the quote. General Web Search is separate and uses Tavily to search the public web and read pages, attaching source links to the answer. Tavily is a third-party service, so enabling it sends your queries outside your machine, which the README's Privacy and Data Flow section presumably covers in more detail than the excerpt here shows.
Limitations and the wrong-tool cases
The clearest constraint is stated by the project itself: Claude Code Mode is experimental and does not support native Zotero API operations. If your reason for wanting this plugin is to drive Claude Code against your library, that path will not do it yet. Second, the whole thing is a Zotero plugin. It requires Zotero 7, 8 or 9, it requires a restart to install, and it lives or dies with Zotero's plugin API. Anyone who reads papers primarily in a browser, a reference manager other than Zotero, or a plain folder of PDFs gets nothing from it. Third, the backend is your responsibility. The plugin ships no model. Every provider path, API key, local server, WebChat session or Codex runtime, is something you configure and pay for, and the README's own fallback advice for people without an API key is to use WebChat or Codex App Server, which means depending on a browser session or a subscription rather than a documented API. Fourth, Agent Mode's write access to library metadata and notes has no documented rollback in the material available. Fifth, the documentation excerpt here is a README, not an API reference. There is no published description of the skill file format, the agent's tool surface, or how coverage state is persisted. For a plugin that edits your library, that is a real gap, and it is the thing I would want filled before enabling the agent on a large collection.
What it is not: the difference from Zotero's own built-in tools and from generic PDF chat
The obvious comparison is Zotero's native tooling. Zotero has a built-in PDF reader, annotation, tagging and search, and it does all of that without a model and without a network call. It cannot summarize a paper, compare two sources, or read a figure. The comparison that matters more is with generic PDF chat tools and with reference managers that have added AI features. A generic chat tool receives a document you hand it and forgets your library. llm-for-zotero receives a library and, in Agent Mode, can act on it: search across items, apply tags, edit metadata, import, and write notes back. That is a different unit of work. The cost of that difference is that the plugin is coupled to Zotero's internals and to the Zotero Plugin Template's release cadence, while a standalone chat tool is coupled to nothing. If your reading is already in Zotero and you want the model to operate on the collection as a whole, the coupling buys you something. If you read ad hoc and never maintain a library, it buys you nothing and adds an install step, a restart, and a provider configuration to maintain.
Licence, maintenance and the upgrade bill
The licence is AGPL-3.0. The practical consequence, stated plainly and without legal advice: if you modify the plugin and let others interact with it over a network, the AGPL's source-disclosure obligations are the ones to read, and if you only install the .xpi for personal use, the obligations are much lighter. Anyone embedding this in a hosted service should read the licence text itself rather than a summary. On maintenance, the repository is active and not archived, the last push is dated 2026-09-09, and v3.9.6, v3.9.5 and v3.9.4 all landed within roughly two weeks of each other. That release cadence is the upgrade cost. A Zotero plugin is not a library you pin and forget: Zotero updates can break plugins, the README's badges cover Zotero 7, 8 and 9, and the changelog entries show features being reworked, not just patched, including the Codex App Server path being designated the recommended one and Claude Code arriving as experimental. Budget for reading release notes before each upgrade and for testing Agent Mode against a small collection after one. The upside of the cadence is that documented gaps, including the missing native Zotero operations in Claude Code Mode, are the kind of thing this project has been closing release by release.
Editorial conclusion
Adopt it if you already keep your reading in Zotero and want the model to work against the library rather than against a pasted PDF. Skip it if you need a stable, fully documented agent API, or if Claude Code Mode is the reason you are here, since the README labels that path experimental and without native Zotero API operations. Before installing, verify three things: that your Zotero version is covered by the 7/8/9 badges, that your chosen provider protocol matches one of responses_api, openai_chat_compat, anthropic_messages or gemini_native, and that you accept AGPL-3.0 terms if you plan to redistribute a modified build.
Community notes