A 16-step pipeline turns one prompt into many agent jobs
Hyperresearch splits a full research run into 16 numbered stages, including query decomposition, source collection, contradiction mapping, several drafts, 4 critics, citation checking, and final edits. The entry skill loads each procedure when needed instead of putting the whole playbook into one prompt. A light tier takes fewer stages, while the dissertation tier repeats the research work by chapter. This is a workflow system for Claude Code, not a search box with a longer answer setting.
The package also makes a sound editorial choice: after synthesis, its patcher and polish roles receive Read and Edit access rather than permission to replace the report. Critical findings that cannot fit a bounded edit stay visible. The final gate checks quote integrity, retracted citations, numeric consistency, and whether sampled citations support their sentences. Those checks can catch structural mistakes, but the README says they do not guarantee factual accuracy. A person still decides which sources deserve trust.
The 250-source claim is a profile target, not outside proof
The README says its premier width sweep targets 100 to 130 sources and that later citation chasing can take the stored corpus above 250. Its benchmark graphic is described underneath as a forward-looking projection from an internal pilot, with third-party validation pending. That wording matters. Hyperresearch may collect far more material than a normal chat session, but the repository does not supply an independent result that proves its reports beat hosted research products.
Scale has a direct cost. The default full profile targets 55 to 80 sources, invokes several Sonnet and Opus roles, and may launch 8 to 12 fetchers in a wave. A budget setting tracks estimated API-equivalent spend and is supposed to block a run once the cap is crossed. Open issue 92 says completed-run spend counters can remain at zero, which would stop that guard from firing. Until that issue is resolved, watch provider billing outside the tool as well.
What happened when we ran it
Our sandbox installed commit 15010c5 in 60 seconds, pulling 140 packages and occupying 848 MB. The build completed in 7 seconds. The repository itself was much smaller: 202 files, roughly 32,940 source lines, and 2.1 MB checked out. It had 2 CI workflow files, a tests directory, and no Dockerfile. Those figures cover repository mechanics, not the cost or quality of a live research report.
The test command did not finish within our 900-second limit. Its last output showed successful progress markers through 10%, 20%, and 30%, followed by another partial row of dots. The log did not report a failing test or final total, so we cannot convert the timeout into a pass rate. Pip-audit found 1 known vulnerability in the installed environment. A 7-second build is encouraging, but the full suite remains unproven on our stated 3-CPU, 8 GB setup.
Thirteen MCP tools share a Markdown and SQLite vault
The optional MCP server exposes 13 tools for searching, reading, fetching, creating, and updating notes. The canonical copy of each note is Markdown with YAML metadata; SQLite supplies a disposable full-text index that can be rebuilt. PDFs can be saved beside extracted text, and optional embeddings add semantic search through Voyage or OpenAI. That design gives users readable files, Git-friendly changes, and an exit path if they later stop using Hyperresearch.
One advertised MCP operation needs caution. Issue 84 reproduces fetch_url returning a truthy success path while no note is created, plus a false duplicate error with a missing note ID. The report targets version 0.10.0 and commit 15010c5, the same commit our lab checked. Pull request 86 proposes a fix but is still open. Existing vault search and read tools may be useful, yet MCP-based collection should wait for that change or receive an explicit regression test locally.
The port 8080 viewer can stall behind one idle socket
The local viewer binds to port 8080 and displays notes, tags, search, and a link graph without a JavaScript build. Issue 87 gives a deterministic case where the single-threaded HTTP server accepts an idle Chrome preconnect socket and stops answering other clients. Pull request 96 remains open with a proposed responsiveness fix. Use the viewer as a local convenience, not as a shared research service, until the merged code and your browser combination pass the same idle-connection test.
Authenticated crawling has sensible limits. A visible browser can reuse logged-in sessions for sites that reject headless requests, while blocked URLs enter an escalation queue. The tool refuses to solve CAPTCHAs, logins, or two-factor prompts automatically. Open-access recovery can replace a thin publisher page with a legal copy from Unpaywall or Europe PMC, and records when the note body came from a different URL or manuscript version. Researchers still need to check quotations against the published paper.
Twenty-nine open issues and pull requests show unfinished work
GitHub listed 2,295 stars and 29 open issues and pull requests on September 11, 2026, split into 17 issues and 12 pull requests. The last repository push was August 4, while pull-request discussion continued on September 11. The latest GitHub release endpoint returned v0.9.1 from July 25, even though the checked-out package metadata says 0.10.0. That mismatch calls for pinning a commit or package version instead of assuming the release page describes main.
Hyperresearch earns a careful trial if a research team already lives in Claude Code and wants inspectable source files. Start with one bounded topic, keep provider billing visible, and verify that citations survive manual spot checks. GPT Researcher offers more provider freedom, Deep Research is easier to understand as a small implementation, and PaperQA better fits a closed scientific corpus. The 900-second test timeout makes Hyperresearch a poor choice for teams that need quick local validation before every change.