$2 for a Small RAG App, With a Stop at $1.90

01 / Give the app $1.90 of a $2 budget

A small retrieval augmented generation app can answer questions about your own documents without sending every document to a model. It retrieves relevant passages, adds them to a prompt, and asks for an answer grounded in those passages. For a first version, use ten short text files, local search, and one paid generation request per question.

Set a $2 total spending ceiling for this experiment. Let the app allocate only $1.90, leaving $0.10 untouched as a buffer. These are your budget rules, not a claim about how many answers any provider will deliver.

The important distinction: an application ledger controls requests made through that application. It cannot cap spending from another script sharing your credentials. A provider-enforced spending limit, if available, adds protection. Do not assume that a balance alert blocks requests.

02 / Retrieve passages locally before paying for generation

Start with Python, SQLite, and a folder of plain text documents. SQLite's FTS5 extension provides local full-text search. Confirm that your Python installation supports it before continuing. This version needs no paid embedding calls or hosted vector database.

• ■ Split each document into passages of roughly 200 to 300 words, preferably at paragraph boundaries.
• ■ Store each passage with its filename and a stable identifier, such as handbook-007.
• ■ Search the passages using terms from the reader's question, then select the three highest-ranked matches.
• ■ If nothing matches, return “No relevant passage found” locally and spend nothing.

This is keyword retrieval, so synonyms and unfamiliar wording can cause misses. For ten documents, inspecting the matches is a useful first test. Add paid retrieval infrastructure only after you identify a problem that requires it.

03 / Make the $0.01 request allowance a real gate

Before connecting an API, create a ledger with a $1.90 available balance. Each attempted generation must reserve $0.01 before the network request begins. With no refunds to the ledger, that permits at most 190 attempts. Failed requests also consume their reservation, making the accounting conservative.

A reservation is safe only when the maximum possible billed cost of that request is at most $0.01. Calculate that bound using verified prices, the complete input token count, and an enforced output limit. Include every billable category, including cache reads, cache writes, and any reasoning tokens the selected endpoint charges for. If you cannot bound those charges, block the request.

For arithmetic practice only, suppose input costs $1 per million tokens and output costs $4 per million. A maximum of 3,000 input tokens and 400 output tokens would cost $0.0046. Those are hypothetical rates, not CheapRelay prices. Substitute current rates and check how the endpoint applies its output limit before using this calculation.

Count the instructions, question, retrieved passages, and message overhead. Use supported token-counting methods; a word count is insufficient for enforcement. Trim passages until the complete request fits the verified allowance.

04 / Connect one endpoint and keep the answer bounded

CheapRelay offers pay-as-you-go access through an OpenAI-compatible API at https://api.cheapapirelay.com/v1, with no monthly fee or subscription. Billing follows real token usage, including cache reads and writes. Sign up for CheapRelay, then check the chosen model's current pricing, API identifier, and supported limits before funding this experiment.

Keep the API key on your server. Configure an OpenAI SDK with that base URL, choose one available model, and send only the question and selected passages. Ask the model to cite passage identifiers, treat retrieved text as evidence rather than instructions, and say when the evidence is insufficient. Enforce the output limit through the API parameter, not just the prompt.

05 / Prove the stop works before spending the allowance

Make the balance check and reservation one atomic SQLite transaction so simultaneous requests cannot spend the same remaining cent. Keep reservations after timeouts or crashes because a missing response does not prove that processing was free. Disable automatic SDK retries and avoid adding tools or follow-up generation calls.

Test locally with a fake API response: insufficient balance must prevent any network call, and two simultaneous requests must not overspend the ledger. Then make one small live request and compare its reported usage and billing with your bound. If the numbers disagree, stop and correct the calculation before accepting more questions.