37,945,352 Cache Reads Before We Could Name the Question

One AI session burned through 365,257 output tokens and 37,945,352 cache reads, which are bits of earlier text pulled back into the conversation. None of our rules for avoiding that had a chance to fire. Those rules were to search inside files before reading them, clear old conversations between tasks, and send side searches elsewhere. They all assume we know what we are looking for, and during an audit of session notes and instruction files we did not.

A token is a small piece of text that an AI counts, and the meter runs on them. That one session used a meaningful slice of the quota we had for the week.

It stung because we already had the rules. We had told ourselves to search inside files before reading them whole. We had told ourselves to clear out old conversations between tasks. We had told ourselves to send side searches elsewhere so the main conversation would stay tidy. They were good rules, and they worked when we knew what we needed.

The afternoon the rules stopped working

That afternoon was an audit. We were reading session notes and instruction files, comparing results, and revising a small script. We did not know the problem at the beginning. We had to look around before we could even name the right question.

You cannot search first when you have not yet learned what needs finding. So we kept reading, comparing, and trying another angle, and the count kept climbing. The limit on our usage was real, but our strategy was wrong for that kind of work.

We tested RTK. It is a proxy, a small go-between that looks at what ordinary computer tools send to the AI before the AI has to read it. A clean status check can become a short summary. A test run can hide the long list of passing tests and show only the failures. A file comparison can lose the surrounding lines that rarely affect the decision.

We were not looking for a trick that would make every task cheaper.

The most reassuring part was what happened when the tool did not recognize a command. It left the result alone. No broken command, no mangled answer, just the full output. That matters because the danger of a new habit is often the moment it gets in the way. Here, the worst case was no savings.

We added one simple instruction to use the filter before routine computer tools. It is still a habit, and habits can be missed. But once it is used, the tool does the shortening itself. It does not depend on us remembering a list of careful behaviors in the exact moment those behaviors are hardest to follow.

What we have not proved

We do not know what this saves across a normal week. The tidy percentages came from test runs and other routine output, where the filter has the most noise to strip. The audit session is the opposite case. It was mostly us reading large files and comparing results, so our guess is that the filter saves less there.

Even so, that session put 365,257 output tokens and 37,945,352 cache reads on the meter before we could name our question, and no rule of ours could have searched first for something we had not found yet. The filter does not need us to know what we are looking for. It shortens the status checks and passing-test lists on the way in, and when it does not recognize a command it hands back the full output, so its worst case is the same bill we already paid.

If your AI usage depends on people remembering careful habits, check whether a filter could do the shortening for you instead. Ours returns the full output whenever it does not recognize a command.

dxdev LESSON · paste into your AI coding agent
LESSON: A discipline that depends on remembering to apply it breaks during exploratory work
SOURCE: dxdev.com/everyday-ai/rule-i-forgot-when-i-needed-it
WHAT HAPPENED: Rules like "search inside files before reading them whole" and "clear old conversations between tasks" worked reliably for known-target tasks, but broke down during an open-ended audit where the right question wasn't known at the start, since you cannot search first when you haven't yet learned what needs finding. That afternoon produced 365,257 output tokens and 37,945,352 cache reads. Testing a proxy tool that filters verbose output, such as test runs and diffs, before it reaches the model, with a documented fallback of passing output through unfiltered when it doesn't recognize a command, gave a guardrail that worked without requiring the operator to remember discipline in the exact moment memory is weakest.
THE RULE: A discipline that depends on remembering to apply it in the exact moment memory is weakest, mid-exploration, tired, moving fast, will fail. Prefer a mechanism that enforces the saving automatically, with a safe no-op fallback when it doesn't recognize the input, over a rule that depends on the person.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any token or cost-discipline rule stated as a habit or reminder rather than enforced by a wrapper or tool that applies automatically.
  2. Any output-filtering tool integrated into a workflow without a verified safe-fallback behavior when it encounters an unrecognized command.
  3. Any exploratory or audit-style task flagged as an exception to normal search-before-read discipline, without a specific alternative strategy defined for that case.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.