Discofork
Repository brief

zylon-ai/private-gpt

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis
cached 2026-03-31T10:03:54.477Z
1mo ago

zylon-ai/private-gpt

PrivateGPT is a widely forked Python project for privately asking questions over your documents. It exposes an OpenAI-style API with both high-level RAG workflows and lower-level primitives, and includes a Gradio UI plus scripts for model download, ingestion, and folder watching. It appears actively maintained, with recent commits in February 2026 and a large ecosystem of fork-friendly configuration files for different model and vector-store backends.

GitHub
Loading tags...
Stars57,200
Forks7,611
Default branchmain
Last pushed2026-02-26T09:56:49Z
Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

9 of 9 fork briefs
Selected

Choose this fork only if you specifically want its older Streamlit-centric app shape. For most adopters, upstream PrivateGPT is the better base because this fork is stale, deeply divergent, and likely missing major later features and fixes.

Prefer upstream unless you specifically want a reduced, older codebase with less UI and backend complexity. This fork is best for narrow, controlled use cases, not for adopters who want current features or broad integration support.

Choose this fork only if you specifically want the Memory Cache backend and can accept an old, highly diverged PrivateGPT codebase. For a general private document-QA platform, upstream is the better default because this fork is stale and likely missing substantial newer functionality.

Choose this fork only if you value its older local-install/GPU tweaks and are comfortable owning the gap to upstream. For most adopters, upstream is the safer default because this fork is materially stale and likely missing many newer capabilities.

Prefer this fork only if its early ingestion-focused changes match your needs and you want a largely frozen snapshot. For most adopters, upstream is the safer choice because this fork is stale and far behind current development.

Choose this fork only if translation-focused behavior is the main requirement and you are willing to own long-term maintenance. For most adopters, upstream is the safer choice because this fork is much older and appears to have shed or missed substantial newer functionality.

Choose this fork only if you specifically want this exact snapshot. If you want the freshest upstream docs or fixes, use upstream instead.

Prefer this fork only if you specifically need its early ingestion and local-setup tweaks and are willing to own a stale codebase. For most adopters, upstream is the safer choice because this fork is far behind and has likely lost newer features, fixes, and backend support.

Choose upstream unless you specifically need this exact frozen snapshot; the fork adds no visible functionality and is slightly behind.