Open Paper: a research library workbench with citation-grounded AI

The context-switching problem Open Paper targets

Reading a paper is rarely a linear act. You stop to look up a term, follow a reference into a second PDF, then try to remember which of three papers contained the result you highlighted last week. Open Paper's README frames the product around exactly that loop, describing reading as "constant context switching" and positioning the workspace as a way to keep lookup, reference chasing and re-finding inside one place. The audience is therefore narrow and specific: people who read papers as a sustained activity, such as graduate students running a literature review, research engineers tracking a subfield, or analysts who need to pull the same fields out of dozens of PDFs. It is not a reference manager in the Zotero sense, although it imports from Zotero, and it is not a general document chat tool. The unit of work is the paper, and the surrounding objects are annotations, notes, projects and cross-paper questions.

How the citation-grounded assistant and annotation layer fit together

The README describes a side-by-side layout: the PDF and the assistant occupy the same view, so asking a question does not mean leaving the document. On upload, the system produces an AI-generated brief plus starter questions. Every assistant response carries contextual citations, and clicking one jumps to the passage in the paper the answer came from. That citation behaviour is the design claim worth scrutinising, because it is the difference between a summariser and something you can check. The repository backs the claim with an evaluation suite: the README points to server/evals/README.md and to ResearchQA, described as a citation-grounded benchmark for scientific QA, with methods, metrics and instructions for running it yourself. Annotations are the second layer. Selecting text lets you highlight it, attach a comment, or send it to the assistant for a deeper explanation, and notes are stored in context with the paper with a markdown view available. Projects sit above individual papers: grouping papers unlocks cross-paper questions, artifact generation and data tables where you define a custom schema and extract fields across every paper in the project, each cell grounded in its source, with CSV export. Architecturally the repository is three services: a FastAPI backend under server/, a Next.js web app under client/, and a Celery worker under jobs/ that the README says handles async work including PDF parsing, Zotero sync and audio. A docker-compose.dev.yml and a docker/ directory are present at the top level for local orchestration.

Installing Open Paper locally from DEVELOPMENT.md

The README does not give a one-line install. It states that the full stack can be run yourself, warns that the project is built primarily as a hosted service and is not optimized for self-hosting, and names the components you will assemble: Postgres, S3-compatible storage, LLM API keys and background workers. It then says the setup in DEVELOPMENT.md is the best starting point. The repository layout confirms the shape of that setup: three services plus a compose file. The README names the per-directory documentation as the entry point for each service, and those files are what you read before starting anything. It also links the three READMEs directly, so the links below are the ones it gives.

DEVELOPMENT.md
server/README.md
client/README.md
jobs/README.md

DEVELOPMENT.md is described as the full setup guide covering prerequisites, environment variables and how to start all three services. server/README.md covers the FastAPI backend, client/README.md the Next.js web app, and jobs/README.md the Celery worker for async processing. The repository root also contains docker-compose.dev.yml, which is the local orchestration file present in the top-level listing. Because the README does not print the compose command or the environment variable names itself, read DEVELOPMENT.md for those before running anything; what you should expect once the stack is up is the backend, the client and the worker running together, with the client reachable in a browser. For a first real use, the README's own sequence is upload a PDF, read the generated brief and starter questions, then select a passage and send it to the assistant. If you would rather not assemble any of this, the README points to the hosted instance at openpaper.ai as the primary way to try it.

Where self-hosting Open Paper stops being reasonable

The README is unusually direct about this: Open Paper is built primarily as a hosted service and is not optimized for self-hosting, so you should "expect some assembly". That is a real constraint, not a disclaimer. Four external dependencies must be satisfied before the product does anything useful: a Postgres database, S3-compatible object storage, LLM API keys, and background workers. Each is an operational surface you own. The Celery worker is not optional if you want the features that depend on async processing, and the README lists PDF parsing, Zotero sync and audio overviews as its responsibilities, which means the reading experience itself is gated on a worker being healthy. There is also a data-egress question the README does not resolve: the assistant requires LLM API keys, so paper content leaves your infrastructure for whichever provider you configure. If your institution forbids sending unpublished manuscripts to a third-party model, self-hosting Open Paper does not by itself solve that problem. Finally, the README does not document rollback, backup or upgrade procedures for a self-hosted deployment, and no releases were retrieved, so there is no published version history to pin against. Treat the self-hosted path as a development environment that you would have to harden yourself, and confirm that assumption against DEVELOPMENT.md before promising it to anyone else.

Open Paper compared with a plain PDF annotator

The obvious alternative is a conventional PDF reader with annotation, where highlights and comments live in the file and nothing is indexed across documents. The difference in approach is where the intelligence sits. A plain annotator treats each PDF as an isolated artifact: you search inside one document, and cross-document recall is your own memory plus your folder names. Open Paper makes the library the queryable unit. Projects group papers, questions can span the whole collection, and data tables let you define a schema and extract the same field from every paper in a project with each cell citing its source. That is a different bet about where the work happens: less time organising files, more time defining what you want extracted. The trade is that the cross-paper features depend on the ingestion pipeline and the LLM provider being configured and working, so a broken worker degrades you below the plain-annotator baseline rather than simply leaving you where you started. The README also positions Open Paper against the reference-manager workflow by importing from Zotero and keeping the library in sync, rather than asking you to abandon it.

Licence and the cost of keeping a fork alive

Open Paper is licensed under AGPL-3.0, with the licence file at the repository root. The practical implication for a team is that the network copyleft applies if you modify the software and let users interact with it over a network, which is exactly what a self-hosted deployment is. If you plan to run a modified Open Paper as an internal or public service, read the licence text rather than assuming the obligations match a permissive licence; this is not legal advice, and the specifics depend on what you change and how you expose it. On maintenance, the last push to the default branch was on 2026-09-03, and the repository is not archived, so the codebase is recent. That does not tell you anything about release cadence, because no releases were retrieved and the README does not describe a versioning or upgrade path. Upgrading a self-hosted instance therefore means tracking the master branch and reading the per-service READMEs for changes, which is a different kind of cost from pulling a tagged release. Budget for that, and for the possibility that a schema change in the Postgres database arrives without a migration note you can act on.

Editorial conclusion

Adopt Open Paper if you read papers in volume and want annotations, project-level extraction tables and an assistant whose answers link back to the passage they came from; the hosted service at openpaper.ai is the path the README points to. Do not adopt it if you need a turnkey on-premise deployment, because the README states the stack is built primarily as a hosted service and is not optimized for self-hosting. Before committing, verify three things in DEVELOPMENT.md: the exact environment variables for Postgres, S3-compatible storage and your LLM API key, whether your licence obligations under AGPL-3.0 are acceptable for how you plan to run the server, and whether the Celery worker in jobs/ is required for the PDF parsing and Zotero sync you depend on.

Frequently asked questions

Official sources

1. Issues
2. khoj-ai/openpaper on GitHub
3. License: AGPL-3.0
4. Project website
5. README