Model or dataset
deepsense-ai/ragbits avatar
deepsense-ai/ragbits

Ragbits: a modular Python stack for prompts, retrieval and agents

Building blocks for rapid development of GenAI applications

1,667 stars143 forksPythonMIT

At a glance

What is it?
Ragbits is an MIT-licensed collection of Python packages that splits GenAI plumbing into installable pieces: prompts, LLM access, vector stores, ingestion, agents and a CLI. The interesting question is not what it does but whether its module boundaries hold up when you assemble them.
Who is it for?
Adopt Ragbits if you are already writing Python and want prompt objects, vector store adapters and ingestion pipelines as separate installable packages rather than one framework that owns your application. Skip it if you need a hosted service, a fixed orchestration graph, or a non-Python runtime.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 121 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap Ragbits targets: glue code between prompts, models and stores

Most GenAI projects start as a script and turn into a dependency problem. The prompt lives in one file, the model client in another, the vector store client in a third, and the ingestion job in a fourth that nobody wants to touch. Ragbits addresses that by shipping the plumbing as separate packages instead of a single import surface. The README describes the project as building blocks for rapid development of GenAI applications, and the package list backs that claim: ragbits-core for prompts, LLMs and vector databases, ragbits-agents for agentic systems, ragbits-document-search for retrieval and ingestion, ragbits-evaluate for evaluation, ragbits-guardrails for response safety, ragbits-chat for conversational applications, and ragbits-cli for the ragbits shell command. The intended audience is a Python team that already knows which vector store and which model provider it wants, and needs the connective tissue rather than an opinionated runtime. That is a narrower audience than the feature list suggests. If you are looking for a hosted RAG service or a drag-and-drop pipeline builder, this is a library, and you will still be writing the application.

How the pieces fit: Prompt generics, LiteLLM, vector store adapters

The mechanism visible in the README is composition through Python types. A prompt is a class that inherits from Prompt, parameterised with an input model and an output type. The quickstart defines QuestionAnswerPromptInput as a Pydantic BaseModel with a single question field, then declares QuestionAnswerPrompt(Prompt[QuestionAnswerPromptInput, str]) with system_prompt and user_prompt class attributes. The user_prompt uses Jinja-style placeholders, so the template reads Question: {{ question }}. The second type parameter is the output type, and the README points to a how-to page about configuring prompts output data type, which is where the type-safe LLM calls claim comes from: the model is asked for a structured result that matches the declared type rather than free text. Model access goes through LiteLLM, so llm = LiteLLM(model_name="gpt-4.1-nano") is the whole provider configuration in the example, and the project states that this reaches 100+ LLMs or local models. Retrieval is assembled the same way. The document search snippet instantiates LiteLLMEmbedder(model_name="text-embedding-3-small") and InMemoryVectorStore, then passes both into DocumentSearch. The vector store is an injected dependency, not a global, which is why swapping in QdrantVectorStore or PgVectorStore is a constructor change. That is the architectural bet: no hidden registry, no framework-owned client, just objects you wire together in your own entry point.

Installing only the sub-packages you need

The default install is pip install ragbits, which the README calls a starter bundle containing ragbits-core, ragbits-agents, ragbits-document-search, ragbits-evaluate, ragbits-guardrails, ragbits-chat and ragbits-cli. The README explicitly notes that you can instead install individual components by installing their respective packages, which is the reason the modular layout exists: ragbits-evaluate and ragbits-chat are not needed to run a prompt against a model. Nightly builds come from pip install ragbits --pre and follow the version format X.Y.Z.devYYYYMMDDHHMM, with an explicit warning in the README that they may be less stable than official releases. The three most recent releases listed are v1.6.0, v1.6.1 and v1.6.2, published on 2026-03-18, 2026-03-24 and 2026-03-31 respectively, so the release cadence in that window is roughly weekly. The CLI is a real surface rather than an afterthought: the README links a ragbits vector-store command for managing vector stores and a quickstart section on testing a prompt from the CLI. Document ingestion offers a choice of parser backends, Docling or Unstructured, or a custom parser, and distributed ingestion is documented as Ray-based parallel processing. Each of those choices has its own dependency footprint, which is the practical reason to install narrowly.

