Quivr hides the RAG inside a Brain object, but the config it hands you stops mid-line

The whole quickstart is one Brain object with no visible storage

The public surface in the quickstart is a single class, Brain, imported from the quivr_core package. The short example writes a sentence into a temporary file, calls Brain.from_files with a name and a list of file paths, and finishes with brain.ask and a question string. Nothing else is configured: no collection identifier, no embedding model, no index location, no persistence target. That is the pitch, that you focus on your product rather than the retrieval plumbing, and the shape of the code delivers it. The cost is visibility. A Brain owns its storage decisions, and once constructed you hold no handle on where the vectors went or which supplier answered, so diagnosing a bad retrieval means reaching for brain.print_info and the hosted docs rather than reading your own code. There is an examples/save_load_brain.py, which implies serialisation exists, but persistence is not part of the five-line path.

import tempfile

from quivr_core import Brain

if __name__ == "__main__":
    with tempfile.NamedTemporaryFile(mode="w", suffix=".txt") as temp_file:
        temp_file.write("Gold is a liquid of blue-like colour.")
        temp_file.flush()

        brain = Brain.from_files(
            name="test_brain",
            file_paths=[temp_file.name],
        )

        answer = brain.ask(
            "what is gold? asnwer in french"
        )
        print("answer:", answer)

The workflow YAML on the page ends in the middle of a value

The configuration section tells you to create basic_rag_workflow.yaml, copy the content in, and then shows a node graph: START, then filter_history, then rewrite, then retrieve, then generate_rag, then END. After the reranker_config key with its supplier field, the block stops in the middle of the value, at supplier: "co. Copy that and you have invalid YAML, and this file is what RetrievalConfig.from_yaml reads at the start of the chat loop. It is not a stray formatting problem either, because the same file is the entry point for every retrieval strategy the library offers. A reader with no other copy has no working configuration at all, and the page answers that gap by pointing at core.quivr.com for everything. That is the deal: the README gives you the shape of the graph and defers the working file to a site you have to be online to read.

The documented REPL prints a goodbye panel and never asks a question

Step 4 of the walkthrough builds an interactive session. It creates a rich Console, prints a fitted panel reading Ask your brain, then loops on Prompt.ask for user input. It compares the input against exit and, on that branch, prints a Goodbye panel. The snippet as given ends there. There is no call that sends the question to the Brain, no retrieval config attached to the call beyond the RetrievalConfig object built a few lines earlier, and no break out of the while loop, so what you can copy is the shell of a REPL rather than a working one. Step 5 then announces that you are all set up to talk with your brain. The distance between those two steps is exactly where your own glue has to go, which sits awkwardly next to a library whose stated advantage is that you do not write this part. The named streaming node is never referenced from Python either, so the hook the YAML implies has no visible call site.

max_history is the only number in the graph and it drives cost

Read the YAML graph as a pipeline. START hands to filter_history, which trims the conversation, which hands to rewrite, which hands to retrieve, which hands to generate_rag, and that node is the one from which the answer streams to the user before END. The single numeric setting in the whole file is max_history, set to 10, described as the maximum number of previous conversation iterations to include in the context of the answer. That is a small dial for answer quality and a large one for your bill, because every extra iteration enlarges the context the model is asked to read on each turn, and the number is global to the workflow rather than set per question. The graph is also the extension story: adding internet search or tools means inserting a node, not calling a new function, and the README frames internet search and tools as the next step once the basic pipeline works. The reranker block sits below max_history, which is the only other configuration key visible, and it is the one that gets cut off.

Three releases in six days, then nineteen months without a tag

The most recent published releases are core-0.0.33 dated 2025-02-04, core-0.0.32 dated 2025-01-31, and core-0.0.31 dated 2025-01-30, three tagged versions inside six days and nothing since. The last push to the default branch main is dated 2026-08-31, close to nineteen months after that final tag. The install line is pip install quivr-core, followed by a comment telling you to check that the installation worked, so what lands in your environment is the 0.0.33 tree unless you install from a checkout of main instead. For a library whose selling point is that you never read the retrieval code, that gap is the difference between owning the pipeline you depend on and trusting a build you cannot match to the branch you are reading about. A run of three releases in one week followed by a long silence also suggests the versioning cadence stopped rather than slowed, and the release-please configuration at the repository root shows the tagging is automated, so the absence is not a manual process being skipped.

Apache 2.0 in the README, no recognised identifier in the metadata

The License section states that the project is licensed under the Apache 2.0 License and points to the LICENSE file for details. The repository metadata GitHub exposes for this project does not resolve to a recognised licence identifier, which is what NOASSERTION records: the classifier could not categorise what it found. Both statements can hold at once, because a LICENSE file can carry Apache 2.0 text while an automated detector fails on formatting or on a file it cannot read fully. The question an adopter actually needs answered is whether the shipped LICENSE file is complete and who holds copyright, and the README reproduces neither a copyright line nor a NOTICE instruction. If you intend to redistribute something built on quivr-core inside a closed product, open the LICENSE file yourself before you build on it, because an unclassified licence in package metadata is the first thing a compliance scanner will flag and the slowest thing to argue about later.

The only model key in the walkthrough is OPENAI_API_KEY

The feature list claims any LLM and any file, and the repository description goes further, naming GPT4, Groq and Llama on the model side and PGVector and Faiss on the storage side. The walkthrough, though, sets exactly one environment variable, and it is OPENAI_API_KEY, while the YAML it shows selects no model and no vector store. The prose does say Quivr supports APIs from Anthropic, OpenAI and Mistral, and that it also supports local models using Ollama, but naming a supplier is not the same as showing the key that switches it on, and the advertised set is wider than the one the walkthrough configures. The file path is awkward too: basic_rag_workflow.yaml, a name that describes a graph, is loaded through RetrievalConfig.from_yaml, so a workflow file is parsed by a retrieval config object. Anyone swapping in a different supplier or store has to find the key names in the hosted documentation, because the example and the YAML together never show one.

Any file means any parser, and each parser is a separate example

The Any File promise is honest about its mechanism in a way that is easy to skim past: Quivr works with any file, and you can add your own parsers. The repository layout shows what that costs. Under examples/ there is pdf_parsing_tika.py, a Tika-based route into PDFs, and simple_question_megaparse.py, which pairs the retrieval with Megaparse, the separate ingestion project the README links as an integration. Two entries are directories rather than scripts, examples/quivr-whisper/ and examples/chatbot_voice/, which bring speech into the picture, and the rest are single files covering other shapes: pdf_document_from_yaml.py, save_load_brain.py, and simple_question/. Each of those routes brings its own dependency and its own setup, and the README prints an install command for exactly one package. The file types you can genuinely use are therefore the ones you have wired up yourself, and an unfamiliar format is your parser's problem rather than the library's, which is a fine design for a toolkit and a real risk if your product promises a fixed upload list.

Editorial conclusion

Quivr is worth a look if you want retrieval removed from your product's critical path and can live with a thin abstraction you cannot inspect end to end. Check three things first: that the quivr-core version you install is the one the current docs describe, given the last tag is 0.0.33 from February 2025, that the LICENSE file really holds the Apache 2.0 text the README claims, and that a complete workflow YAML exists somewhere outside the README, because the one printed there stops in the middle of a value.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes