Claude Code has a feature called auto-compact that quietly destroys your session quality.

The Problem

I was three hours into a multi-file refactoring session, had just finished explaining which modules needed interface changes and which were already done. Auto-compact fired at 80% context. When Claude came back, it had no idea which files had been edited and which still needed changes. It suggested modifying a file I'd finished an hour earlier and forgot a constraint I'd repeated twice. I had to re-explain the entire task from scratch.

The community calls this "lobotomization" and it's accurate. Post-compaction Claude loses track of what repo you're in, forgets constraints you set, drops skills you invoked. The quality drop is immediate and obvious.

A note on terminology: throughout this post I reference /flush, /project, and other slash commands. These are custom Claude Code skills I built (stored as markdown files in ~/.claude/commands/), not built-in features. /project loads a project's saved state (CLAUDE.md with Working/Blocked/Next, domain topic files, recent daily logs) so Claude knows what happened last session. /flush captures the current session state to multiple places (daily log, project state, MEMORY.md, topic files) so the next session can pick up where this one left off. Think of /project as "load game" and /flush as "save game." The skill files are simple markdown prompts that Claude follows as instructions.

The Technical Reality

Community analysis of Claude Code's minified source found a hardcoded buffer that triggers compaction. The exact value has changed across versions (it was ~13k in early 2026, reportedly ~33k in later builds), but the mechanism is the same:

var jbA = 13000;

function lwB() {
    let T = UhT();      // Available input (context - max_output_tokens)
    let R = T - jbA;    // Subtract 13k buffer
    return R;           // This is where auto-compact triggers
}

Buffer Reserved = max output tokens + safety buffer.

With default settings, you're losing 22.5% of your context window to a safety buffer you may never need.

These numbers reflect the ~13k buffer from early 2026 builds. If the buffer has increased in your version, the usable context will be lower. The principle holds regardless: auto-compact reserves a meaningful chunk of your context window.

Why This Matters

Research on iterative context rewriting (arXiv 2510.04618) calls it "context collapse": when LLMs rewrite their own context iteratively, accuracy drops. Claude Code's auto-compact does exactly this.

