[PERFORMANCE] Unused tool and skill metadata adds avoidable latency to every agent turn

Status Open
Reported on v2.1.222
Maintainer reply None cached
Activity 0 comments · opened Sep 24, 2026

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?

Claude Code appears to carry a large amount of tool and capability metadata
through the agent loop even when most of those capabilities are not relevant
to the current task.

The concern is not that an individual tool is slow. The concern is the
repeated processing of information that remains unchanged between turns.

For a simple task such as editing one local file, the agent may only need
one or two capabilities, but the surrounding tool/skill context can remain
part of the request lifecycle.

As the number of available tools, skills, hooks, and session-level
instructions increases, this creates a potential "metadata tax" on every
additional turn.

The latency therefore appears capable of growing with the size of the
available capability context rather than with the actual complexity of the
user's request.

What Should Happen?

Claude Code should avoid repeatedly processing unchanged capability
metadata when it is not required for the current turn.

A possible approach would be to separate:

  1. Stable session metadata
  2. Currently relevant tools
  3. Task-specific instructions
  4. Dynamic tool results

Stable information could be cached or referenced rather than repeatedly
reconstructed and transmitted.

For example:

Session initialization
↓
Capability registry
↓
Cache / identifier
↓
Current turn
↓
Only relevant capabilities
↓
Model

This should reduce unnecessary work while preserving the same tool-selection
and instruction-following behavior.

Error Messages/Logs

No error is displayed.

The issue is related to performance and request-processing overhead rather
than an explicit failure.

Steps to Reproduce

  1. Start Claude Code in a clean project.
  1. Measure the response time for a simple task that requires only one

basic capability.

  1. Create a second environment containing a substantially larger set of

available skills/tools.

  1. Run the same task without changing the model, prompt, or project code.
  1. Compare the response and first-token latency between the two environments.
  1. Repeat each test several times to reduce the effect of normal network

and inference variation.

  1. Repeat the experiment with the same conversation after several tool

calls.

  1. Record:
  • number of available tools
  • number of available skills
  • approximate prompt/context size
  • time to first response
  • total turn duration

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown

Claude Code Version

2.1.222

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Investigation direction

The main question I am trying to isolate is:

Does Claude Code's turn latency increase as the amount of available but
unused capability metadata increases?

I am intentionally separating this from the execution time of individual
tools.

A useful diagnostic would be to expose timing information for:

prompt construction
↓
capability/tool preparation
↓
request serialization
↓
API request
↓
first token
↓
tool execution
↓
next model turn

If capability preparation or request construction is repeated for every
turn, caching immutable session-level information could potentially remove
a portion of this overhead.

I would also be interested in a benchmark showing:

Number of tools/skills
vs
Request preparation time
vs
First-token latency

The goal is to determine whether unused capability metadata contributes
measurable overhead to otherwise identical tasks.

View original on GitHub ↗