Where the abstraction leaks: parsers, Ray and the nightly channel

The parser choice is the clearest example of a boundary that does not fully hide its dependencies. Selecting Docling or Unstructured means pulling in whichever of those libraries you chose, and the README does not present a lightweight default for the twenty-plus formats it claims. If your corpus is plain text or HTML, the ingestion stack is more machinery than the task requires. Distributed ingestion is documented as Ray-based, which is a significant operational commitment for a team that has not already standardised on Ray; the how-to page is titled how to ingest documents in a distributed fashion, and the README does not describe a non-Ray path for the same workload. The nightly channel is the second place to be careful. The version format X.Y.Z.devYYYYMMDDHHMM means a nightly pin is effectively a timestamp, and the README's own note that nightly builds may be less stable than official releases is the only guidance given. Anyone who builds on --pre is building on a moving target. A third limitation is structural rather than technical: the README lists capabilities across agents, guardrails, evaluation and chat, but the quickstart demonstrates only prompts and a partial document search example. The material here does not let me judge how mature the agent coordination or A2A interoperability paths are, and I am not going to guess.

How Ragbits differs from LangChain and LlamaIndex

LangChain and LlamaIndex are the obvious comparisons, and the difference is in where the framework draws its edges. Both of those projects ship large, fast-moving abstractions that tend to own the run loop: chains, agents and indexes are framework objects with their own execution semantics. Ragbits, as documented here, exposes smaller pieces and leaves the loop to you. The quickstart is an asyncio.run(main()) around a prompt object and an await on llm.generate, which is plain Python control flow with no framework runner in between. The prompt class is a typed Python generic rather than a serialisable chain definition, so the contract is enforced by the type checker instead of by a runtime schema. Retrieval is a constructor argument, not a registered index. The trade-off is real in both directions. You get less magic and fewer surprises when a call fails, because the failure surfaces in your own code. You also get less for free: no prebuilt chain library, no hosted tracing UI beyond the OpenTelemetry and CLI trace handlers the README mentions, and no ecosystem of community integrations beyond what the project itself maintains. Teams that want a large catalogue of ready-made components should look at the bigger frameworks. Teams that have been burned by upgrading a framework and finding their pipeline semantics changed should look here.

Maintenance, licence and what to verify before adopting

The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the code. That is a statement about the licence identifier, not legal advice; if you vendor the packages into a commercial product, run the usual review. Maintenance signals visible in the supplied material are the release history and the repository state: the project is not archived, the last push is dated 2026-05-18, and three patch and minor releases landed within a two-week window in March 2026. That suggests active work, but it says nothing about the size of the maintainer team or how quickly issues are answered, and the material does not include a support policy or a compatibility guarantee. The upgrade cost depends on how many sub-packages you install. A project that takes only ragbits-core has a much smaller surface to re-test than one that takes ragbits-agents, ragbits-document-search and ragbits-chat together, because the latter pulls in parser backends, Ray and a chat API. Pin exact versions rather than ranges, and treat the nightly channel as something you run in a branch, not in production. The concrete first step is to install ragbits-core alone, run the quickstart with LiteLLM and InMemoryVectorStore against a real embedder, and confirm the Prompt generic actually rejects a mismatched output type at the point the README says it does. If that holds, the rest of the stack is worth assembling one package at a time.

Editorial conclusion

Adopt Ragbits if you are already writing Python and want prompt objects, vector store adapters and ingestion pipelines as separate installable packages rather than one framework that owns your application. Skip it if you need a hosted service, a fixed orchestration graph, or a non-Python runtime. Before committing, install ragbits-core alone and run the LiteLLM plus InMemoryVectorStore quickstart against a real embedder, then confirm which of the seven sub-packages your deployment actually pulls in.

Official sources

  1. deepsense-ai/ragbits on GitHub
  2. License: MIT
  3. Project website
  4. README
  5. Releases
Community notes

Community notes