How much to charge for a RAG system
How much to charge for a RAG system comes down to what the client's people stop doing once they can ask their own documents a question, and how much a wrong answer would cost them. A system that lets a support team find the right policy in seconds instead of minutes saves real hours every week, so price it against those hours. One that answers compliance or contract questions sits higher, because a wrong answer is expensive. Then price the parts that drive effort: the data, the accuracy work, and who can see what.
RAG stands for retrieval-augmented generation. The system finds the most relevant passages in the client's documents and hands them to the AI with the question, so the answer comes from their material and not from guesswork. Claude Code makes the code itself quick: the ingestion scripts, the search, the chat interface. What takes time is everything around it: getting the documents out of the client's systems, cleaning them, deciding who may see what, and testing that the answers are right. Build the quote around those.
First question: does the client even need RAG?
Ask how big the knowledge base is before you scope anything. The rule of thumb is that if a knowledge base is smaller than 200,000 tokens, about 500 pages, you can put the whole thing in the prompt and skip RAG entirely. That is a much smaller build: no search index, no chunking, no retrieval tuning.
Telling a client that is how you earn trust, not lose a sale. Quote the simple version at a lower price, and keep RAG as the upgrade for when their library outgrows it. If they have thousands of documents across several systems, RAG is the right call, and you can say so with a straight face.
Find the job before you quote
What a RAG system does for a client and what to price against
| Job | What changes for the team | Price the build against |
|---|---|---|
| Internal answers | Staff ask a question instead of searching drives and wikis | Hours spent searching per week, across the team |
| Support deflection | Agents or customers get answers from help docs and past tickets | Tickets handled faster or not opened at all |
| Onboarding | New hires ask the knowledge base instead of senior staff | Senior time freed up, and faster ramp for new people |
| Policy and contract lookups | Answers come with the source passage to check | Cost of a wrong answer, and review time saved |
| Sales enablement | Reps pull product facts and case details in seconds | Prep time per call, and deals not lost to slow answers |
Ask for the client's own numbers: how many people would use it, which questions they answer by hand today, and how long each takes. If they cannot say, measure it in a short paid discovery. Paid discovery for AI projects covers how to sell it, and client discovery questions before you quote has the questions.
The CCC RAG Quote
Six parts of a RAG system quote
| Part | What it prices | Question to ask the client |
|---|---|---|
| Sources and access | Getting documents out of drives, wikis, ticket tools or databases | Where does this knowledge live today, and who can give us access? |
| Cleaning and ingestion | Turning PDFs, scans, slides and spreadsheets into clean, searchable text | What formats are the documents in, and how many are scans? |
| Retrieval and answers | Search, ranking and answers that cite the source passage | Do people need to see where each answer came from? |
| Permissions | Making sure each person only gets answers from documents they may see | Should everyone see everything, or only what their role allows? |
| Accuracy testing | A test set of real questions with known answers, run before launch | What are the twenty questions this has to get right? |
| Keep plan | Re-syncing new documents, fixes, tuning, monitoring | How often do these documents change? |
Retrieval and answers. Price this as a fraction of one year of the value from the table above, so the client can see the system pay for itself. One clean source with everyone seeing everything sits at the low end. Several sources with role-based access sits much higher.
Sources, cleaning and permissions each get their own line. This is where RAG projects run over: a folder of scanned PDFs, a wiki nobody has tidied in years, or a security team that needs per-user access. Quote them separately so a messy data source does not quietly eat into the build.
Accuracy is a line item, not a promise
A RAG system is only as good as what it retrieves. If the search pulls the wrong passage, the AI answers confidently from the wrong source. Better retrieval methods make a real difference: in published retrieval tests, adding context to each chunk before indexing, combined with keyword search, cut failed retrievals by 49%, and adding a reranking step cut them by 67%. Each of those steps is more build work and more cost per query, so it belongs in the quote.
So never promise a percentage you have not measured. Agree on a test set with the client before you build: their real questions, with the answers they expect. Price the work to run it, report the results before launch, and tie the launch payment to passing it. That turns accuracy from an argument into a checklist.
Always quote the Keep plan
A RAG system is never finished on launch day. New documents arrive, old ones go out of date, people ask questions nobody tested, and models change. A system that answers from last year's policy is worse than no system, because people trust it.
Quote a monthly plan in the original proposal. Say what it covers: keeping documents in sync, re-running the test set after changes, and a set number of fixes. Say what it does not cover: AI usage and hosting, which are billed at cost or held by the client, plus new sources, which are quoted separately. How to price a maintenance retainer covers the structure.
How to present the RAG quote
- Lead with the job in their words. One line on what the team can now ask and get answered, then the price.
- Itemize it. Sources, cleaning, retrieval, permissions and accuracy testing, then usage and the Keep plan as separate monthly lines. Itemized quotes get trimmed, not rejected.
- Gate payments on proof. A deposit to start, a payment when the test set passes on real documents, and the final payment after the team is using it. How to structure milestone payments for an AI project covers the schedule.
- Write the scope down. Which sources, which formats, who sees what, which test questions, and whose name the AI and hosting accounts are in. How to write a statement of work for an AI project has the template.
And skip hourly. Claude Code makes the build fast, so hourly pricing turns that speed into a pay cut. Why that matters is covered in why I stopped charging hourly for AI builds.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
How much should I charge for a RAG system?
Price it on what it unlocks for the client's team: hours not spent searching documents, and wrong answers avoided. Charge a fraction of one year of that value for the build, itemize sources, cleaning, permissions and accuracy testing, bill AI usage separately, and quote a monthly plan.
Does every knowledge base need RAG?
No. If the knowledge base is smaller than about 200,000 tokens, roughly 500 pages, it can go straight into the prompt with no retrieval system. That is a smaller, cheaper build. RAG is for larger libraries.
What makes a RAG system more expensive?
Mostly the data: many sources, scanned or messy files, documents that change often, and per-user permissions. Higher accuracy targets also add cost, because better retrieval and reranking take more build work and cost more per query.
Should I guarantee accuracy for a RAG system?
Not as a percentage you have not measured. Agree on a test set of real questions with known answers, run it before launch, report the results, and tie the launch payment to passing it.
Should I charge a monthly fee for a RAG system?
Yes. Documents change, people ask new questions and models update. Quote a monthly plan for syncing documents, re-testing and fixes, with AI usage and hosting billed separately.
Last reviewed by Duncan Rogoff on October 27, 2026
