Claude Code Sessions: Cost Engineering and Context Reuse Patterns That Ship Faster

You’ve felt it. Minute 45 of a Claude Code session. The latency creeps up. Responses get verbose, then vague. You’re repeating instructions you swore you gave 20 messages ago. The model isn’t getting dumber—your context window is polluted.

Anthropic’s guidance on maximizing Claude Code sessions lands on a truth that most engineers discover the hard way: long-running sessions are a liability, not a feature. The fix isn’t a bigger context window. It’s aggressive context engineering. For Forward Deployed Engineers (FDEs) juggling customer environments, proprietary codebases, and tight deadlines, these patterns aren’t optional—they’re the difference between shipping a fix in 20 minutes and burning an afternoon on token bloat.

Let’s break down the mechanics, the cost implications, and the concrete workflows that turn Claude Code from a chatty assistant into a precision instrument.

The Core Problem: Context Rot and Token Waste

Every message you send to Claude Code carries the full conversation history—code snippets, linter errors, that one time you asked it to explain a regex. The attention mechanism processes all of it, even the irrelevant bits. This isn’t a bug; it’s the architecture of autoregressive models. But it creates a compounding cost:

• Latency inflation: More tokens in the context window means more compute per forward pass. Response time grows non-linearly.
• Attention dilution: The model’s focus splinters across stale information. It starts hallucinating against old, invalidated code states.
• Monetary burn: You’re paying for every token in the input, not just the output. A session with 100k tokens of history is a tax you pay on every subsequent message.

For an FDE debugging a customer’s on-prem deployment, this isn’t theoretical. You paste a 400-line stack trace, iterate on a fix, verify it, then move to the next bug. Without intervention, that stack trace haunts every future prompt. The model confuses the old error with the new one. You’re now debugging the AI, not the code.

The Session Lifecycle: A Mental Model

Think of a Claude Code session like a Unix process. It has a birth, a working set, and a point where it should be SIGKILL’d. The goal is to keep the working set—the active context—as lean as possible.

The lifecycle isn’t linear—it’s a loop with an explicit escape hatch. You work, you compact, you fork. The fork is the critical move: it’s a fresh session initialized with a dense summary of what mattered, not the raw transcript.

Pattern 1: CLAUDE.md as Boot Code

Every Claude Code session reads CLAUDE.md from your project root on startup. Treat this file like a bootloader, not a README. It’s your chance to inject persistent context without burning a single message.

What goes in it:

• Build commands and test runners specific to this repo
• Linting and formatting rules (e.g., "use ruff format, never black")
• Architectural constraints ("this service uses Hexagonal Architecture; ports are in domain/, adapters in infra/")
• Known footguns ("the User model has a legacy role_id column—ignore it, use roles M2M")

What doesn’t:

• Long code examples (link to files instead)
• Transient task instructions (those belong in the prompt)

An FDE maintaining three customer forks can ship a tailored CLAUDE.md per branch. When you context-switch, the model loads the right mental model instantly. This is far cheaper than explaining your architecture in every session.

If you’re building RAG pipelines or agentic workflows that rely on precise project context, the same principle applies. We cover structured context injection in depth when we walk through building a codebase QA tool with LlamaIndex and Supabase Vecs. The pattern is identical: front-load the invariant context so the model doesn’t have to rediscover it.

Pattern 2: Compaction and Forking

This is the highest-leverage habit. When a session feels sluggish or hits ~100 messages, don’t keep pushing. Run /compact.

Compaction tells Claude Code to summarize the conversation history into a dense, structured digest. The model extracts decisions, unresolved issues, and the current state of modified files. It discards the dead ends, the corrected mistakes, the verbose explanations. You then use that summary to initialize a fresh session—a fork.

The workflow:

1. /compact produces a summary block.
2. Copy that summary.
3. Open a new terminal tab, cd to the same project.
4. Paste the summary as your opening prompt, prefixed with: "Continuing a previous session. Here’s the compacted context:"
5. Continue working with a clean context window.

This isn’t just about performance—it’s about correctness. A forked session has no memory of the code state from 50 messages ago. It reads the current filesystem. If your compacted summary says "we agreed to refactor the auth middleware to use JWT," the model checks the actual auth.py and sees the current truth. No stale hallucinations.

For FDEs, this maps to a core skill: prompting as delegation. You’re handing off a structured brief to a fresh agent, not micro-managing a tired one. The same discipline that makes you a good engineering lead—clear context, explicit constraints, clean handoffs—makes you effective with Claude Code.

Pattern 3: Git Worktrees for Parallel Context

