Context Window Optimization
Case Study

My AI coding sessions were dying after an hour. I was sitting down to build out a dashboard or refactor a pipeline, and by the time I actually got into the flow state, the model would start refusing requests. The context window was full. The session was stalled.

I found myself constantly restarting sessions, copying over the half-finished code, and trying to re-explain the architectural context to a fresh agent. It was exhausting. It felt like trying to write a novel on a typewriter that runs out of ink every three pages.

We treat AI as magic, but it is just infrastructure. And like any infrastructure, when it breaks down, you need to profile it. I had no visibility into what was consuming the budget. But I knew that a 200,000 token context window shouldn't be exhausted by an hour of editing React components and Python scripts. Something was eating the context before the real work even began.

What I Was Looking At

AI tools need the same operational discipline as any other infrastructure. If your database queries suddenly take ten seconds, you don't just restart the server — you run an EXPLAIN plan. You find the missing index. But with Claude Code, I was just restarting the server.

The symptom was clear: sessions stalling. The missing piece was visibility. I didn't know what the agent was loading on boot. I didn't know what context was being carried forward every single turn.

To fix it, I had to instrument the problem. I had to look at exactly what data was being injected into the prompt context at the start of every session and every turn.

How I Instrumented the Problem

I started by measuring the baseline. I looked at the hidden system directories that store the agent's memory, its settings, and its global configurations. I literally just ran a disk usage check on the configuration files that I knew were being appended to the system prompt.

# Check the size of the global settings file
ls -lh ~/.claude/settings.json

# Check the memory files
du -sh ~/.claude/projects/*/memory/

The command revealed the elephant immediately. The `settings.json` file was sitting at 95.7 KB. That is nearly 100 kilobytes of text being loaded into the context window on every single turn. And that was just the settings file. Add in the project memory files, and the baseline context overhead was hovering around 130 KB.

No wonder my sessions were dying. The context window wasn't empty when I started working. It was already carrying a massive backpack of technical debt.

Fix 1: The 15-Minute Hygiene Win

The settings audit was the most glaring issue. The `settings.json` permissions had ballooned to 928 entries. Every time I approved a command in the terminal for the agent to run, it was being appended verbatim to the allowlist.

This wasn't just `ls` and `git status`. This included multi-line bash scripts, massive `curl` payloads, and deeply specific grep commands. All of it was being dutifully saved to ensure the agent wouldn't have to ask for permission next time. The result was a 95.7 KB file that accounted for 73% of my total context overhead.

I pruned the 928 exact-match entries down to 116 wildcard patterns. Things like `git *`, `npm install *`, `pytest *`.

The file collapsed from 95.7 KB down to 2.5 KB. That was a 15-minute fix that reclaimed a massive chunk of my context window. Today it sits at 5.3 KB — I've added new patterns since the audit. The discipline is quarterly pruning, not a one-time fix.

Fix 2: The Architectural One

The second issue was harder. The agent's memory system was fundamentally broken by cross-project context bleed. I had domain knowledge for CSL Capital, the R9 Ranch, and Nektar Insights all loaded into memory files or global `CLAUDE.md` files.

When I was working on a React component for Nektar, the agent was carrying CSL Capital loan cohort analysis and R9 Ranch cattle lineage logic in the same prompt. It was a waste of tokens, and it caused hallucinations where the agent would try to apply agricultural logic to a SaaS dashboard.

The fix was architectural: an Obsidian wiki migration.

I moved the domain knowledge into three project-scoped Obsidian vaults, completely out of the always-loaded memory files. Today those vaults hold 635 pages combined (CSL 128, R9 355, Nektar 152) — a footprint that would have made the always-on memory unusable if I hadn't moved it out. Instead, the knowledge loads on-demand when I enter a specific project vault.

The agent now uses `Read` or a recall script to fetch the specific context it needs, rather than dragging the entire encyclopedia around on its back. This eliminated the cross-project context bleed entirely.

The Numbers

The impact of these two changes was immediate and dramatic. My sessions stopped dying. I could work for hours without hitting the wall. Here is what the overhead looked like before and after.

The config audit accounted for the lion's share of the byte reduction, but the architectural migration had an outsized impact on the quality of the context. By removing the 170 pages of unrelated domain knowledge, the model's attention mechanism was no longer diluted by noise.

What This Means for Tooling at Scale

We are moving from a world where AI is a novelty to a world where it is the operating system for how we build software. That requires a shift in how we manage it.

The editing-discipline part — that's still on me. The tools will keep getting faster, but knowing what to feed them is going to remain an engineering problem for a long time.

Reproducible Playbook

You can run this exact audit on your own setup today. It takes about five minutes to diagnose and fifteen minutes to fix.

# Find the size of your global settings
ls -lh ~/.claude/settings.json

# Check your project-specific memory footprint
du -sh ~/.claude/projects/*/memory/

# Open the settings file in your editor
code ~/.claude/settings.json

# Scroll to "allowedCommands". 
# Replace exact commands with wildcards (e.g. "npm install *", "git *").
# Look for and delete any embedded secrets or tokens.

# Move heavy documentation out of CLAUDE.md
mkdir -p ~/obsidian/my-project-wiki
mv ~/.claude/projects/my-project/memory/* ~/obsidian/my-project-wiki/

# Add a pointer in CLAUDE.md instead
echo "For domain rules, use Read on ~/obsidian/my-project-wiki/rules.md" >> CLAUDE.md