Shape the Note Before You Send It: A Unix-Style `grep | trim | feed` for AI Prompts

Before any LLM call, run the input through a four-step shape — inspect what you have, trim what the model does not need, preview what is left, and only then send. Plain markdown is the easiest possible input to shape: a stream of bytes you can grep, wc, and head before it crosses the wire.

The reason this matters now is that the bill is the shape. Anthropic's Applied AI team — Prithvi Rajasekaran, Ethan Dixon, Carly Ryan, and Jeremy Hadfield — wrote in September 2025 that context engineering is "the art and science of curating what will go into the limited context window from that constantly evolving universe of possible information," and that "every new token introduced depletes this budget by some amount, increasing the need to carefully curate the tokens available to the LLM"¹². The same week the essay was indexed on Hacker News, a CLI named Lowfat — author handle zdk — went front-page with a single-line summary the developer audience grokked instantly: "agents don't need the full kubectl get -o yaml or any 10k-line dump to make decisions"³. Two voices, one thesis. The shape of the input is the part you can change.

What "shape the input" actually means

A prompt has a shape — the literal sequence of bytes you hand the model — and a bill, measured in tokens. Shape is upstream of bill. The four-step discipline is inspect → trim → preview → send: look at the file you are about to attach, drop the lines the model does not need to answer the question, look again at what is left, and only then make the call. The discipline is identical whether the input is a 200-line markdown note, a git diff, or the JSON dump of a Kubernetes pod.

The framing is not new. Doug McIlroy, writing the foreword of the Bell System Technical Journal's UNIX issue in July-August 1978, put down what is still the operating instruction for any pipeline that has to fit a fixed budget: "Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new 'features.'"⁴ The 1978 budget was a teletype and a few kilobytes of memory; the 2026 budget is a 200K-token context window and a metered per-MTok price list. The constraint changed; the response did not. The pipeline tools that survived — grep, head, wc, sed, cat — survived because they each do one thing well and compose into a single line that prepares a stream for whatever consumes it next.

The 2026 consumer is the model. Anthropic's Applied AI team named the discipline directly: context engineering "is the art and science of curating what will go into the limited context window from that constantly evolving universe of possible information"¹. The word that matters there is curating. The model is not a search engine that figures out what is relevant — it reads whatever you send. The byte count you send is the byte count it pays attention to (and the byte count you are billed for).

The bill is the budget — and the budget is small

LLM prices have fallen, and they will keep falling. They have not fallen to zero. Simon Willison's December 2024 retrospective on the year in models is the longest-running named voice on per-token pricing, and the line is blunt: "LLM prices crashed, thanks to competition and increased efficiency"⁵. The collapse was real — Willison reported one path "200x cheaper than GPT-4, nearly 7x cheaper than GPT-3.5" by the end of 2024 alone⁵. A 200× price cut sounds like the bill stops being the constraint; it is the opposite. The cheaper a token is, the more tokens you send, and the bill is back to where it was.

The vendors agree there is a budget. Anthropic's pricing page documents two discounts that exist precisely because the per-token line is not free. A prompt-cache hit "costs 10% of the standard input price" — the cache pays off "after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)"⁶. The Batch API "allows asynchronous processing of large volumes of requests with a 50% discount on both input and output tokens"⁶. OpenAI's Batch documentation describes the same shape — a "50% cost discount" against synchronous pricing⁷. The discounts only matter to people who already measured the bill. The first measurement is the byte count of the prompt.

The deeper budget is not the dollar — it is the attention. Anthropic's Applied AI team write that "every new token introduced depletes this budget by some amount, increasing the need to carefully curate the tokens available to the LLM"². The "depletion" is not a financial metaphor. Models lose track of facts buried in long contexts; the longer the prompt, the more the model has to ignore to find the question. Trimming the bytes is the same operation as sharpening the question.

What shaping actually buys you (the receipts)

The clearest receipts come from a tool that does exactly one thing: trim the output of common commands so an agent does not drown in noise. Lowfat — Apache-2.0, single binary, zdk/lowfat on GitHub — publishes a "Levels" table in its README that measures the reduction in tokens between the raw output of a command and the trimmed output at three levels: lite, full, and ultra. The numbers below are from the project's v0.8.0 release on 2026-06-19, read directly off the README⁸:

