claude-code - 💡(How to fix) Fix [FEATURE] System prompt consumes user context window — should be separated [1 comments, 2 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Problem

The base system prompt (tool definitions, permission rules, skill listings, MCP server instructions, plan mode instructions, etc.) is loaded into the user's context window every session. This consumes a significant portion of the available context before the user even sends their first message.

Observed impact

• In a non-coding, document-only project, the system prompt (tool schemas, coding-specific rules, skill listings) still occupies ~25% of the context window.
• Even after aggressively disabling MCP servers, skills, and hooks via project-level settings.json, the reduction is marginal because the core system prompt itself is large and unavoidable.
• Users experience repeated compaction cycles (4+ compactions in a single session), losing conversation history prematurely.
• This has been a persistent complaint across 6+ sessions with no effective mitigation available to the user.

What was tried

• Denied 11 MCP servers at project level
• Turned off 27+ skills via skillOverrides
• Disabled 25+ hooks via ECC_DISABLED_HOOKS
• Result: system prompt still dominates context usage

Proposal

1. Separate system prompt from user context: Move tool definitions, permission rules, and base instructions to a dedicated system layer that does not count against the user's context window.

2. Lazy-load tool schemas: Tool schemas (especially for deferred tools) should only be loaded into context when actually invoked, not pre-loaded. The current ToolSearch pattern already does this partially — extend it to all tools.

3. Project-type-aware prompt trimming: If a project is identified as non-coding (e.g., document/proposal work), automatically exclude coding-specific tool definitions, git instructions, commit guidelines, PR creation rules, etc.

4. Expose context budget breakdown: Provide users visibility into how much context is consumed by system prompt vs. conversation vs. tool results, so they can make informed decisions.

Environment

• Claude Code CLI (desktop app, macOS)
• Model: claude-opus-4-6
• Project type: document/proposal (non-coding)

Expected behavior

The system prompt should not materially reduce the user's available context window. Users paying for context should get to use it for their actual work, not for housing tool definitions they may never invoke.

Proposed Solution

Proposed Solution

1. System prompt isolation

Move base system instructions (tool schemas, permission rules, commit/PR guidelines) to a separate system layer that does not count against the user's context window. The Anthropic API already supports a system parameter distinct from messages — leverage this boundary so infrastructure instructions don't compete with user conversation.

2. On-demand tool schema loading

Currently, all tool schemas are injected at session start regardless of usage. Instead, load only tool names upfront (as ToolSearch already does for deferred tools) and fetch full schemas on first invocation. This would significantly reduce the baseline prompt size.

3. Project-type-aware prompt selection

Claude Code already detects project type (e.g., {"primary":"python"} vs. document projects). Use this signal to exclude irrelevant instruction blocks — a document-only project doesn't need git commit guidelines, PR creation rules, or coding-specific tool definitions.

4. Context budget transparency

Expose a breakdown of context usage (system prompt / conversation / tool results) to users, so they can make informed decisions about what to disable. Currently users have no visibility into what's consuming their context.

Expected Outcome

• Users reclaim 20-30% of context window currently consumed by system infrastructure
• Fewer premature compaction cycles (observed 4+ per session in document projects)
• Project-level settings (deniedMcpServers, skillOverrides) become genuinely effective instead of marginal

Alternative Solutions

Proposed Solution

1. System prompt isolation

Move base system instructions (tool schemas, permission rules, commit/PR guidelines) to a separate system layer that does not count against the user's context window. The Anthropic API already supports a system parameter distinct from messages — leverage this boundary so infrastructure instructions don't compete with user conversation.

2. On-demand tool schema loading

Currently, all tool schemas are injected at session start regardless of usage. Instead, load only tool names upfront (as ToolSearch already does for deferred tools) and fetch full schemas on first invocation. This would significantly reduce the baseline prompt size.

3. Project-type-aware prompt selection

Claude Code already detects project type (e.g., {"primary":"python"} vs. document projects). Use this signal to exclude irrelevant instruction blocks — a document-only project doesn't need git commit guidelines, PR creation rules, or coding-specific tool definitions.

4. Context budget transparency

Expose a breakdown of context usage (system prompt / conversation / tool results) to users, so they can make informed decisions about what to disable. Currently users have no visibility into what's consuming their context.

Expected Outcome

• Users reclaim 20-30% of context window currently consumed by system infrastructure
• Fewer premature compaction cycles (observed 4+ per session in document projects)
• Project-level settings (deniedMcpServers, skillOverrides) become genuinely effective instead of marginal

Priority

Critical - Blocking my work

Feature Category

Performance and speed

Use Case Example

No response

Additional Context

No response