papercopilot/paperlists: conference paper JSON, a local search tool, and what it will not do

What papercopilot/paperlists is for

Conference paper records live in scattered places. OpenReview holds submissions and reviews, official conference sites hold accepted-paper lists, and open access sites hold whatever they have indexed. Moving between them costs time, and the record for a single paper is rarely in one spot. The README states this directly: records are "scattered, leading to fragmented information and extra effort to navigate between them." The repository's stated aim is to serve as a comprehensive link collection for major conferences, with statistical analysis built on top of those records.

The audience is narrow and specific. It is for someone who wants a machine-readable list of papers from a given venue and year, either to count things or to search titles and keywords locally. The repository is the data layer behind papercopilot.com, so if you want the rendered charts, the homepage is the destination. If you want the rows underneath the charts, this is the source. There is no stated API, no query language and no database. The unit of delivery is a JSON file per venue per year, reachable over raw.githubusercontent.com, which means the practical integration is a download plus a local script.

How the data is organised across venues and years

The top level of the repository is one directory per venue: iclr/, nips/, icml/, cvpr/, iccv/, eccv/, acl/, emnlp/, naacl/, aaai/, ijcai/, kdd/, www/, siggraph/, siggraphasia/, icra/, iros/, rss/, wacv/, uai/, colt/, corl/, aistats/, acml/, acmmm/, coling/, 3dv/, alt/, automl/, colm/, ai4x/. Inside each directory the naming pattern is the venue slug plus the year, so the ICLR directory holds iclr2025.json, iclr2024.json and so on, and the NeurIPS directory holds nips2024.json back through nips2000.json. The README's tables link each year to a raw URL on the main branch, and the same tables link a matching statistics page on papercopilot.com.

Coverage is uneven by design. ICLR files are listed for 2013 through 2025 with gaps at 2015 and 2016. NeurIPS runs from 2000 to 2024, and the statistics pages add a separate Datasets & Benchmarks breakdown for 2022, 2023 and 2024. The README does not document the JSON schema, so the only way to know which fields exist in a given file is to open it. The CLI defaults hint at the field names in use: keywords, title, primary_area and topic. That is a thin contract. If you build against these files, read one first and treat the field set as something you validate rather than assume.

Installing paperlists and running the Streamlit search tool

The README gives a clone-and-pip setup. It suggests conda as an option with Python 3.10. There is no published package, so installation means working from a checkout.

git clone https://github.com/papercopilot/paperlists.git
# use conda if needed: conda create -n papercopilot python=3.10
pip install -r requirements.txt

After the dependencies install, the web interface is a Streamlit app under tools/. Running it prints a local URL, which the README shows as http://localhost:8501.

cd paperlists/tools
streamlit run app.py

The README includes a screenshot of the interface but does not describe its filters, so the first run is exploratory: open the local URL and see which files the app offers to search. The tool is described as contributed by @hhh2210, which is worth knowing if you plan to depend on it, because it is a community addition to a data repository rather than the repository's main product.

Searching from the command line with extract.py

The second interface is a script, tools/extract.py. Its positional argument is the keyword and it is required. The three flags are -i/--input_path, defaulting to iclr2025.json; -o/--output_file, optional; and -f/--fields, defaulting to keywords title primary_area topic. The README's worked example searches for the term retrieval across the ICLR 2025 file and restricts the search to title and keywords, writing matches to results.json.

cd paperlists/tools
python extract.py retrieval -i iclr/iclr2025.json -o results.json -f title keywords

The output is a JSON file, and the input can be a single JSON file or a directory, so you can point -i at a venue folder to sweep multiple years in one call. Two things the README leaves open: whether matching is case-sensitive and whether it is substring or token based. Test with a term you know appears in a title before you trust a count. The default field list is also a design choice worth noting, since primary_area and topic are venue-specific labels and their values differ between conferences, which makes cross-venue keyword comparisons harder than a single-venue search.

Where papercopilot/paperlists stops being the right tool

