claude-code - 💡(How to fix) Fix Full skill list re-injected on every tool call — token bloat, performance, cognitive load [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#54978Fetched 2026-05-01 05:49:27
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
labeled ×3commented ×2

When skills are loaded in a session, the full skill catalog (description + name + trigger conditions for every available skill) appears to be re-injected as a <system-reminder> on most tool-call results — not just once at session start. On a session with ~32 skills loaded, this is roughly 5k tokens per re-injection.

Concrete data point from a single session:

  • Session total: 249,000 tokens
  • Skill list re-injections observed: ~13+
  • Estimated token cost from re-injection alone: ~65,000 tokens (~26% of total session tokens)

The same harness behaviour likely applies to any other invariant session-scoped content (rules, system reminders, configurations) that the harness re-asserts after every tool call. Skills are the most visible offender because the catalog itself is large.

This is a multi-faceted issue, not just a token cost:

Root Cause

The same harness behaviour likely applies to any other invariant session-scoped content (rules, system reminders, configurations) that the harness re-asserts after every tool call. Skills are the most visible offender because the catalog itself is large.

RAW_BUFFERClick to expand / collapse

Summary

When skills are loaded in a session, the full skill catalog (description + name + trigger conditions for every available skill) appears to be re-injected as a <system-reminder> on most tool-call results — not just once at session start. On a session with ~32 skills loaded, this is roughly 5k tokens per re-injection.

Concrete data point from a single session:

  • Session total: 249,000 tokens
  • Skill list re-injections observed: ~13+
  • Estimated token cost from re-injection alone: ~65,000 tokens (~26% of total session tokens)

The same harness behaviour likely applies to any other invariant session-scoped content (rules, system reminders, configurations) that the harness re-asserts after every tool call. Skills are the most visible offender because the catalog itself is large.

This is a multi-faceted issue, not just a token cost:

1. Behavioural / correctness

The model's behaviour shifts subtly: every tool call now competes for attention with a re-asserted "here are all the skills you could be using". This biases the model toward second-guessing its current trajectory ("should I have used a skill instead?") at points where the sensible answer is just "continue the work". It also amplifies a confirmation bias — re-stated instructions feel authoritative even when they're stale relative to the current task.

2. Performance / latency

Every re-injection extends the request payload sent to the model. On long sessions, the cumulative latency adds up: 13× re-injections of 5k tokens = ~65k tokens of additional input that has to be tokenised, hashed, cached, and billed on every subsequent turn.

3. Cognitive load (model side)

The model has to repeatedly skim a list of names + descriptions that haven't changed since the last time it read them. The actual user content (their last message, the file diffs, the test output) gets diluted in a sea of static boilerplate. This is the same anti-pattern that makes very-long context-windows degrade reasoning quality.

4. Token / usage cost (user side)

The skill list re-inject is invisible to the user but counted against input-token quota and billed. In the observed session, ~26% of total token spend was attributable to repeated skill-list injection alone — content the user did not ask for and the model already had.

Reproduction

Any session that loads the full skill catalog (e.g., one with multiple plugins installed: claude-mem, atlassian-cli, context-mode, etc., plus the default skills) and then makes more than a handful of tool calls. A <system-reminder> containing the full skill catalog appears between consecutive tool results, repeatedly through the session.

Suggested fix

The skill catalog is invariant within a session. Inject it once at session start (or when the catalog actually changes via plugin install / uninstall), not after every tool call. If a periodic nudge toward proactive skill use is desired, inject a much smaller stub ("N skills available — open the skills picker if needed") instead of the full catalog.

Apply the same principle to other invariant session-scoped content the harness currently re-asserts on every tool call.

Environment

  • Claude Code session, Opus 4.7 (1M context)
  • ~32 skills loaded across multiple plugins
  • Long working session (~249k tokens total, multi-hour)

extent analysis

TL;DR

Inject the skill catalog only once at session start or when it actually changes, rather than after every tool call, to reduce token cost and mitigate behavioral issues.

Guidance

  • Identify and modify the code responsible for injecting the skill catalog to only do so at session start or when the catalog changes.
  • Consider injecting a smaller stub to periodically remind the user of available skills, rather than the full catalog.
  • Review other invariant session-scoped content that may be re-asserted unnecessarily and apply the same principle to reduce latency and token cost.
  • Monitor session token usage and model behavior to verify the effectiveness of the fix.

Notes

The suggested fix assumes that the skill catalog is indeed invariant within a session and that injecting it once at session start is sufficient. If the catalog can change dynamically during a session, additional logic may be needed to handle updates.

Recommendation

Apply the workaround of injecting the skill catalog only once at session start or when it changes, as this addresses the root cause of the issue and reduces token cost and latency.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Full skill list re-injected on every tool call — token bloat, performance, cognitive load [2 comments, 2 participants]