Understanding Claude’s Context Window, RTK, and Enterprise Security Considerations

A practical guide for engineers working with AI coding tools

What Is a Context Window?

Every conversation with Claude operates within a “context window” — the total amount of text the model can reference when generating a response. Think of it as working memory. Everything lives in a single buffer: your messages, Claude’s replies, system instructions, uploaded files, tool definitions, and tool results. Once a conversation ends, that context is gone. There’s no cross-chat recall, though Claude’s separate memory system can persist some high-level information between chats.

Each session gets its own independent context window. Starting a new chat means starting with a clean slate.

Context Window Sizes Across Claude Interfaces

Interface Context Size Visibility Auto-Compaction Claude.ai (web/mobile) 200K tokens No indicator Yes (with code execution enabled) Claude Code (CLI) Up to 1M tokens /context command; customizable status line Yes Cowork (desktop) Up to 1M tokens No indicator (feature requested) Yes

Claude.ai offers 200K tokens — roughly 500 pages of text. There’s no built-in indicator showing consumption. When code execution is enabled, Claude automatically summarizes older messages as you approach the limit. Without it, you simply hit a wall. The only signal is when Claude starts losing track of earlier conversation details or you get an error.

Claude Code supports up to 1M tokens on Opus 4.6 and Sonnet 4.6 for paid plans (Max, Team, Enterprise). It provides a /context command that shows a detailed breakdown of what's consuming your window. There's no persistent on-screen indicator by default — you have to type /context manually or set up a custom status line (more on that below). When context reaches roughly 83.5% capacity, auto-compaction kicks in: Claude summarizes older messages, drops the history, and continues from the summary.

Cowork uses the same underlying architecture as Claude Code and supports the 1M window on Opus 4.6. However, it currently has no context usage indicator at all — compaction arrives as a surprise mid-task with no warning. This is a known pain point with an open feature request on GitHub.

What’s Actually Inside the Context Window?

Running /context in Claude Code reveals the anatomy of your context window. Here's a real example after asking Claude Code to search Jira for assigned tickets:

/context
 ⎿  Context Usage
    ⛁ ⛁ ⛀ ⛁ ⛁ ⛁ ⛁ ⛁ ⛀ ⛀   claude-opus-4-6 · 43k/200k tokens (22%)
    ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁ ⛁
    ⛁ ⛁ ⛁ ⛁ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   Estimated usage by category
    ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System prompt: 5.2k tokens (2.6%)
    ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ System tools: 9.9k tokens (4.9%)
    ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ MCP tools: 459 tokens (0.2%)
    ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Skills: 237 tokens (0.1%)
    ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶ ⛶   ⛁ Messages: 28k tokens (14.0%)
    ⛶ ⛶ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝   ⛶ Free space: 123k (61.6%)
    ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝ ⛝   ⛝ Autocompact buffer: 33k tokens (16.5%)
    MCP tools · /mcp (loaded on-demand)
    Loaded
    └ mcp__claude_ai_Atlassian__atlassianUserInfo: 57 tokens
    └ mcp__claude_ai_Atlassian__getAccessibleAtlassianResources: 127 tokens
    └ mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql: 275 tokens

Breaking this down:

• System prompt (~5.2K tokens): Claude’s behavioral instructions, your CLAUDE.md files, and project instructions. This is fixed overhead every session.
• System tools (~9.9K tokens): Built-in tool definitions (Bash, Read, Write, Grep, Glob, etc.).
• MCP tools (459 tokens, loaded on-demand): Only the 3 Atlassian tools Claude actually needed were loaded — not all 30+ available. atlassianUserInfo to identify the user, getAccessibleAtlassianResources to find the cloud ID, and searchJiraIssuesUsingJql to run the query.
• Skills (~237 tokens): Loaded skill definitions. Negligible.
• Messages (28K tokens): The conversation history plus the Jira results returned from the API. This is where the bulk of the growth happens — a single Jira query can return 20K+ tokens of ticket data.
• Autocompact buffer (~33K tokens, 16.5%): Reserved space that can’t be used for conversation. This is the safety margin before compaction triggers.

The key insight: MCP tools are loaded lazily. Even with 80+ tools available across multiple servers, only the ones Claude actually calls consume context. And the expensive part isn’t the tool schemas — it’s the data returned from tool calls.

Monitoring Context Usage

In Claude.ai: There’s no way to check. You’re flying blind until you notice degradation or hit an error.

In Claude Code: Type /context for a snapshot. For persistent monitoring, you can set up a custom status line by typing /statusline and describing what you want (e.g., "show model, context percentage, cost, and git branch"). This generates a shell script that displays at the bottom of your terminal. Community tools like claude-statusline (Go), claude-statusbar (Python), and claude-powerline offer more polished alternatives.

