Plugin skills don't support `disable-model-invocation` like user skills do

Open 💬 11 comments Opened Feb 1, 2026 by johnzfitch

Summary

User-defined skills support disable-model-invocation: true in YAML frontmatter to hide them from the model's auto-detection. Plugin-defined skills lack this capability, forcing all plugin skills into context regardless of relevance.

Environment

  • Claude Code version: 2.1.29
  • OS: Arch Linux 6.18.3

The Problem

User Skills (works)

# ~/.claude/skills/my-skill/SKILL.md
---
name: my-skill
description: Does something specific
disable-model-invocation: true
---

Result: Skill hidden from model, only invokable via /my-skill

Plugin Skills (doesn't work)

# ~/.claude/plugins/my-plugin/skills/my-skill/SKILL.md
---
name: my-skill
description: Does something specific
disable-model-invocation: true  # ← Ignored
---

Result: Skill still appears in context, disable-model-invocation has no effect

Context Overhead

From /context command with several plugins installed:

| Source | Tokens |
|--------|--------|
| Plugin skills | ~2,000 |
| Plugin agents | ~2,400 |
| Total plugin overhead | ~4,400 |

This overhead is included in every request, with no way to reduce it short of disabling entire plugins.

Impact

  • Can't create "manual-only" plugin skills (invoked via /skill-name only)
  • Plugin authors can't optimize context usage for their users
  • Users must choose between plugin functionality and context efficiency

Expected Behavior

disable-model-invocation: true should work identically for:

  • User skills in ~/.claude/skills/
  • Plugin skills in ~/.claude/plugins/*/skills/

Proposed Solution

  1. Parse disable-model-invocation from plugin skill frontmatter
  2. Exclude matching skills from model context
  3. Keep skills invokable via /plugin:skill-name syntax

Workaround

Currently none. Users must either:

  • Accept the context overhead, or
  • Disable the entire plugin

Skill Index Pattern (partial workaround)

Create one auto-detect skill that lists all others:

  • 1 skill in context (~26 tokens) vs 20+ skills (~2K tokens)
  • Other skills invoked manually via /skill-name

This requires plugin authors to restructure their plugins.

---

Token Impact

Per-Request Overhead

This overhead is included in every request, not just when using plugins:

| Requests/Session | Plugin Overhead | With disable-model-invocation* |
|-----------------|-----------------|----------------------------------|
| 10 | 44K tokens | ~11K tokens |
| 50 | 220K tokens | ~55K tokens |
| 100 | 440K tokens | ~110K tokens |

*Assuming 75% of plugin skills marked as manual-only

Monthly Cost at Scale

| Sessions/Month | Current Overhead | Optimized | Savings |
|----------------|------------------|-----------|---------|
| 100 | ~$66 | ~$17 | $49 |
| 500 | ~$330 | ~$83 | $247 |
| 1000 | ~$660 | ~$165 | $495 |

(Based on Sonnet input pricing: $3/1M tokens)

---

Related Issues

  • #22335 - LSP plugins spawn eagerly regardless of file types
  • #22344 - Subagent system prompt bloat
  • #13605 - Custom plugin subagents cannot access MCP tools

View original on GitHub ↗

This issue has 11 comments on GitHub. Read the full discussion on GitHub ↗