# QA-Pilot: three Python versions, a tracked .env, an install guide the file calls obsolete, and a provider list from 2024

> A chat interface that indexes a repository into a vector store so you can ask questions about it with a local or hosted model, with a Svelte frontend over a FastAPI backend and a Chroma store. The configuration and release history in the README are where the useful reading is.

**reid41/QA-Pilot** — QA-Pilot is an interactive chat project that leverages online/local LLM for rapid understanding and navigation of GitHub code repository.

- Repository: https://github.com/reid41/QA-Pilot
- Stars: 328 · Forks: 43
- Language: Svelte
- License: Apache-2.0
- Published: 2026-09-15 · Updated: 2026-09-15 · Language: en
- Canonical page: https://hysenlabs.com/projects/reid41-qa-pilot

## Three Python versions, one of them in the requirements file itself

The install steps tell you to create the environment like this:

```shell
conda create -n QA-Pilot python=3.10.14
conda activate QA-Pilot
```

The first comment line of the requirements file says the core runtime is Python 3.11 and newer. The note at the top of the README, the one telling you the setup has been updated, points at a deployment guide describing a tested Python 3.13 environment with LangChain 1.x.

So the file you are reading says 3.10.14, the file you are about to install says 3.11 or newer, and the file you are pointed to says 3.13 was tested. Only two of those can be right at once.

The third number is the one attached to a lock file and a service unit, which makes it the most likely to be the version the project actually runs. The 3.10 line is pinned to a patch release, which is the shape of an instruction copied from an environment that worked once rather than a floor.

This matters more than a version number usually would, because the dependency set is pinned to major versions of a package family that changed its layout between 0.x and 1.x, and the top note says the historical model SDKs are no longer required.

## The install steps are the ones the same file tells you not to follow

The note above the feature list says the runtime setup has been updated, points at the deployment guide for a tested environment with pinned dependencies, a local model setup and a service unit, and then says the older installation instructions that follow describe the original environment and that installing every historical model SDK is no longer required.

So the eighteen step procedure immediately below that note is the superseded one. It is still the only complete procedure in the file: clone, conda environment, requirements, a separate PyTorch install step with CUDA, provider setup for four different local runtimes, seven API keys, a Go compile, and a database user.

The dependency list shows what the update was about. There is no bare LangChain package at all. There are five namespaced ones, four of them on the 1.x line and one on 0.4.

That outlier is the community package, held below 0.5 while the classic, Ollama, Chroma and text splitter packages are all 1.x. A floor of 1 on four of them and a ceiling below 0.5 on the fifth is a real constraint, because the community package is where retrieval loaders live.

Everything else in the base list is ranged with a ceiling: the web framework and its server, the template engine, the upload parser, the dotenv reader, the PostgreSQL driver, GitPython, a cache library, Chroma, and four LangChain packages. No entry is pinned to an exact version, and the separately named lock file is not what the install command uses.

## An environment file is tracked at the repository root, next to the ignore rules

The root listing contains `.env`. It also contains `.gitignore`.

Those two facts sit next to an install step that says to set API keys in that same file, and then lists seven of them: one each for OpenAI, Mistral, ZhipuAI, Anthropic, Nvidia, Tongyi and Moonshot. It even shows the quoting style for each.

So the file where credentials are supposed to live is present in version control, while the ignore file that is supposed to keep it out is also present. There is no separate example file at the root, which is what you would normally expect to find instead.

It is entirely possible the tracked file holds empty values and exists so that a fresh clone has the keys present. It is also possible it holds something. Nothing in the repository as described tells you which, and there is no step telling you to create the file before you paste a key into it.

That is worth resolving before anything else, because the next step in the README tells you to copy a configuration file to a local variant that the ignore rules do cover. The project clearly knows how to keep a local file out of git, and applied it to one of its two configuration files.

## The provider list is a 2024 snapshot with a duplicated entry and a repository path as a model name

The supported models list runs to eleven providers. Two things about it are worth reading carefully.

The Mistral line names its smallest model twice, in two consecutive positions, before moving on to the small, medium, large and code variants. And the last model in that line is misspelled, missing the final letter of the word for latest.

The last provider is a local model runner, and its model list contains a bare version string that is not a model family naming convention, a full Hugging Face repository path listed as though it were a model identifier, and the word more.

The Anthropic line is the clearest evidence that this list has not been touched in a while. Every identifier in it is from 2024: the Opus, Sonnet and Haiku snapshots from February of that year and a 3.5 Sonnet from June. No later model appears anywhere in the file.

The local line has the same vintage, naming a second generation model family alongside the first.

None of this makes the feature list wrong, since an old model is still a model you can talk to, and the list is the discovery menu rather than a claim of currency. It does mean the menu cannot be used to judge whether the provider integration is current.

## The release log stops in July 2024 while the code moved for two more years

The README has a release section, and its last entry is dated 2024-07-03. The entry before that is three days earlier and the one before that is four days earlier than that.

The repository has no GitHub releases and no version field anywhere in the visible material. The last commit is 2026-09-14.

So the change log stopped twenty-six months before the last commit, and nothing in the repository replaces it. The top note about an updated runtime is the only signal that the installation story changed after July 2024, and it is a single paragraph with no date.

Reading the log in order does tell you what the project is, because the entries are dated and specific. A frontend rewrite from a Python UI framework to Svelte, a web framework swap, reranking added with a specific library, then a cascade of provider integrations: a local runner, a hosted Chinese provider, Anthropic, another local runner, two more hosted providers, and a code graph for a second language.

