A $2.17 Receipt for My Personal Knowledge Chatbot

01 / Start With 46 Documents Instead of a Whole Wiki

Most personal knowledge base projects die because the author tries to capture everything. Mine survived the first month because I capped the scope at 46 files, which is roughly what I actually reread. That single decision is what made the bill small: fewer documents means fewer tokens pulled into every answer.

Before writing any code, I listed what I wanted the chatbot to know and what it should never see. The list is unglamorous, and that is the point.

• ■ Postmortems from bugs I want to stop repeating
• ■ Short decision records: what I picked, what I rejected, and why
• ■ Error messages paired with the fix that actually worked
• ■ Shell and Git one-liners I keep retyping
• ■ Local runbooks for my own side projects, ports, and build steps
• ■ Book and article notes in plain prose, one file per source

I excluded API keys, customer data, private contracts, anything with a password in it, and any note I would feel nervous pasting into a chat window. Assume the text you index will travel to a remote model. If that assumption makes you uncomfortable for a given file, do not index it.

The 46 documents total about 61,000 words. That is a weekend of tidying, not a career of documentation, and it is enough for genuinely useful recall.

02 / Splitting 61,000 Words into 240 Chunks by Hand

Chunking is where beginners overspend. A naive splitter that cuts every 500 tokens across 61,000 words produces a lot of overlapping text, and overlap is billed tokens. I split on headings first and then on paragraphs, aiming for 200 to 400 words per chunk. That gave me 240 chunks, averaging about 450 tokens each.

The rule I followed is simple and cheap:

• ■ Never split in the middle of a numbered step or a code block
• ■ Repeat the document title at the top of every chunk from that document
• ■ Keep each chunk readable on its own, because the model sees it in isolation
• ■ Cap the chunk at 500 words, and if it is longer, that is a sign the section needs two headings

Because I split at headings, the repeating title line costs maybe 12 tokens per chunk. Across 240 chunks that is under 3,000 tokens total, and it saves me from answers that confidently describe a fix that belongs to a different project. Cheap insurance.

I stored the result as one JSON file: an array of objects with an id, a title, a body, and a list of lowercase keywords. No database, no service, no monthly commitment for hosting. The file is 280 KB and it fits in memory on a ten-year-old laptop.

03 / The Receipt: 1.42M Tokens Cost Me $2.17

Here is the accounting, because the headline number should be traceable. In one month I asked the chatbot 420 questions. Each request carried the system prompt, the user question, and six retrieved chunks, and returned a typical answer of 300 to 400 words. That comes to about 1.27M input tokens and 0.15M output tokens, or 1.42M real tokens in total.

My ledger for the month reads 1.42M tokens, 2.17 US dollars. Your number will move with how much you paste into each question, but the shape stays the same: retrieval context is the dominant cost, and it is the only part you can control with file hygiene.

The reason the receipt is that small is the billing model behind it. I used CheapRelay at api.cheapapirelay.com, a pay-as-you-go relay where one key reaches Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more. Billing is per real token, and that includes cache reads and cache writes, so there is no hidden multiplier waiting at the end of the month. There is no monthly fee and no subscription, so a quiet month costs me almost nothing instead of renewing a plan I did not use. The same key works with Claude Code, Codex, Gemini CLI and any OpenAI SDK, which meant I did not rewrite anything when I switched models. If you want to try this yourself, sign up at cheapapirelay.com and fund it with the smallest amount you are comfortable experimenting with.

For model choice I kept it boring. I used Claude Haiku 4.5 for everyday recall questions and DeepSeek V4 Flash for bulk summarizing a folder of notes into chunk-ready prose. Two models, one key, one invoice line.

04 / One Request per Question, Six Chunks Inline

There is no embedding call in this system, and that is deliberate. An embedding step would mean a second model, a second billable surface, and an index I have to rebuild whenever a note changes. Instead the pipeline does the retrieval on my own machine for free, then makes exactly one billed request.

• ■ Lowercase the question and strip punctuation
• ■ Score each of the 240 chunks by how many question words appear in its keywords and title
• ■ Take the top six chunks, roughly 2,700 tokens
• ■ Send them inline with a system prompt that says to answer only from the supplied chunks and to say so when they are silent

The whole Python script is about 60 lines. The instruction to admit ignorance is the most valuable line in it. Without it the model fills gaps with plausible inventions, which is exactly the failure mode that makes a personal knowledge base worse than grep.

Asking for the answer to cite the chunk id costs a few extra output tokens and saves me from chasing phantom notes. I also turn caching on for the system prompt and the ten chunks I use most often. The relay bills cache reads and cache writes per real token, so the saving shows up as a smaller number on the receipt rather than as a mysterious credit.

05 / A Keyword Index Beats a Vector Database on a Tiny Budget

Vector search is wonderful at scale and wasteful at this size. With 240 chunks, a keyword index with simple scoring finds the right note most of the time, and when it misses, the answer is still cheap enough that I can ask again with different wording. I added two cheap tricks that paid for themselves immediately.

• ■ A synonym map of about 80 entries, so search hits on abbreviations I actually type
• ■ A boost of two points for chunks from documents I edited in the last 30 days
• ■ A hard limit of six chunks, so no single question can quietly drag in half the index
• ■ A log of every question with the chunk ids used, so I can see which notes are never retrieved

That log is how I shrank the index instead of growing it. Nine notes were never retrieved in six weeks, so I merged or deleted them. Smaller index, smaller context, smaller bill, better answers. Frugality here is not about choosing the cheapest model. It is about refusing to send text the question does not need.

06 / Three Failures From Month One and the Cheaper Fixes

The first failure was duplication. I had three notes describing the same deployment ritual, and the chatbot stitched them into a procedure that existed nowhere. Fix: one canonical note per topic, and every other note links to it by name.

The second failure was stale chunks. I edited a runbook and forgot to rebuild, so the bot served the old version for a week. Fix: rebuild the JSON index in a git pre-commit hook. It takes under a second for 240 chunks.

The third failure was cost creep from careless prompting. I was pasting entire stack traces, sometimes 4,000 tokens, for questions that needed only the last error line. Fix: trim pasted text to the last 20 lines unless I explicitly say otherwise. That single habit cut my average input by roughly 40 percent, which is most of the gap between a 4 dollar month and a 2 dollar month.

Total ongoing effort is about twenty minutes a week: add a note, prune a note, glance at the retrieval log. Total fixed cost is zero, and the marginal cost is a couple of dollars for thousands of questions. That is the whole architecture. Small enough to understand completely, cheap enough that I never think twice before asking it something.