Working With 1M Token Context Windows Without Losing Your Mind
If you've ever pasted a 50,000-line codebase into Claude and watched it confidently hallucinate a function that doesn't exist, you know the frustration. Large context windows sound like a solved problem until you're actually using them. The model technically has access to your entire repo, but retrieval quality degrades, attention drifts, and you spend more time re-prompting than you would have spent just reading the code yourself.
The problem isn't the context window size — it's that most developers treat a 1M token context like a bigger clipboard. You dump everything in, ask a question, and hope the model finds the relevant pieces. That approach breaks down fast when you're debugging a distributed system, auditing a legacy codebase, or trying to trace a data pipeline across a dozen files. The raw capacity is there, but using it effectively requires actual structure.
What People Usually Try
The common workarounds each have real costs. RAG pipelines add infrastructure overhead and miss non-semantic connections between files. Chunking documents manually is tedious and breaks relationships between sections. Most developers end up doing ad-hoc prompt engineering — pasting "pay special attention to the auth middleware" — which is hard to reproduce and inconsistent across teammates. Summarization chains lose detail at exactly the wrong moments. None of these are wrong, but they're treating symptoms rather than building a repeatable system.
A Structured Approach to Context Management
The core idea is that context needs to be layered, not flat. Rather than one giant prompt, you build a hierarchy: a compact system-level manifest that describes what's in the context, followed by the actual content organized by relevance to the current task. The model reads the manifest first, which primes attention before it hits the raw material. This is similar to how you'd write a technical document — executive summary before appendices.
Practically, this means maintaining a context map as a structured artifact alongside your code. For a large codebase, that might be a context_manifest.json that categorizes files by domain, marks entry points, and notes critical dependencies. When you start a Claude session, you inject the manifest before anything else:
def build_session_prompt(manifest_path, task_description, relevant_files):
manifest = json.load(open(manifest_path))
system = f"Codebase map:\n{json.dumps(manifest, indent=2)}\n\nTask: {task_description}"
file_contents = "\n\n---\n\n".join(
f"# {f}\n{open(f).read()}" for f in relevant_files
)
return system, file_contents
This gives the model a schema for the context before it processes content, which measurably improves accuracy on cross-file questions.
The third piece is task-scoped context loading. Instead of loading everything for every query, you define task types — debugging, refactoring, documentation, security audit — and pre-specify which context layers matter for each. A debugging session needs runtime logs, the call stack, and the relevant module. A security audit needs API routes, authentication middleware, and data validation layers. Pre-defining these profiles means you're not deciding what to include mid-session, and you can share those profiles with your team.
Quick Start
- Audit your current prompts — look at your last 10 Claude sessions and note where the model missed something that was in the context. That pattern tells you where your context structure is failing.
- Build a manifest for one project — create a JSON or YAML file that maps your codebase: modules, their responsibilities, and key dependencies. Keep it under 2,000 tokens.
- Write three task profiles — define what context layers your three most common tasks actually need. Debug sessions, feature work, and code review are a reasonable starting set.
- Implement the layered prompt builder — adapt the snippet above to your stack, injecting the manifest as the first element of every session prompt.
- Run an A/B comparison — use your old flat-paste approach and the new layered approach on the same question across the same codebase. Measure how many follow-up prompts each requires.
- Iterate the manifest — after two weeks, update the manifest based on what the model consistently missed. The manifest is a living document.
The mechanics here aren't complicated. The discipline is in treating context architecture as a first-class concern rather than an afterthought.
Full toolkit at [ShellSage
Top comments (0)