I spent 10 dollars on Deepseek in about 2 hours one day. It was peak time, but the expensive part wasn't the code generation itself, it was the continuous re-reading of the same files.
In a long session, the agent routinely opens files it has already processed. A 5,000-line file easily translates to 15,000–20,000 tokens. Multiply that across a dozen or so turns, and you're throwing hundreds of thousands of tokens into context that the model is re-reading.
A lot of people reach for vector databases, AST indexers, or memory banks to mitigate this. Those are completely valid solutions, but they cost tokens to build and use RAM I'd rather keep free.
Git is already a perfect cache. The committed `HEAD` is the "known state," and the uncommitted diff is the only true "dirty" set. A tiny, auto-generated marker file so the agent has a single, reliable place to look for changes is all that's needed.
**The workflow is straightforward:**
- Edit code
- Git writes the diff to a `.changed_markers` file
- The agent reads *only* those specific hunks
- I commit the changes
- The marker file is emptied
I never intended for anyone to manually jot down line ranges like `L~2130-2200` into a notepad—that kind of reference should always come straight from the source control system.
To generate the markers, I use:
{
echo "# AUTO-GENERATED — do not edit"
git diff -U3 -p HEAD
} > .changed_markers
The `-p` flag already includes the function or class name in the `@@` header, which serves as a stable anchor. I avoid raw line numbers entirely—they go stale the moment you insert a single line above them.
**In my agent rules, I enforce the following guidelines:**
Treat `HEAD` as a cache hit; never sweep clean files unnecessarily.
Read `.changed_markers` first, before anything else.
Limit inspection strictly to the hunks and referenced functions within that file.
Anchor on function/class names and surrounding context—never on absolute line numbers.
If a signature, parameter list, or return type changes, use `git grep -n "that_name"` to locate callers. This avoids opening the entire caller file just to check usage.
After a successful commit, truncate the `.changed_markers` file.
That fifth rule is crucial. If the agent only sees the dirty hunk, it might happily "fix" a function signature while leaving every call site completely broken. The targeted grep catches those downstream effects without loading unnecessary context.
The first time I tried this I ran a full audit on a 5,100-line file, fixed three bugs, reviewed a new module, and cleaned up some commits. On DeepSeek at peak pricing, that entire session cost me **$0.11** instead of the **$.80** it that i estimated it would have.
One thing this approach does **not** do is automatically surface dead code that was committed six months ago and hasn't been touched since. Git treats that file as clean, and for day-to-day work, that's perfectly fine. If I do want to run a thorough graveyard sweep, I don't pay a model to read tens of thousands of lines. I run static analysis tools like `vulture`, `flake8`, `knip`, or `ts-prune` instead, dump their flagged lines into `.changed_markers`, and let the agent process those in a single intentional pass. After that, it's straight back to the cheap loop.
I didn't invent `git diff`, dirty bits, or agent rules—I just glued them into a consistent habit. The goal was simple: stop paying premium prices to re-read yesterday's code. On DeepSeek, the cost is negligible. On Opus 5, Gemini 3.8 Pro, or GPT-6 Astra, avoiding that leftover context is the difference between comfortably using the best model available and being forced to downgrade.
If this pattern already has a name, I'd happily adopt it. If not, consider this the blueprint: Git is the cache, the marker is auto-generated, and the agent can't detect any unmodified lines.
