RAG development cost in 2026: what drives the price

An internal assistant that answers 10,000 questions a month from 20,000 pages of company documents costs about $80 to $210 a month in tokens and storage. Indexing all 20,000 pages costs about 20 cents. The vector database and the model, the parts most RAG (retrieval-augmented generation) cost guides price, are the cheap parts.

The money goes into getting your documents into a state where retrieval works, enforcing who can see what, and proving the answers are right. So we price a RAG system the way we scope one: by what the data and the permissions demand.

How much does RAG development cost?

A production RAG system costs $25k–$120k to build with us, as one fixed price. We set it at the end of a two-week Discovery Sprint ($5,000) that tests retrieval on a sample of your real documents, so the quote reflects the data you have rather than a clean demo set.

Running it is the small number. The worked example below lands at about $80 to $210 a month at 10,000 queries, before hosting and monitoring.

What a RAG system is made of, and what each part costs

A RAG system has six parts. The first and the last take the most engineering; the middle ones are mostly configuration and usage fees.

RAG cost by scope

The scope of a RAG system is set by three questions: how many sources, how messy the documents are, and whether different users may see different things. Each answer pushes a project toward one row of the table below. The rows are our own placement of typical scopes inside the published $25k–$120k band, not quotes; the real number comes out of discovery once we have seen your documents.

What drives the price of a RAG system?

Six things move a RAG quote. The vector database and the model are not on the list, because they barely change the build.

Data preparation is the largest cost

Retrieval can only find what ingestion made findable. Scanned PDFs need OCR and layout-aware extraction; tables need to be kept intact rather than split mid-row; duplicate and outdated versions need to be removed or they will be cited as if current. The messier the documents, the more of the build goes here, which is why discovery tests real files.

Number of sources and how fresh they must be

Each source needs a connector, authentication and a sync schedule. Nightly batch syncs are simple; near-real-time updates need change tracking and more careful re-indexing. Five sources cost meaningfully more than one, even if the total volume of text is the same.

Permissions

If everyone can see every document, permissions are free. If a salesperson must never see HR files, every passage needs access metadata copied from its source system, and every query must be filtered by it. Getting this wrong is a data leak, so it needs its own tests. Once the assistant can also call tools, the same filtering has to cover what it may do, not only what it may read; our checklist of guardrails for agentic RAG covers those controls.

Retrieval quality

Basic vector search is quick to set up but misses exact terms such as product codes and names. Combining it with keyword search and adding a reranking step costs more to build and pays back in accuracy. In Anthropic’s published tests, contextual embeddings plus keyword search cut failed retrievals by 49%, and adding reranking took the cut to 67%. Preparing the contextualized chunks cost about $1.02 per million document tokens, once.

• Contextual embeddings plus keyword search49%
• Plus a reranking step67%

Source: Anthropic, Introducing Contextual Retrieval. Your own documents will give different numbers.

Evaluation

An evaluation set is a list of real questions with known correct answers and source passages. It is how you know a change made things better rather than worse. Building it takes time with your subject-matter experts, and it is the part most often skipped in pilots.

Hosting and compliance

Running in your own cloud, using zero-retention model endpoints or self-hosted models, keeping data in a region, and logging access for audits all add work. For regulated data, such as health or financial records, these are not optional.

Worked example: monthly RAG run cost at 10,000 queries

Here is the arithmetic for a mid-sized internal knowledge assistant, using list prices from each vendor’s pricing page.

Assumptions: 20,000 pages of documents at about 500 tokens a page, so 10 million tokens to index. 10,000 queries a month. Each query sends about 6,000 input tokens (the question, instructions and retrieved passages) and gets back about 400 output tokens.

So tokens and storage come to about $80 to $210 a month. At this size the index itself is small: 25,000 passages of 1,536-dimension vectors take roughly 0.15 GB. Add the hosting for your application and sync jobs, logging and scheduled evaluation runs, which depend on your cloud and retention rules.

The same system at 1,000 and 100,000 queries a month

Run cost scales with queries, not with the build. The per-query figures stay the same: about $0.008 on Claude Haiku 4.5 and $0.016 on Claude Sonnet 5.5 for 6,000 tokens in and 400 out.

At 1,000 queries the vector store minimum can cost more than the model, which is an argument for pgvector in a database you already run. At 100,000 the model is the bill, and routing simple questions to the smaller model is worth more than any storage choice. The corpus size barely moves either column: indexing 10 million tokens costs about 20 cents once.

Score your documents before you get a quote

You can estimate where your project lands before talking to any vendor by scoring your own documents against seven questions. Each “yes” in the middle column pushes the build price up; several together move a project from the bottom of a price band to the top.

