Proposal: cut the always-loaded context cost with a lean default install (~24K to ~7K)

[gaurav0107]

Hi. I have been measuring how much context ECC costs per session, and I think there is a clear win available in the default install. I wanted to float it here before writing any code, since part of it is a direction call that is yours to make.

The short version

Every ECC user pays a fixed cost on every session: the name and description of each installed skill, agent, and command is injected up front so the model can discover them. On a full install that is roughly 24K tokens before you type anything. Skill bodies are already lazy and only load when a skill actually fires, so this is purely the discovery metadata.

Measured on a current checkout (about 278 skills, 67 agents, 94 commands):

• skill descriptions: about 15.7K tokens
• agent frontmatter: about 5.1K tokens
• command frontmatter: about 3.2K tokens

I believe the default can get down to roughly 5 to 7K without removing any capability, keeping everything else available as opt-in.

Why the current profiles do not already fix this

Two reasons.

1. Two modules are all or nothing. Even the leanest profile (minimal) pulls agents-core and commands-core in full, which is all 67 agents (about 5.1K) and all 94 commands (about 3.2K). So the floor today is about 11K no matter which profile you pick, and most of that floor is those two blobs. framework-language has the same shape: one module covering every language, so a Python user still loads Kotlin, Laravel, and Quarkus skills.

2. The marketplace path ignores profiles. plugin.json declares "skills": ["./skills/"] and "commands": ["./commands/"], so a /plugin install loads every skill and command regardless of profile. To make that channel lean, the marketplace itself needs to be a core plugin plus optional companions.

This builds on work you already started

This is not a new direction, it is making an existing one systematic. The 2.0 release notes already mention slimmer defaults: rules/zh was moved out of the always-loaded default (#2170) and hooks-runtime was gated for OpenCode (#2140). ECC also already ships a context-budget skill that audits context consumption across agents, skills, MCP, and rules and recommends savings. What is missing is a lean default by construction, the module splits that make it possible, and a CI budget that reuses context-budget's measurement so the default cannot quietly grow back.

What I am proposing

The plan, ordered by leverage

1. Split the monolithic modules. agents-core becomes about a dozen general agents (planner, code-reviewer, architect, build-error-resolver, tdd-guide, refactor-cleaner, and similar) plus opt-in language and domain agent modules for the reviewers and build resolvers. Same core and extended split for commands-core. framework-language splits per language. This is additive: as long as full still expands to everything, nothing changes for existing installs.

2. Add a lean profile (working name starter) and make it the recommended default. It carries the core agents and commands, the quality workflow skills, rules, hooks, and platform config. Breadth stays one flag away with --profile full or --modules.

3. Split the marketplace plugin into a core plugin plus optional companions, so the /plugin install path can be lean too.

4. Project aware language selection. Detect the stack at install time (package.json, requirements.txt, go.mod, Cargo.toml, pom.xml) and pull in only the matching language module. A Python repo gets Python skills, not all of them. This overlaps with the relevance ranking idea in feat: rank SessionStart-injected instincts by project/stack relevance; make injection count + confidence threshold configurable #2371.

5. Tighten the descriptions that remain in the default. Only about 70 descriptions survive into the lean profile, so this is a small and high value pass.

6. Add a token budget CI guard. Reuse the measurement already in the context-budget skill, wrap it as a CI check, and fail the build if the default profile goes over budget. This also catches the class of bug in install-modules.json is missing 79 curated skills (including all 6 from the latest wave) — ecc-install --profile full silently skips them #2431 where skills silently drop out of the manifest.

Target: the default install goes from about 24K to about 5 to 7K, with a CI cap around 8K. No capability removed, and native discovery stays intact for whatever is installed.

How I would ship it

Small PRs rather than one big one, so each is easy to review and reverse:

• measurement first (the budget tool, no behavior change, also flags install-modules.json is missing 79 curated skills (including all 6 from the latest wave) — ecc-install --profile full silently skips them #2431 style gaps)
• split the modules (additive, full still pulls everything)
• add the starter profile (opt-in)
• flip the default (tiny diff, this is the one that needs your sign-off)
• marketplace split
• auto detect and description cleanup as fast follows

What I need from you

These are the calls I cannot make on your behalf:

1. A new starter profile, leaving core, minimal, and full as they are?
2. A hard CI cap on the default. I would suggest 8K always-loaded.
3. Should the default carry zero language modules and rely on auto detect, or bundle the two or three most common (js and ts, python)?
4. Marketplace split now, or land the installer side first and treat the split as a fast follow?

If the direction sounds right, I am happy to write it up as a docs/proposals doc and open the measurement PR first. Related prior work and issues: #2170, #2140, #2431, #2371, and docs/SELECTIVE-INSTALL-ARCHITECTURE.md.

[makslanies]

We ran paired evaluations while adapting selected ECC capability packs for another production agent platform.

A tdd-workflow pilot across 6 paired tasks (including 2 held-out tasks) produced an average +0.20 quality delta, but also added about 20.97 seconds and 74,473 processed tokens per measured task. Selective activation kept the quality gain without making the workflow part of the always-on path.

We also found that not every reviewer pack justified its runtime/context cost: a security-reviewer pilot produced 0.00 quality delta across 3 paired tasks (2 held-out), so we retired it instead of enabling it by default.

This seems to support the lean-default proposal, with one additional measurement layer:

1. measure always-loaded discovery cost;
2. measure marginal execution cost and held-out quality lift after activation;
3. keep a pack in the default only when its measured lift stays positive within explicit token and latency budgets.

That would let a CI/eval gate catch both context growth and capabilities that are valid in principle but do not add value for a particular default profile. If useful, I can share an anonymized evidence schema or prepare a small measurement-focused PR.