Three observations. First, the reductions are not uniform across commands or levels — git status shows lite and full at the same -62%, which means the trim discipline does not always have more to give. Second, the ultra column on git diff is the headline number that makes the post — a 96% reduction in the bytes the model has to read in order to answer "what changed in this commit." Third, and most important, these are single-command numbers on bundled samples, not a promise about a project's monthly bill. The author says so himself, twice in the same README section.

The load-bearing caveat is the author's own. Lowfat's README, immediately under the percentage table, reads: "These percentages are the reduction of a single command's output, not your end-to-end agent token usage."⁹ And again, in the next sentence: "savings depend on how much of your context is command output and how lossy a level you pick — higher levels drop more, so verify your agent still has what it needs."¹⁰ We are repeating those two lines verbatim because the temptation to read the table as "Lowfat will cut your bill by 96%" is the exact misreading the author wrote them to prevent. The ultra column also drops information; some of what it drops, your agent will need.

The HN reception was the same shape. Lowfat's "Show HN" landed on 2026-06-05 at 156 points and 80 comments, with the title "Show HN: Lowfat — pluggable CLI filter that saved 91.8% of my LLM tokens"¹¹. The headline 91.8% is a personal two-month sample from the author's own agent workload, not a benchmark and not a claim about anyone else's project. The submission's standing-up move is the one-liner from the author that everyone reading the thread quoted back: "agents don't need the full kubectl get -o yaml or any 10k-line dump to make decisions"³. The villain is the shape — paste-the-whole-dump and let the model figure it out — not any specific tool.

The four-step shape, in five minutes

The smallest version that does real work is four shell tools and a habit. The folder is the source; the tools inspect, trim, and preview; the model is the only thing in the loop that costs per byte. The pipeline is a single line you can type from memory.

1. Inspect. Run wc -l -w your-note.md and head -20 your-note.md. The line count and the first twenty lines tell you, before any model call, what you are about to send. If the file is 4,000 lines and your question is about the third H2, you already know most of those lines are not the answer.
2. Trim. Pipe the file through rg (ripgrep) to pull only the lines that mention what you are asking about. The pattern is: rg -n -A 5 -B 2 -w 'topic' your-note.md. The -A 5 and -B 2 flags keep five lines of trailing context and two of leading context — enough to read a paragraph in context, not enough to ship the whole file. The -w enforces whole-word matches so "PTO" does not also pull every "potato".
3. Preview. Run the same pipeline through wc -c and read what you have on screen. If wc -c returns more bytes than the question can possibly need, tighten the regex or cut the -A/-B window. If the model's context window is 200K tokens, the budget is hardly the immediate constraint — the attention budget is, and a focused prompt outperforms a long one on the same content.
4. Send. Paste the trimmed output into the chat client you already use, with one prompt: "Here are the relevant lines from my notes. Answer my question using only these lines; tell me if the lines do not contain the answer." Then ask the question. The "tell me if not" clause is the cheap insurance that prevents the model from filling in the trimmed-away parts from its training data.

That is the pipeline. The folder is the source; rg is the trimmer; the pipe is the preview; the model is the reasoner. The four steps fit on one terminal line: rg -n -A 5 -B 2 -w 'topic' your-note.md | wc -c && rg -n -A 5 -B 2 -w 'topic' your-note.md | head -80. When the model answers wrong, you can open the file at the line number rg printed and read the original — the failure mode is legible by construction. This is the prep-side companion to the read-side argument in grep beats RAG when your vault is small: once you have grepped the matches, this is what you do to them before you send.

The thirty-minute version

The thirty-minute upgrade is the same loop with three additions — a saved prompt, a trim function in your shell, and the habit of writing summary lines into the file the regex will find. Each is a one-time cost that widens the trim's reach without adding a dependency. None of the three require a new tool; all three pay out every time you press send.

The first addition is to save the "Here are the relevant lines from my notes…" prompt as a plain text file at the root of your notes folder. Name it prompt-prefix.md. The trim pipeline becomes one line: cat prompt-prefix.md && rg -n -A 5 -B 2 -w "$1" ~/notes. Wrap it in a shell function — ask_notes() { cat ~/notes/prompt-prefix.md && rg -n -A 5 -B 2 -w "$1" ~/notes; } — and the prompt is one keystroke away. The discipline is now mechanical.

The second addition is to let the model widen the regex on its own when the first trim returns too little. After the initial rg returns three lines, pass the question to the model with the prompt: "These are the only matches I have. If you need more context, suggest three additional search terms — synonyms, abbreviations, or related verbs — and I will run them." This is the same agentic-retrieval loop that Anthropic's Applied AI team describe as curating the context window across turns¹. The model decides what to look at next; the file stays where it is; the trim runs again. Nothing about this requires building a vector index.