The README describes the repository as a link collection. That word matters. If you need abstracts, PDFs, review scores or author affiliations, the README documents none of them, and the statistics pages on papercopilot.com are the place those numbers are presented. The files here are the records the statistics are computed from, not a substitute for the analysis.

There is no versioning to pin against. No releases were retrieved for this repository, so there are no tags or changelogs. Files are served from the main branch at raw URLs, which means a file can change under you between two downloads with nothing in the URL to signal it. Anyone building a reproducible pipeline should fetch the JSON once, store it, and record the fetch date rather than pulling the raw URL on every run.

Coverage gaps are real. The README lists no ICLR file for 2015 or 2016, and NeurIPS statistics links are absent for some years even where JSON exists. A venue that is not in the top-level directory list simply is not covered. Finally, the repository is Python, but the data is plain JSON, so the language matters only if you use the bundled tools; a reader in another language can consume the files directly and ignore requirements.txt entirely.

Alternatives: OpenReview, DBLP and the papercopilot.com statistics pages

The obvious alternative is OpenReview, which the README names as one of the sources the records are combined from. The difference is one of role. OpenReview is a submission and review platform: it holds the live record for a venue, including reviews and decisions, and its API reflects that. papercopilot/paperlists is a derived, cleaned snapshot oriented toward listing and counting. If you need review text or decision status, go to OpenReview. If you need a flat per-year file you can grep, the snapshot is less work.

DBLP is the other common stopping point for publication lists, and the distinction is scope. DBLP is a bibliographic index across venues and years with author disambiguation as a core concern. papercopilot/paperlists is conference-centric, with one directory per venue and one file per year, and the README makes no claim about author identity resolution. For a per-conference analysis of what was submitted or accepted in a given year, the per-venue file layout is more direct; for author-level or cross-disciplinary bibliometrics, a bibliographic index is the better fit.

The third option is papercopilot.com itself. The README pairs every JSON link with a statistics page, and the site is where the data is presented as charts for ICLR, NeurIPS and the other venues. If your question is "what did the acceptance rate do this year," the statistics page answers it without a clone. The repository is for the case where the chart is not the answer you need and you want the rows.

Maintenance, licensing and upgrade cost

The last push to the default branch was on 2026-07-01. The repository is not archived. That is a data-refresh cadence rather than a software release cadence, and the two are not the same thing: new JSON files for a conference year can appear without any change to tools/, and a change to tools/ can land without any new data. Because no releases were retrieved, there is no tagged version to upgrade to and no migration notes to read. Upgrading means pulling the branch and re-reading the scripts.

The license is unknown. The repository's licence field is empty and the README does not state terms, so redistribution of the JSON files, or of anything derived from them, rests on terms this material does not establish. The README also credits a contributor for the search tool, which points to mixed authorship across the repository. If you plan to republish the data or embed it in a product, resolve the licensing question with the maintainers before you build on it; that is a factual gap here, not a legal opinion.

The practical upgrade cost is low for consumers of the JSON, since a new year is a new file and your existing parser either handles it or fails loudly on the first record. It is higher for anyone who has customised tools/extract.py, because there is no version boundary between your changes and upstream ones.

Editorial conclusion

Adopt papercopilot/paperlists if you need per-year conference paper records as JSON and want to grep them locally without scraping OpenReview yourself; the repository layout covers ICLR, NeurIPS, ICML, CVPR, ICCV, ECCV, ACL, EMNLP, NAACL, AAAI, IJCAI, KDD, WWW, SIGGRAPH, ICRA, IROS, RSS and more. Do not adopt it if you need abstracts, full texts or a stable versioned API, because the README documents none of those and no release has been published. Verify first that the specific year and venue you care about has a JSON file on the default branch, and check whether the fields your pipeline needs (keywords, title, primary_area, topic) are actually populated in that file, since the README does not describe the schema.

Frequently asked questions

Official sources

1. Issues
2. papercopilot/paperlists on GitHub
3. Project website
4. README