Seven “no” answers describe the single-source assistant at the bottom of the scope table. Four or more “yes” answers usually mean the top of the band, or a first phase that leaves the hardest sources for later.

What a RAG system costs after launch

After launch, the model bill is the predictable part; the work is keeping answers right as documents, models and people change. Four recurring jobs make up most of it:

• Re-indexing changed sources, and fixing connectors when a source system changes its API or export format.
• Rerunning the evaluation set after every prompt, chunking or model change, and adding questions users asked that it missed.
• Migrating to a new model when the current one is retired or a cheaper one passes your tests.
• Auditing permissions when teams, roles or clients change, so a passage never outlives its access rule.

Our builds include a post-launch support window; after that, the work runs as small fixed-price changes or a Dedicated Team, both on the pricing page. Whoever does it, budget engineering time for these four jobs, not only tokens.

How long does a RAG project take?

A typical RAG project takes two weeks of discovery and then 6–16 weeks to build, depending on scope. A single-source assistant with clean digital documents is at the short end. Several sources, per-user permissions and scanned documents push it to the long end, or into phases.

The timeline follows the same drivers as the price:

1. 01Weeks 1–2DiscoveryOn a sample of real documents, with retrieval tested against real questions and a fixed quote at the end.
2. 02Early sprintsConnectors and ingestionIngestion and cleanup for each source, then chunking, embeddings and search.
3. 03Middle sprintsPermissions and answersPermissions, citations, the answer interface and integration with where your team works.
4. 04Final sprintsEvaluation and launchThe evaluation set run end to end, security review, load testing and launch.

What slows projects down is rarely engineering. It is waiting for access to source systems, agreeing who may see what, and finding subject-matter experts to write and check evaluation questions. Lining those up before the build starts is the single most effective way to keep the schedule.

RAG vs long context vs fine-tuning: the cost angle

RAG is not the only way to put your knowledge in front of a model, and the alternatives have different cost curves.

Long context has become a real option: Anthropic includes a one-million-token context window at standard pricing on Claude 4.6 and later models, and its retrieval research puts the cut-off for skipping RAG at roughly 500 pages (about 200,000 tokens). Past that size, every query pays for every token. Filling that window on Claude Sonnet 5.5 costs about $2 per query at list price before caching, against roughly $0.016 for the RAG query in our example, a difference of more than 100 times. For a deeper comparison of the architectures, see RAG vs fine-tuning.

• RAG query, Claude Haiku 4.5about $0.008
• RAG query, Claude Sonnet 5.5about $0.016

6,000 tokens in and 400 out, as in the worked example above. Filling the full one-million-token context on Sonnet 5.5 costs about $2 per query, 125 times the Sonnet row, too long to draw on this scale.

When an off-the-shelf tool is enough

You do not always need a custom RAG build. If your documents live in one workspace tool and its built-in AI search answers your team’s questions well enough, use it. The same applies if a document-chat product already connects to your sources, respects their permissions and keeps your data where your policies require.

Custom RAG is worth paying for when answers must come from several systems at once, when per-user permissions are strict, when documents are scans or complex tables, when the assistant must act through tools rather than only answer, or when it is part of a product you sell. If none of those apply, start with what you have. We set out a fuller decision method in build vs buy AI agents.

A real example: document intelligence in Relm

Relm, a commercial real estate platform we built, shows what the top end of the scope table involves. Its document intelligence runs OCR, extraction and vector search across rent rolls, offering memoranda, P&Ls and leases. Every finding is traceable to a source record, and tenant isolation covers the database, the vector store and the AI context, so one firm’s documents can never surface in another firm’s answers. The work that made it reliable was ingestion, citations and isolation, exactly the drivers above, not the choice of vector database.

How to keep RAG development cost down

The cheapest RAG project is a narrow one that grows on evidence.

• Start with one source and one group of users, and add sources once answers are trusted.
• Prototype on your messiest real documents in discovery, not a clean sample.
• Write fifty real questions with known answers before the build starts; they become your evaluation set.
• Use the database you already run for vectors unless scale says otherwise.
• Route simple questions to a smaller model and cache stable instructions.
• Keep regulated documents out of version one if the use case allows it.

To get a fixed price on your own documents, start with a free AI audit from our enterprise LLM and RAG team. Discovery then ends with retrieval tested on your data and a quote that does not move unless the scope does.

Related service

Enterprise LLM & RAG

Private LLM architectures, retrieval (RAG) systems and fine-tuned models that answer from your data, cite their sources and never leak it.

• Explore Enterprise LLM & RAG →
• Case study: Relm →