Token Tax with HVE Core Installed

[Trinanjan90]

When we install HVE Core in VS Code, we see that there is a context tax that is induced even when we are not using any HVE Core Specific agents. Is there any specific guidance on the same or recommended approach to avoid the same?

[WilliamBerryiii]

Honest acknowledgement

Before getting into the mechanics: you're right that there is a real token tax, and we know it. HVE Core has grown quickly — agents, prompts, skills, and instruction files have all expanded as the framework matured — and we have not yet done a focused pass to optimize the always-on context cost. Specifically:

• The instruction/agent/skill index that gets advertised to the model on every request has grown well past the size we'd choose if we were designing it from scratch today.
• Several copilot-instructions.md sections include content that could reasonably move into scoped .instructions.md files with applyTo globs, so it would only load when relevant.
• The hve-core-all collection in particular bundles everything, which is convenient but is the worst case for context cost.
• We don't yet publish per-collection or per-extension token-cost numbers, which makes it hard for users to make informed install decisions.

This is on our roadmap. A context-optimization effort — measuring the cost, splitting unconditional content into scoped instructions, trimming descriptions in the index, and giving users finer-grained collection choices — is something we're committed to. This discussion is exactly the kind of signal that helps us prioritize the work.

In the meantime, here's how the system works today and what you can do to reduce the cost on your side.

How instructions files load (and why you see a token tax)

VS Code Copilot loads agent customization files in two different ways, and this is the main source of the overhead:

1. copilot-instructions.md — always injected into every prompt for every agent in the workspace, no matter what you're doing. In hve-core this file is comprehensive (project structure, script operations, coding-agent environment, npm script catalog, etc.).
2. .instructions.md files with an applyTo glob — conditionally injected. The Copilot client matches the applyTo pattern against files attached to (or referenced by) the current request. When a match occurs, that instruction file's body is added to the prompt context.

The coding-standards files under .github/instructions/coding-standards/ all use targeted applyTo patterns:

File	applyTo
csharp.instructions.md	**/*.cs
powershell.instructions.md	**/*.ps1, **/*.psm1, **/*.psd1
python-script.instructions.md	**/*.py
bash.instructions.md	**/*.sh
terraform.instructions.md	**/*.tf, **/*.tfvars, **/terraform/**
bicep.instructions.md	**/bicep/**
pester.instructions.md	**/*.Tests.ps1

So a coding-standards instruction file only contributes tokens when you actually touch a matching file. If you're editing .cs, you pay for the C# rules; if you're editing .py, you pay for Python. You do not pay for all of them at once.

What is unconditional (the real tax)

Even with applyTo scoping, the agent still pays for:

• The full copilot-instructions.md body.
• The index of every .instructions.md file in the workspace (description + applyTo + file path) — so the model knows what's available to pull in. With ~100+ instruction files in hve-core, this index alone is sizable.
• The index of every available agent and skill (name + description).
• Any applyTo: "**" files, which always match. In hve-core that's hve-core-location.instructions.md (small, intentional).

Recommendations to reduce the tax

If you want hve-core's framework artifacts (agents, prompts, skills, RPI workflow) but not the coding-standards overhead, install a smaller collection instead of hve-core-all:

• hve-core — core agents/prompts only
• Topical collections like ado, github, security, design-thinking, etc.
• coding-standards — only install if you want language-specific rules

Each collection ships as a separate VS Code extension, so you can install just the slices you need rather than hve-core-all. That directly cuts the instruction/agent/skill index size, which is the largest fixed component of the per-request token cost.

Impact summary

Component	Cost	When paid
copilot-instructions.md	Fixed, large	Every request
Instruction index (descriptions + applyTo)	Fixed, scales with file count	Every request
Agent/skill index	Fixed, scales with count	Every request
Coding-standards body (per language)	Variable	Only when matching file is in scope
applyTo: "**" files	Fixed, small by design	Every request

The biggest lever for reducing context cost today is installing only the collections you use, not removing or rewriting individual instruction files. The biggest lever tomorrow is the optimization work we owe you on our side.

Disabling the extension when you don't need it

Because every installed Copilot customization extension contributes to the always-on context (its agents, prompts, and instruction index are advertised to the model on every request), the most effective lever for eliminating the token tax is simply turning the extension off when you're not using HVE Core for the current task.

VS Code supports both global and per-workspace disable, which lets you keep HVE Core handy without paying for it everywhere:

• Disable in this workspace — in the Extensions view, find the HVE Core extension (or the specific collection extension you installed, e.g. hve-core-all, coding-standards, ado), click the gear icon, and choose Disable (Workspace). The extension stays installed and enabled for other repos but contributes zero context here. This is the recommended setting for repositories where you never use HVE agents.
• Disable globally — same menu, choose Disable. Re-enable on demand when you want to run an HVE workflow (RPI, Security Planner, DT Coach, etc.).
• Reload required — VS Code will prompt to reload the window after toggling. The context drop takes effect on the next Copilot request.
• Command Palette shortcut — Extensions: Disable and Extensions: Enable accept the extension by name, which is convenient if you flip it on and off frequently.

A practical pattern many users adopt:

1. Install only the collection extensions you actually use (not hve-core-all).
2. Keep them disabled by default at the workspace level in repos that don't need them.
3. Enable on demand when starting an HVE-driven workflow, then disable again when finished.

This gives you full HVE capability when you want it and a clean, untaxed Copilot context the rest of the time — and we'll keep working on shrinking the baseline so the trade-off matters less over time.

[ShahabName]

Thanks for the info. Very useful, detailed and of high value and impact for teams using HVE Core.

[Trinanjan90]

Thanks for the detailed explanation. This definitely helps knowing the alternatives and something that's in the charter.