The third addition is to write the vocabulary you actually search by into the notes themselves. If you write vacation everywhere and your future query says PTO, add the parenthetical (PTO) next to the first occurrence in the note. The regex can then find both. A note that lists its own synonyms is its own retrieval index — the cheapest possible index, and the one that will outlive every retrieval architecture you try. Steph Ango, writing on his personal site, put the principle behind the practice in one sentence: "apps are ephemeral, but your files have a chance to last"¹². The synonyms you write into the file last as long as the file does.

Common mistakes

Five common mistakes account for almost every "I trimmed the prompt and the answer got worse" story — over-trimming the context, conflating a single-command percentage with an end-to-end bill, treating a percentage as a promise, paying for the cache without measuring the cache, and reaching for a vector index for a corpus that does not need one. Each is a one-line fix.

• Over-trimming the context. If rg -A 0 -B 0 returned the line "the API requires a token", the model has the fact but not the contract — the lines before and after that one explain which token, where to put it, and what it expires after. Pick a -A/-B window that captures a paragraph, not a line. The Lowfat README's own caveat is identical in shape: "higher levels drop more, so verify your agent still has what it needs"¹⁰.
• Conflating a single-command percentage with an end-to-end bill. Saying "Lowfat saves 96% on git diff" is true; saying "Lowfat will cut my bill by 96%" is a misreading of the same table. The author flags this twice on the same page: "These percentages are the reduction of a single command's output, not your end-to-end agent token usage"⁹. The end-to-end bill depends on what fraction of your context is command output in the first place.
• Treating a percentage as a promise. The 91.8% number in Lowfat's HN title is the author's personal two-month sample on his own agent workload¹¹. Your workload is different; your percentage will be different. Measure your own bill before and after — the discounts on Anthropic's pricing page and OpenAI's Batch API⁶⁷ only apply on top of a number you actually have.
• Paying for the cache without measuring the cache. Prompt caching is a real lever — a cache hit "costs 10% of the standard input price" — but the line in the docs is more specific than that: it "pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)"⁶. If your prompt never hits twice in the cache window, the cache write is overhead, not savings.
• Reaching for a vector index when grep is the right tool. Vector retrieval is a real architecture and the right answer at scale. For a personal vault under about a million words and known-vocabulary queries, a regex over plain files beats a vector database on cost, latency, and the one thing that matters most when retrieval misbehaves — being able to read why it returned what it did. The trim discipline in this post runs on whatever your retrieval step returns; it does not require — or recommend — embeddings to do its job.

The villain in every one of these is the same — the shape of "paste it all and let the model figure it out", not any specific vendor or tool. Lowfat, Anthropic, OpenAI, Smooth, PageIndex, rtk — every name in this post is a receipt for the thesis, not a target for it. The shape is the target.

Two more tools, two more receipts

Two adjacent tools document the same thesis at the level of the agent's whole round-trip, and they are worth naming for the cross-reference even if you never install them. Smooth is a browser built for AI agents to drive; its on-page tagline reads, verbatim from the docs overview: "Give your AI agent a browser that actually works"¹³. The "Show HN" framing that put it on the front page in February 2026 — 109 points on 2026-02-05 — was "Token-efficient browser for AI agents"¹⁴. The framing is the same one Lowfat takes on the shell side: the agent's input is too large by default; the right place to fix it is upstream of the model, in the tool that produces the bytes.

PageIndex documents the architectural version of the same idea. The repo's README — VectifyAI/PageIndex, posted to HN at 192 points on 2025-08-27 — describes itself as "a vectorless, reasoning-based RAG system that builds a hierarchical tree index from long documents, and uses LLMs to reason over that index for agentic, context-aware retrieval. The retrieval is traceable and explainable, with no vector DBs or chunking"¹⁵. Vectorless and no chunking are doing real work in that sentence: the design choice is to ship the model a map of the document and let it ask for the parts it wants, rather than ship it pre-cut chunks. The shape is upstream; the model curates.

The synthesis is the headline of the trend essay that landed on HN at 187 points on 2026-06-28: "Tokenmaxxing is dead, but we haven't seen the last of tokenmaxxing just yet"¹⁶. Maximizing tokens for the sake of it is over. Curating tokens — the inspect/trim/preview/send shape — is the part of tokenmaxxing that remains, because the bill and the attention budget have not gone away.

