[BUG] Effective usable context window is significantly reduced by infrastructure overhead

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Effective usable context window is significantly reduced by infrastructure overhead

Description:

Claude Code and the Claude app share the same underlying model context window (200K tokens), but Claude Code's infrastructure
— system prompts, tool definitions, behavioral instructions, and accumulated tool call results — consumes a substantial
portion of that window before the user has provided any input.

This means the functional context available for user content (code, documentation, project standards, conversation) is
materially smaller in Code than in the app, despite the same advertised model capability.

Why this matters:

Software development doesn't happen in a vacuum. Real projects have governing documentation — compliance requirements,
architecture decision records, security policies, coding standards, style guides. These need to be in context alongside the
code for the agent to produce compliant work. The current design forces users to choose between tooling capability and working
context, which limits Code's effectiveness for any project operating under non-trivial standards.

The experience gap:

• In the Claude app, I can load my full project policy set and work holistically. It fits.
• In Claude Code, the same policy set exceeds usable context because the infrastructure has already consumed a significant

share of the window.

• This creates inconsistency between the two interfaces for the same model, and pushes users toward lossy workarounds

(summarization, selective loading) that introduce compliance risk.

Suggestion:

Consider provisioning infrastructure overhead separately from the user-facing context window, or at minimum:

1. Transparently surface the effective usable context (not raw model window) so users can plan accordingly
2. Explore architectural options that don't tax the user's working memory for system infrastructure

From an infrastructure perspective, sharing a fixed resource pool between system overhead and user workload — without
visibility into the split — is a capacity planning problem. Users shouldn't discover the constraint mid-session when context
starts compressing.

What Should Happen?

Consider provisioning infrastructure overhead separately from the user-facing context window, or at minimum:

1. Transparently surface the effective usable context (not raw model window) so users can plan accordingly
2. Explore architectural options that don't tax the user's working memory for system infrastructure

Error Messages/Logs

Steps to Reproduce

Load a large policy set in to the app, and to code respectively.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.53

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Xterm

Additional Information

_No response_