Here’s a power move for FDEs juggling multiple features or bugs. git worktree lets you check out multiple branches of the same repo into separate directories, all sharing one .git store. Combine this with Claude Code sessions, and you get parallel, isolated context streams.

Setup:

git worktree add ../project-feature-a feature-a
git worktree add ../project-hotfix hotfix/customer-x

Each worktree gets its own CLAUDE.md, its own set of open files, its own Claude Code session. You can have a long-running refactor session in one terminal, and a quick bugfix session in another, with zero context cross-contamination.

This is especially powerful when paired with the FDE rhythm of embedding, shipping, and expanding in a live customer environment. Monday you’re in customer-a worktree debugging a pipeline. Tuesday you switch to customer-b worktree for a feature request. Each session’s context is pristine and customer-specific.

Putting It All Together: The High-Signal Workflow

Here’s a concrete daily workflow that minimizes token waste and maximizes throughput:

1. Morning setup: Pull latest main. For each active task, create a git worktree with a custom CLAUDE.md that includes customer-specific build steps, database connection strings (never secrets—use env vars), and architectural notes.

2. Task initiation: Start a fresh Claude Code session in the worktree. Your opening prompt is tight: "In src/auth/handlers.py, the login function has a race condition on token refresh. The relevant code is lines 45-78. Propose a fix using a database lock."

3. Work loop: Iterate. When the model suggests a change, apply it, test it, feed the test output back. Stay focused on a single logical change.

4. Compaction trigger: The moment you feel friction—slower responses, the model forgetting a constraint you set 10 messages ago—/compact. Don’t wait. The cost of forking is near-zero; the cost of context pollution compounds.

5. Fork and resume: Paste the compacted summary into a new session. Verify the model understands the current code state by asking it to summarize the change so far. If it’s accurate, continue. If not, your compacted summary wasn’t dense enough—add the missing constraint explicitly.

6. Commit and cleanup: Once the change is merged, git worktree remove the branch. The session dies with it. No lingering context, no mental overhead.

This workflow is especially relevant when building automation that touches external APIs. In our guide on automating daily Slack channel summaries with n8n and Groq, we emphasize the same principle: isolate tasks, keep context minimal, and don’t let one failure cascade into the next execution.

The Trade-offs: When This Breaks Down

Aggressive compaction isn’t free. You lose the model’s memory of subtle design rationale—the why behind a decision that was discussed over 15 messages. If you’re in the middle of a complex architectural discussion, forking too early can strip away nuance.

Mitigation: In your compaction prompt, explicitly instruct the model to preserve design rationale. Add to your prompt: "In your summary, include a section called 'Design Decisions' that captures the reasoning behind key choices, not just the outcomes."

Also, compaction works poorly when the session hasn’t converged. If you’re still exploring and haven’t made concrete decisions, the summary will be vague. Better to let the session run until you have a clear direction, then compact.

Finally, CLAUDE.md can become a dumping ground. Review it weekly. If a constraint hasn’t been relevant in three sessions, delete it. Stale boot context is worse than no boot context—it trains the model to ignore the file.

FAQ: Session Engineering

Q: How many messages before I should /compact? A: No fixed number. Watch for latency and attention drift. As a heuristic, 50-80 messages is the zone where most engineers notice degradation. But if you’re pasting large code blocks, compact sooner. Token count matters more than message count.

Q: Can I automate compaction? A: Not directly, but you can build the habit. Some engineers set a terminal prompt indicator that changes color after N messages. A simpler trick: if you can’t remember what you said in message #1, it’s time to compact.

Q: Does CLAUDE.md work for non-code tasks? A: Yes. It’s just system-level context. If you’re using Claude Code for data analysis, your CLAUDE.md can specify preferred plotting libraries, color palettes, and statistical conventions. The principle is universal: preload what’s invariant.

Q: How do I handle secrets in CLAUDE.md? A: You don’t. Ever. Use environment variables and reference them: "Database URL is in $DATABASE_URL." Claude Code reads the env var at runtime. Never hardcode credentials.

Q: What if I need a very long, uninterrupted session? A: Some tasks—like a multi-hour debugging session following a distributed trace across six microservices—genuinely need long context. In those cases, use compaction as a checkpoint, not a reset. Compact, fork, but keep the old session open in a background tab. If the fork loses critical context, you can copy-paste from the old session’s summary. This gives you a safety net while still benefiting from a clean window.

Context engineering is the meta-skill that separates Claude Code power users from everyone else. It’s not about smarter prompts—it’s about understanding the substrate. Treat your context window like L1 cache: small, fast, and ruthlessly evicted. Your ship velocity will thank you.