[FEATURE] System prompt consumes user context window — should be separated
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] 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
- 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.
- Lazy-load tool schemas: Tool schemas (especially for deferred tools) should only be loaded into context when actually invoked, not pre-loaded. The current
ToolSearchpattern already does this partially — extend it to all tools.
- 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.
- 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_
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