Every time Claude Code sends a request to the Anthropic API, more travels with it than the words you just typed. System instructions, project context, conversation history, tool definitions, and tool results all contribute to the request. If you only look at your own prompt, you miss most of the picture.
The original example behind this guide compared a setup with roughly 25,000 tokens of overhead against a reduced setup near 8,000. A configuration with several connected services reached approximately 108,000 tokens. These are examples from a particular setup, not a default cost, a benchmark for every version, or a promise of savings.
This article walks through how to measure what is being sent and how to cut unnecessary context while retaining the tools your current workflow actually needs.
Start with visibility
Claude Code is a client; the Anthropic API is the upstream service. Understanding the traffic between them helps explain why a short prompt can lead to a much larger request. But you do not need to start blind: current Claude Code versions include native usage and context information.
Use /usage to inspect session token usage and available plan information. The locally calculated dollar figure is an estimate; use your provider’s billing records for authoritative charges.
Use /context to inspect what occupies the context window. Check project instructions, conversation history, and tool contributions before changing settings.
Use a configured status line if you want usage information visible as you work.
Until you measure it, you cannot optimize it. Start with your own session, your own model, and a representative task.
A usage total and a raw request answer different questions. Native statistics are a good first step. If you need to inspect exactly which instructions and schemas were sent on a particular call, an observability proxy can provide a closer view.
Put a proxy in the middle when you need request-level detail
An LLM observability proxy sits between Claude Code and the Anthropic API. A pass-through configuration forwards requests and responses while recording the information needed for inspection. Choose a proxy that supports your API provider, streaming responses, authentication method, and the headers your workflow requires.
The aim is to observe normal traffic without rewriting prompts or tool definitions. Confirm that the proxy preserves streaming and responses before comparing measurements. Request logs may contain source code, prompts, credentials, or tool results, so use a trusted local or organization-approved service and redact secrets before storing or sharing logs.
What to inspect
System and project context — instructions supplied ahead of your question, including relevant CLAUDE.md content, memory, and injected guidance.
Tool definitions — the names, descriptions, and parameter schemas made available for the request. Check what is actually loaded rather than assuming every installed tool is always included.
MCP tools — connected servers can add context, but current Claude Code versions defer MCP tool definitions by default until a tool is used. Server instructions and tool names can still contribute overhead.
Conversation and tool results — previous turns, file contents, logs, and command output can grow the context as a session continues.
Usage fields — separate input, output, cache reads, and cache writes. A raw context total is not the same thing as uncached billable input.
The large 108,000-token example illustrates what a tool-heavy configuration can look like. It does not describe every current installation. Tool loading, model choice, caching, and the point in the conversation all affect the result.
Cut what this task does not need
One mechanism is permissions.deny in your Claude Code settings. A bare tool-name deny rule removes that tool from Claude’s context and prevents its use. A scoped rule such as Bash(rm *) restricts matching actions; it does not remove the whole Bash tool. Treat these as different controls.
Measure first, then switch off what this task does not need — and switch it back on when it does.
Denying a tool makes it unavailable while the rule applies. It is not deleted or uninstalled, but the session does lose that capability until the restriction is removed. Keep the tools required for the work, and test the workflow after every change.
Keep: normal coding sessions
Tool | What it does |
|---|---|
Read | Reads file contents. |
Edit | Makes a targeted change to a file. |
Write | Creates or overwrites a file. |
Glob | Finds files by pattern. |
Grep | Searches file contents. |
Bash | Runs shell commands in supported environments. |
PowerShell | Runs PowerShell commands when available in your environment. |
Keep when your workflow needs them
Tool | Keep it when you need to… |
|---|---|
WebSearch / WebFetch | Find current information or read a web page. |
Agent | Delegate a task to a subagent. |
Skill | Use a packaged workflow. |
AskUserQuestion | Answer structured questions during a task. |
NotebookEdit | Edit Jupyter notebook cells. |
EnterWorktree / ExitWorktree | Work in an isolated Git worktree. |
EnterPlanMode / ExitPlanMode | Use the agent’s planning workflow. |
Review optional and environment-specific tools
The original configuration included tools for publishing artifacts, reviewing work, scheduling actions, messaging, and design integrations. Availability and canonical names depend on the product, version, plugins, and connected services. Do not paste a long deny list of names that your installation does not expose.
Examples from the original setup | Review before disabling |
|---|---|
Artifact / ReportFindings | Artifact publishing and structured review output. |
CronCreate / CronDelete / CronList | Scheduled jobs and recurring tasks. |
ScheduleWakeup / Monitor | Wakeups and condition monitoring. |
DesignSync / RemoteTrigger | Design or remote workflow integrations. |
SendMessage / ListAgents / PushNotification | Agent coordination and notifications. |
These examples are a checklist of capabilities to review, not a verified list of built-in tools for every Claude Code installation. Use the current tools reference and your active configuration to identify the correct names.
A small configuration example
For a coding task that does not involve notebooks, this minimal example denies NotebookEdit. Merge the entry into your existing settings rather than replacing unrelated permissions. Remove it when notebook editing becomes part of the task.
{
"permissions": {
"deny": [
"NotebookEdit"
]
}
}Confirm the active rule with /permissions and compare /context before and after. A rule inherited from managed settings may still apply after you remove a local entry. Do not disable planning, questioning, or coordination tools just to make a token count look smaller if your workflow depends on them.
Review connected MCP servers
Use /mcp to inspect connected servers and disable services that are irrelevant to the task. Current deferred tool loading already reduces some schema overhead, so compare actual requests rather than assuming that disconnecting a server removes its full catalog from every call.
A service needed for the next task can be enabled again. The useful question is not “How few tools can I leave?” but “Which tools does this task need to finish correctly?”
Understand the example: 25K down to 8K
Example configuration | Approximate tokens |
|---|---|
Original measured setup | 25,000 |
Reduced measured setup | 8,000 |
Difference per comparable request | 17,000 (68% less) |
In that example, the reduced request contained about 32% of the original overhead. Across 50 otherwise comparable requests, a 17,000-token reduction would add up to 850,000 fewer input tokens. This is arithmetic based on the example, not a prediction for your sessions.
It also does not mean an identical percentage reduction in your bill. Cached input, cache writes, output tokens, model prices, and provider rules affect monetary cost. Changing tool definitions can invalidate a cached prefix, so compare complete representative sessions as well as individual requests.
The right success criterion is that the task still completes correctly with less unnecessary context. If the agent now needs more turns, repeatedly asks for missing capabilities, or cannot finish, the change may have made the workflow worse.
A repeatable measurement workflow
Establish a baseline. Record the Claude Code version, model, connected servers, and a representative task. Inspect /usage and /context first.
Inspect requests if needed. Use a compatible, trusted proxy to examine instructions, tool definitions, and usage fields without changing request behavior.
Make one focused change. Shorten irrelevant instructions, disable an unused server, or deny a tool the task does not need.
Run the same kind of task again. Compare context, cached and uncached usage, number of turns, and whether the result is correct.
Keep useful changes and restore needed tools. Revisit the configuration when the task changes.
Key takeaway
Measure what is actually present, remove what is unnecessary, and keep the capabilities that matter. Native usage statistics help you start; request inspection helps when you need deeper detail. Focused tool configuration is one part of the process, alongside clear instructions, appropriate context, and attention to caching.
Fewer irrelevant tools and less unnecessary context can make a session more focused. Your own measurements tell you what is worth cutting.
Resources
Claude Code — usage, costs, and context management
Claude Code — permission rules and tool restrictions
Claude Code — settings reference
Claude Code — available tools and canonical names