Compaction is lossy compression. You're asking an LLM to decide what's "important" and discard the rest. For the kind of work I do (multi-file refactors, constraint-heavy debugging sessions, anything where I've spent twenty minutes explaining what not to touch), that's a bad tradeoff.

The Fix

Add one line to ~/.claude.json:

{
  "autoCompactEnabled": false
}

Or run /config in an active session and toggle "Auto-compact enabled" off.

The New Workflow

With auto-compact disabled, you get the full 200k context window with no buffer held in reserve. No surprise compaction mid-task. The session stays coherent until you decide otherwise.

When I do need to reclaim context, I use /compact with explicit instructions: /compact "focus on the authentication refactor, discard the earlier debugging". This way I control what survives instead of letting Claude guess. More often, though, the better move is /export to save the conversation, then start a fresh session and have Claude read it back in. Fresh context, curated history, no lossy summarization.

I also dropped my flush threshold from 75% to 60%. When context hits 60%, Claude prompts me to run /flush before continuing. This captures the session state while there's still room to maneuver.

The Tradeoff

Disabling auto-compact means sessions will hit the context limit. You'll need to manually compact, export and restart, or finish the task before running out. I'd rather use that 45k toward skills, rules, and context I deliberately set up than reserve it for an automatic summarization that makes Claude worse.

Anthropic's own guidance has moved toward recommending auto-compact stay enabled, and for simple single-task sessions that's reasonable. For constraint-heavy work where I've built up significant context (multi-file refactors, debugging with specific rules about what not to touch), the automatic summarization loses too much.

Claude Code now supports 1M token context windows on some plans, which reduces the urgency of this problem. But context hygiene still matters at any window size. A 1M window fills up the same way a 200k window does, just slower. Knowing when to flush deliberately versus letting auto-compaction guess is a workflow discipline, not a context size question.

Session Management (Beyond Compaction)

The Context % Statusline

I have a custom statusline script that shows [XX%] at every prompt so I always know how much context is left. The script reads context_window.used_percentage from Claude Code's JSON input and renders it inline:

# ~/.claude/statusline-command.sh
PERCENT=$(echo "$input" | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
printf "\033[01;32m%s@%s\033[00m:\033[01;34m%s\033[00m [%s%%]" "$user" "$host" "$cwd" "$PERCENT"

The Emergency Rescue

When you hit >90% and can't even run /flush (the output won't fit), the workaround is a second terminal:

# In the dying session:
"Write a summary of everything we've done to ~/session-dump.txt"

# In the fresh session:
"Read ~/session-dump.txt and run /flush for those projects"

The dying session has enough context left to write a file. The fresh session has enough context to process it. One session as the brain, the other as the hands.

Thresholds

The Session Lifecycle

Session Start: /project

Every session starts with /project <name>, which fuzzy-matches against a project index, reads the project's CLAUDE.md (including the State section with Working/Blocked/Next), pulls in domain-specific topic files, and checks recent daily logs for open threads. After that, Claude knows what I was doing last session, what's blocked, and what's next. I've wasted enough time re-explaining context to treat this as non-optional.

During the Session

MEMORY.md is always available (auto-loaded). Topic files get pulled when the task crosses domains. Context files from llm-context/ are loaded as needed.

Session End: /flush

Think of /flush as a save game hotkey. You just scraped through a gnarly debugging session, you're at 65% context, and the next task is going to be heavy. /flush captures session state to three or four places: daily log, project state (Working/Blocked/Next), MEMORY.md for new lessons, and optionally a domain topic file if something specialized came up. All append-only, new entries prepended, old entries never dropped.

I learned the hard way that skipping /flush before switching tasks means the next session starts cold. Claude picks up CLAUDE.md and has no idea what happened in the gap.

I watched this exact failure mode play out over three months on a cron health system, where each cold-start session ratified a broken fix (see: The LLM Kept Saying ‘Fixed.’).

After /flush: Why /clear Beats /compact

After flushing, I use /clear instead of /compact. Compaction spends tokens on a lossy summary. /clear costs zero tokens and gives a clean 200k window. The memory system means nothing is lost: /flush already persisted everything worth keeping, and /project reloads it.

/compact still has a use case mid-session (at ~70% context, same task, don't want to reload everything). For session boundaries, /clear is strictly better.

Daily Cron

Drift check confirms indexes match filesystem reality. Heartbeat alerts for overdue P1 tasks get written to the daily log automatically.

Data Flow Summary

/project (read) → work → /flush (write) → /clear → /project (read) → ...

Each session starts where the last one left off, without carrying the previous session's token baggage.

Hooks as Workflow Enforcement

Claude Code's settings.json supports lifecycle hooks: PreToolUse, PostToolUse, and PermissionRequest. These fire on every tool call, and the output gets injected into the conversation as a system reminder. Most people use them for security (blocking dangerous commands). But they're also the best way to enforce workflow patterns that instructions alone can't guarantee.

Example: Forcing a Plan Template

I have a plan template at ~/llm-context/plan-template.md with pre-flight checklists, agent routing guidance, TDD decisions per step, and a verification matrix. CLAUDE.md says "use this template for any plan with 3+ steps." Claude follows this instruction maybe 70% of the time. When it doesn't, the plan is worse: missing verification steps, no fail-fast conditions, no agent routing.

The fix is a PostToolUse hook on EnterPlanMode. When Claude enters plan mode, a 5-line shell script fires and injects the entire plan template into the conversation as a system reminder. Claude can't miss it because the template is literally in the conversation at the moment planning starts.

The hook script:

#!/bin/bash
TEMPLATE="$HOME/llm-context/plan-template.md"
if [[ -f "$TEMPLATE" ]]; then
  echo "MANDATORY: Use the following plan template. Follow its structure exactly."
  echo ""
  cat "$TEMPLATE"
fi

The settings.json entry:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "EnterPlanMode",
        "hooks": [{
          "type": "command",
          "command": "/path/to/plan-mode-template.sh",
          "timeout": 5
        }]
      }
    ]
  }
}

Why This Works Better Than Instructions

A PostToolUse hook injects the template into the conversation at the moment it's needed. Claude can't miss what's already on screen. CLAUDE.md instructions compete for attention with everything else in the system prompt, and compliance hovers around 70%. The hook makes it 100%.

Any time you catch yourself thinking "Claude keeps forgetting to do X before Y," that's a hook. I have a PostToolUse on WebFetch that injects prompt injection warnings after fetching external content (caught a real issue once when a scraped page had instructions embedded in it). I have a PreToolUse on Bash that adds safety checks before shell commands in my infrastructure directories. A PostToolUse on Write/Edit that reminds Claude to lint after file modifications.

What Belongs Here vs Memory Architecture

The session management side is the easy part. How the memory files are structured, what goes in MEMORY.md vs topic files vs project state, is the part most people get wrong. That's a separate post.

Related: LLM Benchmark Rankings 2026 | LLM Routing Playbook | API Quota Dashboard