The order is the useful part. The graph and the upload came first, the providers came later, and the performance rewrite came in the middle. That is the shape of a feasibility project that grew outward.

## Upload limits are exact, but every change needs a new upload

The upload feature is the most precisely specified thing in the file, and it is worth reading for that reason alone.

You point at a local directory in a dialog and the files go to the server and get indexed without any Git clone. Ten extensions are accepted, and only non-empty text that decodes as UTF-8. Dependency and cache directories are skipped by name. Three limits are stated as numbers: at most two thousand source files, at most ten mebibytes per file, and at most fifty mebibytes in total.

The semantics are explicit too. Each upload creates an independent snapshot and its own session, and a local change requires a new upload. There is no incremental sync, no file watcher, and no diffing, so the fifty mebibytes is a per-snapshot budget you spend again on every iteration.

One detail in the same paragraph is a small interface wart. The same dialog holds a GitHub URL, and one button uploads the local folder you just selected while the other loads the URL. So a single panel does two unrelated jobs depending on which of two buttons you press.

Uploaded sources support chat and the code graphs for the two languages the project covers, which is a narrower capability than a clone, where any file the indexer can read is fair game.

## The second-language code graph is a loose file you compile by hand

There is a source file for the other language sitting at the repository root, next to the gitignore and the readme, with no directory of its own and no module manifest.

The install step for it is three lines of prose and two shell commands: install that language, compile the parser file to a binary, and run the binary against a test file to check it.

Three consequences. The build is a manual step with no script in the repository, so nothing regenerates the binary for you. The binary has to be rebuilt whenever the parser changes. And because there is no module manifest at the root, compiling a single file works, but the project cannot import that parser from anything else.

This is a reasonable trade for a feasibility project, since it is one file and one command. It is also the only language-specific toolchain requirement in the whole installation, and it is the one step with no automation around it.

The Python side has the opposite shape. There are four loose modules at the root, a configuration directory, a utilities directory, a templates directory, and the frontend as its own project. There is no Python package directory, so the application is run as a top level module rather than installed.

## Three requirements files, a committed model directory, and an example password in the readme

Three dependency files sit at the root. One is the base list you install. One holds the optional provider SDKs, which the top note says are no longer required. The third has a lock suffix in its name, and it is not the file the install command reads.

One documented feature has its dependency in neither of the first two. The release log records that reranking was added with a specific reranking library, and the search feature still offers an option to enable it. Nothing in the base list contains that library.

There is also a directory at the root whose entire purpose is holding model weights, and it is tracked. The settings page can upload into it, so on a running instance it accumulates files.

The database step gives you a worked example, and the example is concrete: a database name, a user name, and a literal password of six characters with a dash in it. Anyone who pastes it unchanged has a guessable credential, which is fine for a feasibility test on a laptop and worth changing the moment the host is anything else.

The disclaimer at the end of the readme says the project is a test, not production ready, and then three more lines in backticks telling you not to point models at critical data, customer data or private code. Those three lines contain the typos you would expect from text written quickly: a doubled exclamation mark on each, and a misspelling of repository in the third.

## Conclusion

QA-Pilot is worth reading if you want a reference implementation of repository question answering that keeps the model local and separates the provider you talk to from the one you embed with. Two things to sort out before you run it. Pick one Python version deliberately, because the README, the requirements file and the deployment guide each name a different one, and check what is tracked in the repository, because an environment file carrying API keys sits at the root alongside the ignore rules. The disclaimer in the README also tells you plainly that it is a feasibility test and not for production data, which is the correct framing for it.

## FAQ

### What is QA-Pilot and how does it index a repository?

It is an interactive chat interface over a code repository, using online or local models to answer questions about it. You can either give it a public GitHub URL, which it clones, or upload a local source directory, which it indexes without cloning. Indexing uses a Chroma vector store with LangChain namespace packages, and reranking is available through a separate option.

### Which Python version does QA-Pilot need?

The README does not agree with itself. The install step creates a conda environment at Python 3.10.14, the requirements file comment says the core runtime is 3.11 or newer, and the note at the top points at a deployment guide describing a tested 3.13 environment. The repository has no releases and no version field, so there is nothing else to check against.

### What are the upload limits for a local source directory in QA-Pilot?

Two thousand source files, ten mebibytes per file, and fifty mebibytes in total. Ten file extensions are accepted, only non-empty UTF-8 text, and dependency and cache directories are skipped by name. Each upload is an independent snapshot with its own session, so a local change means uploading again.

### Which LLM providers does QA-Pilot support?

Eleven, listed in the README with example model identifiers for each: Ollama, OpenAI, Mistral, a local AI runner, ZhipuAI, Anthropic, a local C++ runner, Nvidia, Tongyi, Moonshot, and another local runner. Every Anthropic identifier in the list is from 2024, and the Mistral line repeats its smallest model twice.

### Does QA-Pilot need a database?

Yes. The install step creates a PostgreSQL database and a user with a literal example password, then has you copy a configuration file to a local variant that the ignore rules cover and set the connection there. A connection check script sits at the repository root. The example credentials are meant to be changed.

## Sources

- [Issues](https://github.com/reid41/QA-Pilot/issues)
- [License: Apache-2.0](https://github.com/reid41/QA-Pilot/blob/main/LICENSE)
- [README](https://github.com/reid41/QA-Pilot/blob/main/README.md)
- [reid41/QA-Pilot on GitHub](https://github.com/reid41/QA-Pilot)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/reid41-qa-pilot