How this fits with MNMNOTE

The substrate is the point. The file MNMNOTE's editor saves is a plain .md file — a stream of bytes that head, grep, wc, sed, and cat can read directly, with no proprietary wrapper to unwrap first. The trim pipeline in this post operates on the file the editor wrote; the model receives only the lines you choose. There is no second store and no third party in the loop you did not put there. Notes stay on your device; the bytes you decide to attach to a prompt are the bytes that go to the AI provider you have chosen — the egress decision and the trim decision are the same decision, made once, in writing.

The architecture the discipline assumes is the architecture markdown gives you for free. McIlroy's 1978 rule — "make each program do one thing well" — is the same rule the trim pipeline above runs on: wc counts, rg filters, head previews, the model reasons. None of the tools know about the others; the pipe is the contract. The file outlasts every model, every editor, and every retrieval architecture you try. That is the part of the system worth designing for.

Frequently asked questions

These six questions are the verbatim shapes of what people search before they reach for a longer prompt or a bigger model. The answers are short on purpose — the long forms live above. Each one names the bound, the source, and the moment the next step begins.

How do I reduce LLM token costs? Trim what you send before you send it. The four-step shape is inspect → trim → preview → send: wc -l, then rg -n -A 5 -B 2 -w 'topic', then re-inspect, then paste. The vendor discounts that follow — Anthropic's cached-input price at 10% of the standard input price, the Batch API at a 50% discount on input and output, OpenAI's Batch API at a 50% cost discount — are real, but they only apply on top of a token count you have actually measured⁶⁷.

How do I filter context before sending it to an AI? Use rg (ripgrep) with -n -A N -B N -w to pull only the relevant lines and a few lines of context around them, then pipe through wc -c to confirm the byte count before pasting. The pattern is rg -n -A 5 -B 2 -w 'topic' your-note.md | wc -c && rg -n -A 5 -B 2 -w 'topic' your-note.md | head -80. The -A/-B window is the dial that trades context for cost — pick a paragraph-sized window, not a line.

What is tokenmaxxing? A 2025-into-2026 framing for maximizing what a model does per token of context, named in the HN-front-page essay "Tokenmaxxing is dead, but we haven't seen the last of tokenmaxxing just yet" by the author writing as theahura, posted on 2026-06-27 and surfaced on HN at 187 points on 2026-06-28¹⁶. The current direction is curating tokens — the inspect/trim/preview/send discipline — rather than stuffing the context window for its own sake.

Is RAG worth it for a small corpus? Usually no — for a personal vault under about a million words, a regex over the folder plus the model you already use is on the Pareto frontier on cost, latency, and debuggability. The full argument is in grep beats RAG when your vault is small. The trim discipline in this post applies after whatever retrieval step you choose — it does not require, and does not recommend, building a vector index over a small personal corpus.

How does prompt caching pricing work on Anthropic? A cache hit "costs 10% of the standard input price"; the cache "pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)"⁶. The Batch API is a separate lever — "a 50% discount on both input and output tokens" for asynchronous workloads⁶. The cache only pays off when the same prefix is read repeatedly within the cache window; measure how often that happens in your workload before assuming the discount applies.

Do Lowfat's percentages mean my bill will drop by that much? No — the author flags this twice in the README. "These percentages are the reduction of a single command's output, not your end-to-end agent token usage"⁹. The numbers in the Levels table — git diff -16% / -38% / -96%, git log -53% / -80% / -91%, git status -62% / -62% / -74% — are reductions on individual command outputs at three trim levels⁸. How much your end-to-end bill moves depends on what fraction of your context is command output and on how much information the higher levels drop that your agent actually needs.

The first prompt-engineering decision is not the prompt. It is the shape of the bytes that reach the prompt. Inspect the file. Trim the noise. Preview what is left. Then send. The discipline is older than the model and older than the bill; it is the same one McIlroy wrote down in 1978, and it is the same one Anthropic's Applied AI team rediscovered, in the same words, in 2025. The credit on the modern receipts belongs to zdk for the working tool⁸, to Rajasekaran, Dixon, Ryan, and Hadfield for the rediscovery¹, to Simon Willison for the longest-running honest record of the price line⁵, to Steph Ango for the file-philosophy ally¹², and to McIlroy, Pinson, and Tague for the 1978 foreword that started it⁴.

The substrate is the plain file. The discipline is the shape you give it before it leaves your machine. The plain file lives at mnmnote.com.