Talk2Arxiv: Chat With Any ArXiv or bioRxiv Paper by Changing the URL

One URL Change That Loads the Full Paper in Context

Talk2Arxiv solves a specific navigation friction: researchers often want to ask questions about a paper they are reading, but switching to a chat interface and pasting text loses the paper's structure and equations. The project removes that step by making the paper URL itself the activation mechanism.

Changing arxiv.org to talk2arxiv.org in any paper link opens the paper in a reader interface with a chat panel alongside it. The same substitution works for bioRxiv: biorxiv.org becomes talk2biorxiv.org. The README gives a concrete example: arxiv.org/abs/1706.03762 becomes talk2arxiv.org/abs/1706.03762.

The target users are researchers and engineers who read papers regularly and want to interrogate a specific paper's content, methodology, or conclusions without switching tools. The project runs as a hosted web service at talk2arxiv.org and talk2biorxiv.org, so most users need no setup at all.

Full-Paper Context Without Chunking or Vector Search

Most paper chat tools split the document into chunks, embed them, and retrieve relevant sections for each question. Talk2Arxiv takes the opposite approach: the full paper text goes into a single prompt, and every question in a conversation has access to the complete document from the first token.

This is made practical by OpenAI's prompt cache. The paper text is sent once and cached on the model provider side, so subsequent questions in the same conversation reuse the cached context rather than resending the full paper each time. The README describes this as the mechanism behind the whole-paper context feature.

The cost of this approach is a hard ceiling. Papers that exceed approximately 800K tokens produce a clear error message rather than a partial response. The README states this limit explicitly. Very long survey papers or papers with extensive appendices may hit this limit, and there is no fallback to chunked retrieval when they do.

Architecture: Vercel Frontend and a Cloudflare Worker

The application splits into two deployed components. A React application built with Vite and Tailwind CSS runs on Vercel and handles the reader interface, the chat panel, and both domains. A Cloudflare Worker handles the API:

The Worker's GET /api/paper/:id endpoint fetches the paper's HTML5 version from arXiv, falls back to ar5iv when the primary source is unavailable, and extracts plain text with LaTeX math preserved. The GET /api/pdf/:id endpoint serves the paper's PDF. The POST /api/chat endpoint assembles the paper text and conversation history into a single prompt and streams the response back from the model. The model used is GPT-6 Luna via the openai/gpt-6-luna route on OpenRouter.

The README notes that bioRxiv blocks most servers but allows Cloudflare's network, so bioRxiv papers may fail when running a local development server.

Running a Development Server

The repository is a TypeScript project. To run it locally:

yarn

Then copy the environment template and add an OpenRouter key:

cp .dev.vars.example .dev.vars

Then start the dev server, which runs the Cloudflare Worker in the real Workers runtime:

yarn dev

To deploy, the Worker is pushed first:

yarn deploy:worker
npx wrangler secret put OPENROUTER_API_KEY

If the Worker URL changes, the /api rewrite in vercel.json must be updated before pushing to main, which triggers Vercel's build and deploy. Local bioRxiv paper fetching may fail even with the dev server running, because bioRxiv's servers block non-Cloudflare requests.

PDF Fallback and Highlighting Features

Papers without an HTML version, including new bioRxiv preprints and some arXiv submissions, open as PDFs rendered through EmbedPDF, which uses PDFium compiled to WebAssembly. The README states that highlighting and chat work on PDFs too, and that the model reads the PDF itself, including figures.

For HTML papers, selecting any passage reveals two options: Ask AI, which sends the selection as a question to the chat panel, and Explain, which requests an explanation of the selected text. Equations in the HTML version appear as MathML, and when a selected passage contains equations, those go to the chat as LaTeX.

Each paper's conversation history is stored in the browser's localStorage, so it persists across page reloads but does not sync across devices or browsers. Clearing site data for talk2arxiv.org removes the history.

Limitations and What It Does Not Do

The 800K-token ceiling is the most practical limit. Most papers are well below this, but long survey papers, preprints with extensive appendices, or multi-part documents may exceed it. The README states that these produce a clear error message, not a silent truncation.

The whole-paper context approach means that every conversation must include the full paper. There is no option to ask a question about a specific section without the rest of the paper in the prompt, and there is no way to compare two papers in a single conversation.

BioRxiv papers may fail from a local development server because bioRxiv blocks non-Cloudflare IP addresses. Developers testing bioRxiv support locally will need to deploy the Worker to Cloudflare rather than running it on localhost.

The project has no GitHub releases and no versioned packages. Updates deploy via Vercel and the Cloudflare Worker registry without explicit version tracking.

Talk2Arxiv vs. NotebookLM for Paper Reading

Google's NotebookLM accepts PDF uploads and allows questions about a document's content. The key difference is context handling: NotebookLM uses retrieval-augmented generation, selecting relevant sections to include in each prompt, while Talk2Arxiv sends the full paper text unconditionally. For papers where the relevant content for a question is scattered across sections, full-context approaches can answer more completely, while RAG approaches are bounded by what the retrieval step finds.

NotebookLM supports multiple documents in a single session and works across document types beyond PDFs. Talk2Arxiv is specialized for arXiv and bioRxiv papers and works by URL substitution, which removes the upload step for those sources but makes it inapplicable to papers from other venues.

Editorial conclusion

Talk2Arxiv is a practical tool for anyone who frequently reads arXiv or bioRxiv papers and wants to ask questions about them without setting up a local RAG pipeline. It does not work for papers longer than roughly 800K tokens, and papers without an HTML version open as PDFs with the same chat feature. The project runs entirely as a hosted web service at talk2arxiv.org, so self-hosting requires cloning the repository, obtaining an OpenRouter key, and deploying both the Vercel frontend and a Cloudflare Worker separately.

Frequently asked questions

Official sources

1. evanhu1/talk2arxiv on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README