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.

Claude Code sends a request through an observability proxy to the Anthropic API. The proxy records request details and returns the API response to the client.

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

  1. Establish a baseline. Record the Claude Code version, model, connected servers, and a representative task. Inspect /usage and /context first.

  2. Inspect requests if needed. Use a compatible, trusted proxy to examine instructions, tool definitions, and usage fields without changing request behavior.

  3. Make one focused change. Shorten irrelevant instructions, disable an unused server, or deny a tool the task does not need.

  4. Run the same kind of task again. Compare context, cached and uncached usage, number of turns, and whether the result is correct.

  5. 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

Anthropic API — token counting

Model Context Protocol — documentation