Note that the cost figures shown in status lines are estimates, not actual billing. They multiply token counts by per-token API pricing but don’t account for prompt caching, and are irrelevant if you’re on a flat-rate subscription plan. The context percentage is the more actionable number.

In Cowork: No indicator exists yet. Some users work around this by building custom CLAUDE.md files and session-reload skills that re-read critical context from disk after compaction events.

RTK: Reducing Token Waste

What It Is

RTK (Rust Token Killer) is an open-source CLI proxy that sits between your AI coding agent and the terminal. It intercepts command outputs and compresses them before they reach the context window — filtering noise, grouping similar items, truncating redundancy, and deduplicating repeated lines. It claims 60–90% token reduction on common dev commands.

For example, git push normally returns 15 lines (~200 tokens) of progress output. RTK compresses it to ok main (~10 tokens). A failing cargo test that dumps 200+ lines becomes a 20-line summary of just the failures. Over a 30-minute session, RTK estimates savings from ~118K tokens down to ~24K.

How It Works

RTK installs as a Claude Code PreToolUse hook. When Claude runs git status, the hook transparently rewrites it to rtk git status before execution. Claude never sees the rewrite — it just receives compressed output. The hook only applies to Bash tool calls; built-in Claude Code tools like Read, Grep, and Glob bypass it.

Setup is straightforward:

brew install rtk
rtk init --global
# Restart Claude Code

You can check savings with rtk gain or rtk gain --graph.

What It Covers

RTK handles 30+ command types: git operations, test runners (cargo test, pytest, go test, jest, vitest), file operations (ls, find, grep, cat), package managers (npm, pip, cargo), Docker, kubectl, GitHub CLI, linters, and build tools.

Security Considerations for Enterprise Use

RTK is promising, but organizations should evaluate it carefully before rolling it out. Several concerns deserve attention.

1. Hook-Based Execution Is a Sensitive Attack Surface

RTK installs itself by wiring into Claude Code’s hook system. Anthropic’s documentation describes hooks as user-defined shell commands that execute automatically at specific points in the agent loop. A hook is not just configuration — it’s an execution path that runs with your user privileges. The evaluation should be the same as for any shell automation in your development environment.

2. Telemetry Sends Data Externally

The official Homebrew build includes telemetry that sends a device hash (SHA-256 of hostname + username), top commands used, and token savings stats to a third-party endpoint. The device hash is a persistent identifier linkable to a specific workstation. For enterprise environments, this may be a non-starter.

To opt out:

rtk config set telemetry.enabled false

Or set the environment variable: export RTK_TELEMETRY=off

Building from source (cargo install --git) instead of using Homebrew may avoid the telemetry URL entirely.

3. Known Security Gaps

A community security audit (conducted using Claude Opus 4.6 against the full codebase) found several issues:

• Shell injection risk: Commands from rtk err, rtk test, and rtk summary pass free-form strings directly to sh -c, which is a potential injection vector.
• Inconsistent trust boundaries: Project-local .rtk/filters.toml requires SHA-256 verification, but the global config at ~/.config/rtk/filters.toml is trusted unconditionally. Malware modifying the global filter could suppress security scanner output or rewrite arbitrary command output.
• Path traversal: The tee directory (RTK_TEE_DIR) isn't validated for relative paths, potentially allowing writes to unintended locations.

The audit’s overall verdict was “mostly sound architecture with real security engineering, but some significant issues.” The project has done more security work than the typical CLI tool, but the implementation doesn’t fully match its own stated security policies.

4. Maturity

RTK has ~13K GitHub stars and active development (430+ commits, 91 releases), but it’s still young. The recommended approach for organizations: audit first, pilot second, standardize last. Pin to a specific version, disable telemetry, and review the hook code before deploying.

Practical Recommendations

For individual developers: RTK offers real savings, especially if you’re on a rate-limited plan or doing CLI-heavy work. Install it, disable telemetry, and monitor your rtk gain stats. The context savings translate directly to longer sessions before compaction.

For teams and enterprises: Don’t install any hook-driven tool casually. Build from source to control telemetry. Audit the hook code (particularly rtk-rewrite.sh and src/runner.rs). Pin to a reviewed version. Consider that RTK only helps with Bash tool call output — if your context bloat mostly comes from file reads, MCP output, or large system prompts, RTK will only solve part of the problem.

For everyone: Understand your context window. In Claude Code, run /context regularly. Set up a status line if you run long sessions. Be strategic about which MCP servers you connect — each one adds tool definition overhead when invoked. And remember that the biggest context consumers are usually message history and tool results, not the tool schemas themselves.