[PERFORMANCE] Unused tool and skill metadata adds avoidable latency to every agent turn
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:
- Stable session metadata
- Currently relevant tools
- Task-specific instructions
- 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
- Start Claude Code in a clean project.
- Measure the response time for a simple task that requires only one
basic capability.
- Create a second environment containing a substantially larger set of
available skills/tools.
- Run the same task without changing the model, prompt, or project code.
- Compare the response and first-token latency between the two environments.
- Repeat each test several times to reduce the effect of normal network
and inference variation.
- Repeat the experiment with the same conversation after several tool
calls.
- 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.