Feature request: skill catalog injected once per session, not after every tool result

Resolved 💬 1 comment Opened May 11, 2026 by Vermeij Closed Jun 10, 2026

Feature request: skill catalog injected once per session, not after every tool result

Summary

Claude Code currently injects the full skill catalog (~50 skills × 1-3 lines each, ~4500 tokens per injection) as a <system-reminder> block after most tool results (Edit, Bash, Write, Read), not only after Skill tool calls. In a production agentic-coding session this fires 30+ times → ~135k tokens, which is approximately 38% of the message context budget at the 38% /context snapshot.

Requesting: inject the catalog once per session (on first SkillTool-eligible turn) OR de-duplicate consecutive identical injections OR replace with a single /skills pointer that the agent can invoke on demand.

Measured baseline (Qapnova production session, 2026-04-28)

From a real session captured in our internal failure log:

  • /context snapshot at 38% (384.6k / 1M tokens used)
  • Messages = 352k tokens (35.2% of 1M window)
  • Walking the message log: same skill-catalog reminder block injected 30+ times in the session
  • Each block: ~4500 tokens
  • Aggregate: ~135k tokens spent on repeated catalog injections
  • Net: ~38% of the entire message context, ~13.5% of the 1M window — just from this passive reminder

Distinct from skill-BODY re-injection on Skill tool invocations (separate failure-log entry in our system, 2026-04-26-context-leak-skill-body-re-injection-on-repeated-invocations). That issue has been mitigated for us via skill-file rewrites that avoid re-loading bodies. The CATALOG injection is upstream of any user-level remediation.

Why this is structurally costly

Each catalog injection is byte-identical to the previous one in the same session (the available-skills list rarely changes mid-session, except when a skill is dynamically registered). The repeated injections are pure prompt-cache invalidators when they land between cache breakpoints AND raw token cost when they don't.

For a heavy-edit session (typical ADR sub-PR implementation):

  • ~50-80 tool calls
  • ~30 of those trigger the reminder
  • Catalog cost dominates the "system-reminder" surface

Net: this is the largest unaddressed structural context leak we have measured. Larger than failure-log loading, larger than CLAUDE.md re-injection, larger than MCP tool definitions.

Suggested remediations (in order of preference)

  1. Inject once per session, on first SkillTool-eligible turn. Drop subsequent injections. The agent has the catalog in its working memory after the first read — re-injecting is the harness assuming the agent forgot, which is not the typical failure mode.
  1. De-duplicate consecutive injections. If the catalog hash matches the previous injection, suppress the duplicate. Re-inject only when the catalog content actually changes (new skill registered).
  1. Replace catalog with a pointer. Inject a one-line "Available skills: invoke /list-skills to retrieve" reminder. The agent fetches the catalog on demand via a tool call. Cost shifts from passive injection to active retrieval — only paid when actually needed.

Suggested instrumentation

A telemetry counter incremented every time the harness injects the skill-catalog system-reminder, exported under (proposed) metric name harness.context.skill_catalog_injections_per_session. SLO target after remediation: p95 ≤ 3 injections per session over 30-day rolling window.

Distinguishing this from related issues

  • Distinct from skill-BODY re-injection (skill body reloaded when Skill tool invoked) — that is a separate item.
  • Distinct from tool-definition injection (MCP tool schemas) — those are typically cache-stable per session.
  • Distinct from CLAUDE.md / MEMORY.md re-injection — those are typically once-per-session.

The skill catalog is unique in being a frequent, content-stable, non-deduplicated injection.

Reference reading

Happy to provide more concrete usage data, /context snapshots, or telemetry traces if useful.

🤖 Filed by Claude Opus 4.7 (1M context) acting on behalf of the Qapnova engineering team.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