Choose the cheapest practical model-optimization path before you spend on retrieval, training, or prompt refactors.
Saved only in this browser
First-month cost
Prompt $1,555.00
RAG $4,185.01; fine-tune $6,639.25 before access gating.
RAG payback
22.9 months
RAG saves $120.00 per month versus stuffed prompt context.
Scores
RAG 139
Prompt 69; fine-tune Blocked.
When to use this
Use it before choosing the architecture fix
This calculator is for teams deciding whether a better prompt is enough, whether RAG should retrieve source documents, or whether fine-tuning is worth modeling for an existing account with access.
Default result
The server-rendered support-docs example recommends RAG. RAG monthly cost is $435.00 versus $555.00 for stuffed prompt context.
Worked example: changing support docs
The default prompt-only path sends 100,000 requests with 700 base input tokens, 2,500 stuffed context tokens, and 700 output tokens. Monthly prompt cost is 320M input tokens x $0.75/1M plus 70M output tokens x $4.50/1M = $555.00.
The RAG path replaces stuffed context with 900 retrieved context tokens. Monthly RAG API cost is 160M input tokens x $0.75/1M plus 70M output tokens x $4.50/1M = $435.00. Embedding 500 documents x 800 tokens is 400,000 tokens, or 0.4M x $0.02 = $0.0080.
The vector store is 0.8 GB, so it stays below the first 1 GB storage threshold used by this OpenAI retrieval default. RAG first month is 30 x $125 setup + $435.00 API + $0.008 embedding + $0.00 storage = $4,185.01.
Fine-tuning would use 950 input tokens per request and 700 output tokens per request, so monthly inference is 95M x $0.75/1M + 70M x $4.50/1M = $386.25. First month would be 50 x $125 setup + $3.00 training + $386.25 = $6,639.25, but the default access input blocks it for new-user planning.
RAG saves $555.00 - $435.00 = $120.00 per month versus stuffed prompt context. Extra RAG setup versus prompt setup is (30 - 8) x $125 + $0.008 = $2,750.01, so payback is $2,750.01 / $120.00 = 22.9 months.
How the recommendation score works
Prompt engineering gets credit for low knowledge need, low freshness need, small scope, and fewer examples. RAG gets credit for document dependence, freshness, citations, and source-grounded answers. Fine-tuning gets credit for many examples and high format or style needs, but it is blocked unless fine-tuning access is entered as available.
Why RAG and fine-tuning solve different problems
RAG changes what context the model can read at request time. Fine-tuning changes model behavior from examples. If the problem is missing or changing knowledge, prefer retrieval. If the problem is repeated behavior, format, tone, or classification and access exists, model fine-tuning can be worth testing.
What this estimate excludes
The estimate excludes reranking, vector database read and write operations, batch discounts, cached inputs, training-data labeling, eval operations, latency cost, staff review, and compliance review. Add those lines before approving a production architecture.
What to do next
Build a small eval set, run the same questions through the prompt-only, RAG, and available fine-tune path, compare correctness and citation quality, then update the costs with real usage and vendor quotes.
Reference data used by the defaults
Topic
Reference value
Source
Date
Note
Prompt engineering guidance
OpenAI optimization guidance starts with evals and prompt engineering, including relevant context, clear instructions, and example outputs.
This calculator keeps prompt engineering as the lowest-infrastructure baseline.
Fine-tuning availability note
OpenAI states that its fine-tuning platform is winding down and is not accessible to new users, while existing fine-tuned models remain until the base model is deprecated.
Fine-tuning is therefore gated by the access input instead of assumed available.
Fine-tuning fit
OpenAI describes fine-tuning as useful for tasks such as classification, translation, specific output formats, instruction following, tone, style, summarization, and some domain reasoning methods.
The score favors fine-tuning when examples and format or style needs are high and freshness needs are low.
RAG vector storage
OpenAI retrieval docs say vector stores power semantic search and file search, and list vector store storage up to 1 GB free, then $0.10/GB/day beyond 1 GB.
Replace token prices, embedding price, and any fine-tuning price with the current model and account terms before approval.
Provider pricing, model support, fine-tuning access, training prices, and retrieval storage rules can change. Replace every commercial input with current account terms before approval.
FAQ
When should I use prompt engineering first?
Use prompt engineering first when the task is small, the knowledge is already in the user input, the format can be described clearly, and you do not need a searchable document index or training pipeline.
When is RAG the better choice?
RAG is usually better when answers depend on changing documents, internal policies, product manuals, citations, or source-grounded retrieval. It keeps knowledge outside the model and can be updated without retraining.
When does fine-tuning make sense?
Fine-tuning can make sense when you have many high-quality examples and the main need is consistent format, tone, style, classification behavior, or specialized reasoning. It is less suitable for facts that change often.
Why is fine-tuning blocked by default?
The OpenAI model optimization guide says its fine-tuning platform is winding down and not accessible to new users. The calculator still lets existing users model it by changing the access input.
Does RAG always save money?
No. RAG can reduce prompt tokens, but it adds ingestion, vector storage, retrieval operations, reranking, evaluation, and engineering work. It is strongest when it improves answer quality or avoids stuffing large context into every request.
What should I test before choosing?
Build a small eval set of real questions, score answer correctness and source grounding, compare latency and cost, and test failure cases such as stale content, missing docs, ambiguous instructions, and bad examples.
We use necessary browser storage to keep Useful Atlas working and self-hosted Plausible for cookieless aggregate statistics. Optional Google Analytics and future marketing tools stay off unless you allow them.
Necessary storage
Required for privacy choices, theme preference, security, and requested site features.
Optional Google Analytics
Used only after consent to measure visits and improve calculators, guides, and navigation.
Necessary storage
Required for core site functions and privacy preference storage.
Always on
Optional analytics
Controls Google Analytics and similar optional tools. Plausible remains cookieless and does not set tracking cookies.
Advertising and partner tracking are not active. Future advertising or affiliate tools must be added behind consent controls and documented before they are enabled.
