Hugging Face has open-sourced its Papers with Code rebuild, making the software behind the research-discovery site available for self-hosting and extension. The repository includes the web application, database schema, import workflows, maintenance tools and deployment documentation under an Apache-2.0 license.
The October 27, 2026 news concerns the codebase for a revival that was already online. Researchers can browse the hosted version at paperswithcode.co, while developers can now inspect and adapt the machinery that connects papers to code, datasets, methods and benchmark results. The repository does not specify an exact public-release time.
The most consequential detail for anyone planning to run it is in the setup instructions: a new installation starts with an empty database schema. The application code is available, but building a useful research index still involves importing papers, configuring integrations and maintaining scheduled jobs. This is a deployable research-discovery system, not a command that automatically duplicates the hosted catalog.
A Community Rebuild of Meta’s Retired Service
The repository describes the project as a recreation of the original paperswithcode.com, which Meta retired in 2025. Its hosted address, paperswithcode.co, is a separate domain. That distinction matters: this is a community rebuild maintained under Hugging Face’s GitHub organization, not Meta reopening the original service. The project README makes that lineage explicit.
The original shutdown also left a gap that a trending-papers feed could only partially fill. In a September 4, 2025 GitHub comment, user julien-c described Hugging Face’s Trending papers section as “only a partial alternative to PWC” and said Hugging Face had proposed redirecting the old domain there.
The rebuild’s public history predates this open-source update. In a May 24, 2026 community article, Niels Rogge, who identified himself as part of Hugging Face’s open-source team, said he had launched paperswithcode.co a week earlier. That post described additions including multiple metrics per benchmark, external-paper submissions and paper lineage.
Those dates separate three events that are easy to blur together: the original service’s retirement in 2025, the rebuilt website’s launch in May 2026 and the current availability of its application code.
My view is that the code release addresses a different need from simply restoring a website. A hosted service provides access while its operator maintains it. Deployment instructions and a permissively licensed codebase give other groups a way to continue, specialize or modify that work themselves. They also transfer a real maintenance burden to anyone choosing that route.
What Researchers Can Self-Host or Extend
The repository’s feature list covers much of the infrastructure needed to move from discovering a paper to locating an implementation and checking its reported results.
| Component | Documented capability | Practical use |
|---|---|---|
| Paper catalog | arXiv and external papers linked to code, project pages, Hugging Face models, datasets and Spaces | Keep research and its associated artifacts together |
| Taxonomies | Browsable tasks, methods, datasets, frameworks, conferences, organizations and authors | Explore a field through structured categories |
| Leaderboards | Paper-linked benchmark results and scheduled imports from external leaderboards | Track reported performance across papers |
| Hybrid search | Lexical retrieval using pg_trgm and semantic retrieval using pgvector | Support both text matching and meaning-based discovery |
| Public API | REST endpoints under /api/v1/, with OpenAPI documentation at /docs | Build scripts and integrations around the catalog |
| Optional research chat | An assistant grounded in the catalog through Papers with Code MCP tools | Add a conversational interface to catalog access |
| Curation automation | Scheduled imports, metadata refreshes, task and method linking, and proposed evaluations | Keep an installation updated after its initial import |
The catalog goes beyond storing titles and abstracts. The README lists thumbnails, short summaries, paper lineage and a Markdown reader alongside links to research artifacts. Taxonomies provide another route through that material: a researcher can start with a task or method instead of needing a particular paper’s name.
That structure is especially useful for a specialized research group. A lab focused on speech recognition, for example, could use the codebase as the foundation for a domain-specific catalog and adapt its import or presentation logic. That is a practical implication of having the application and curation code available, not a claim that the repository includes a ready-made configuration for every field.
The Apache-2.0 license applies to the codebase. Teams redistributing papers, datasets or other linked material should separately check the rights attached to those artifacts; the application’s license should not be treated as permission to redistribute every resource it indexes.
Hybrid Search and API Compatibility Serve Different Needs
The search implementation combines two PostgreSQL extensions. pg_trgm supports text matching based on overlapping groups of characters, while pgvector supports vector-based semantic retrieval. The repository describes the resulting paper search as hybrid lexical and semantic retrieval. Source: project README
The two approaches address different discovery problems. Text matching is useful when a researcher knows a paper title, acronym or distinctive term. Semantic retrieval can help when the query describes an idea using different wording from the paper’s metadata.
The documentation excerpt does not specify how those signals are weighted or provide an independent search-quality evaluation. I would treat hybrid retrieval as a useful design choice, then evaluate it against the queries that matter to a particular collection. Exact model names, ambiguous acronyms and broad conceptual searches can place quite different demands on the same system.
The API serves a separate audience: people who already have scripts built around Papers with Code. According to the README, the REST interface remains compatible with the original Papers with Code API client, and the application serves OpenAPI documentation at /docs.
That compatibility claim offers a potential migration path for existing research tools. It should still be checked against the endpoints and fields a workflow actually uses. Client compatibility concerns the interface; it does not guarantee that a rebuilt or self-hosted catalog contains the same records as the retired service.
This is where the empty-database detail becomes important again. A script can successfully connect to a fresh installation and still return little useful information until the relevant papers and benchmark records have been imported.
Leaderboards Need More Than a Single Score
The rebuild supports paper-linked evaluation results and scheduled synchronization of external leaderboards. Rogge’s May 24 announcement also described support for multiple metrics within one benchmark.
His examples show why that matters:
- Automatic speech recognition: the Open ASR Leaderboard could display both Word Error Rate, or WER, and Inverse Real-Time Factor, or RTFx.
- Object detection: the leaderboard could show frames per second alongside mean average precision on COCO.
Accuracy and speed answer different questions. A model with a better accuracy score may be unsuitable for a latency-sensitive application, while a fast model may miss the quality threshold a project needs. Displaying both dimensions makes the tradeoff visible.
I would consider this one of the rebuild’s more useful design details. A single ranked column is convenient for browsing, but it can hide the reason one model is preferable for a particular deployment.
The remaining work is in interpreting the records. Paper-linked results and imported leaderboard entries are reported measurements, not evidence that the catalog operator independently reran each experiment. Before comparing two entries, researchers still need to inspect the dataset, evaluation protocol, hardware and other relevant conditions in the underlying source. Automated collection makes results easier to find; it cannot make incompatible experiments comparable.
Running a Local Instance Requires More Than the Frontend
The documented stack is conventional enough for many research engineering teams to recognize:
- Frontend: React 18, TypeScript and Vite, with TanStack Query, shadcn/ui and Tailwind CSS.
- Backend: Python 3.12, FastAPI, SQLAlchemy 2 and Pydantic.
- Database: PostgreSQL 16 with the
vectorandpg_trgmextensions. - Development tools:
uv, npm, Ruff and pytest.
The local-development instructions require uv, Node.js 18 or newer, npm and PostgreSQL 16 with pgvector. The README says uv can install the required Python 3.12 version.
The setup proceeds through four main stages.
Install the Application Dependencies
Frequently Asked Questions
4 questions
1Is This Meta’s Original Papers With Code Service?
No. The repository describes it as a recreation of the service Meta retired in 2025. The rebuilt site runs at paperswithcode.co, and its code is hosted under Hugging Face’s GitHub organization.
