Nine structures make updates more useful than one-shot extraction
Hyper-Extract offers 9 knowledge structures, ranging from a chunk corpus and ordinary lists to graphs, hypergraphs, and records with time or location. More importantly, it keeps track of which source contributed each fact. Re-feed a changed document under the same source name and the old contribution rolls back before the replacement is added. You can also remove a document, inspect source contributions, tag them, or limit a search to selected material. That makes the project most interesting when the document set changes after the first import.
The project includes more than 80 YAML templates across 6 domains, so you can try a biography graph or earnings-report extraction without first designing every field. Custom templates still define output fields and identifiers, which is where a serious deployment earns its accuracy. A template can constrain the shape returned by the model, but it cannot decide whether a claimed relationship is true. Hyper-Extract organizes extraction and provenance; your review process still owns the facts.
The 44-second install is easier than provider selection
Our sandbox installed 164 packages in 44 seconds and occupied 627 MB. That is reasonable for a Python extraction toolkit, although it is far beyond a tiny command-line utility. The checkout itself contained 549 files and about 37,308 lines of source in 6.4 MB. Five CI workflow files and a tests directory were present, while a Dockerfile was absent. A team wanting a container image will have to package the supported Python path itself.
Python 3.11 or newer is required. The short setup shown in the README hides a meaningful choice: extraction needs a language model with function calling, and semantic search needs embeddings. OpenAI and Bailian can fill both roles with one account. DeepSeek, Anthropic, and Google cover only the language-model side in the documented setup, so they must be paired with an OpenAI-compatible embedder. Local vLLM replaces cloud credentials with 2 model servers and GPU capacity.
What happened when we ran it
Our run at commit 85d4e05 installed in 44 seconds, built in 6 seconds, and completed tests in 36 seconds. Pytest reported 715 passed, 0 failed, and 15 skipped. Pip-audit reported 0 known vulnerabilities among the installed Python packages. Those results came from a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. They establish that the repository installs and checks cleanly in that environment.
The sandbox did not send a document to OpenAI, DeepSeek, or another hosted model because it had no credentials. It also did not start the 2 local vLLM endpoints described by the project. We therefore did not measure extraction quality, model cost, search relevance, or GPU memory. The passing suite is valuable evidence about the code at that commit, but it does not tell you whether a chosen template and model recover the facts that matter in your documents.
Version 0.10.4 exposes partial extraction instead of preventing it
Version 0.10.4 was released on September 25, 2026 after a downstream integration found 2 consequential problems. Feeding a second document into an existing hypergraph could crash because the update path referenced the wrong extractor attribute. Separately, failed chunks were converted to None and silently omitted, so a source could appear ingested while some of its text contributed nothing. The release added an extraction_failures record and CLI warnings, and fixed the incremental hypergraph path.
The default error policy remains skip. Hyper-Extract records the bad chunk and continues with the survivors; on_error="raise" stops on the first failure. That is a useful choice for exploratory research, where one malformed section should not waste the rest of a long document. It is a dangerous default for contracts, audits, or medical material if downstream code treats a completed command as complete data. Set the policy explicitly and reject any non-empty failure list before publishing results.
The MCP server has nine read and export tools
The optional MCP package exposes 9 documented tools for listing templates, inspecting a collection, searching, asking a RAG question, and exporting to Obsidian, GraphML, CSV, JSON-LD, or Cypher. The README describes that surface as read and export only. This is a sensible boundary for giving Claude Desktop or an IDE agent access to a curated collection without also granting document deletion or ingestion through the same connection.
MCP does not remove the underlying provider requirements. ask still depends on the configured retrieval and model path, and the collection must already exist. Teams should also remember that export can disclose the knowledge base even when mutation is disabled. The right permission question is who may read each source-derived fact, not only who may change it. Hyper-Extract supplies the interface; deployment policy has to supply tenant separation and access control.
September activity is strong, while the package still says alpha
GitHub showed 4,026 stars, 462 forks, and 0 open issues and pull requests when checked on September 28, 2026. The repository was pushed the same day, three days after v0.10.4. Recent merged work includes warnings for dropped chunks, safer dry-run removal, export fixes, and template-list corrections. That is active maintenance, and the empty combined queue should be read alongside the steady stream of recently closed work rather than as proof that no defects exist.
The package metadata still uses the Development Status :: 3 - Alpha classifier. That label fits the pace: releases from v0.9.0 through v0.10.4 arrived within 20 days, adding ingestion, persistence changes, exports, MCP parity, and fixes. Apache-2.0 licensing is stated in both the package metadata and LICENSE file. Try Hyper-Extract when source-aware evolution solves a real problem, then pin the release, run a second-feed test, and make partial extraction an explicit product decision.