The research pipeline is configurable, but it is not a finished fact checker
GPT Researcher takes a question, creates research tasks, gathers material, keeps source references, and writes a report. The current README supports web research and local files through a Python package, FastAPI server, static interface, or a separate Next.js frontend. MCP can add specialist sources such as GitHub or a database. The supplied Claude skill puts the same research path inside Claude. That range is the reason to consider the project: you can use the research engine without adopting one fixed interface.
The output still needs editorial review. The README describes the application as experimental and explicitly declines to recommend it for academic papers. Its approach is to consult multiple sites and reduce error or bias through broader sourcing. That may improve the evidence pool, but agreement among scraped pages does not verify a claim. A production integration should retain source URLs, expose the collected material, and require a human check when the report affects money, policy, health, or publication.
The 1,026 MB environment buys many provider choices
Our checkout of commit 0957c30 contained 828 files, roughly 51,408 lines of source, and occupied 26.1 MB. Installation expanded that to 1,026 MB after 227 packages arrived. The repository includes 6 CI workflow files, a Dockerfile, a Compose file, and a tests directory. This is a substantial application with several entry points, not a small Python helper that disappears inside an existing service.
The documented basic setup requires Python 3.12 or later, an OpenAI key, and a Tavily key. GPT Researcher can point at an OpenAI-compatible endpoint, use other retrievers, read local documents, emit several report formats, and connect to MCP servers. Optional paths add more configuration: LangSmith for traces, Google for generated images, or TypeSafe for Jev filtering. Release v3.7.0 made local keyword ranking the fallback, so standard research no longer needs an embeddings provider.
What happened when we ran it
Our sandbox installed commit 0957c30 in 112 seconds and added 227 packages. The build succeeded in 112 seconds as well. We used an unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Pip-audit reported 1 known vulnerability. The measurements establish that installation and build completed; they do not measure report accuracy, search quality, model cost, or research speed.
The test command failed after 47 seconds. Pytest reported 536 passed, 21 failed, and 1 skipped out of 557. Several failures could not import get_all_retriever_names; another could not import gpt_researcher.utils.enum. Other log lines showed assertion failures in SearchAPI and Semantic Scholar cases, request-mocking errors in Serper cases, and an attribute error around a plugin retriever. Those are the results in the supplied log, and the log does not establish one shared cause.
A successful 112-second build therefore did not clear the repository for deployment. Teams evaluating it should reproduce the suite with the providers and interfaces they plan to use, then inspect the 21 failures rather than hiding them behind the 536 passes. The vulnerable package also needs identification and a project-specific risk decision. Our pip-audit result says one known vulnerability exists; it does not identify exploitability or prove an incident.
Issue 1764 makes unattended runs a risk decision
Open issue 1764 reports research jobs becoming stuck after an initial successful run, with little useful information in the command output or interface. The reporter used SearXNG and Ollama Cloud and asked for visible external-call status, timeouts, and retries. This is one user's report, not a failure from our sandbox. It is still relevant to anyone planning scheduled research, because a job that remains marked in progress needs an external timeout and an observable failure state.
Deployment also has more than one shape. Docker Compose runs the Python server on port 8000 and the React application on port 3000 by default. The README offers a lightweight frontend and a Next.js frontend, while open issue 1517 reports that a published frontend image is ARM64 and lacks the expected AMD64 variant. Confirm the exact image and architecture you will deploy instead of assuming the documented Compose path covers every cloud host.
An October 1 push shows activity, not a clean release gate
GitHub showed 29,865 stars and 21 open issues and pull requests on October 2, 2026. The repository was pushed on October 1, and recent open work included documentation and dependency pull requests. Release v3.7.0 shipped on September 26 with retriever plugins, context-filter changes, WebSocket work, and many fixes. Those dates show maintainers are shipping and reviewing changes; the combined open count should not be read as 21 confirmed bugs.
GPT Researcher earns a controlled trial when you need one codebase to cover cited reports, local documents, provider choice, MCP sources, and multiple frontends. The trial should start with the exact interface you intend to operate and a fixed set of research questions whose sources you can judge. commit 0957c30 did enough to prove the project installs and builds, but 21 failed tests are too many to wave through an automated release gate.