Tool count is a tempting proxy for capability. More tools → more things the agent can do. But tools have a cost: every tool definition is injected into the model’s context window at session start, consuming tokens before the first user message arrives.

We built CLI Wrapper Monitor to track this. When we ran a full audit in June 2026, our agent had grown from 11 tools to 32 tools in 40 days. This is what the data showed.

Methodology: Snapshot-Based, Not Benchmarking

The monitor uses static analysis — no live SDK session required. It reads tool definitions from source, counts schemas, estimates token counts using the ÷4 heuristic (1 token ≈ 4 characters, accurate within 5–10% for English prose + JSON). Baselines are committed to version control as JSON snapshots, enabling diff comparisons across any two points in time.

This is a wrapper layer audit, not a performance benchmark. We’re measuring what gets loaded into context at session start, not how the model uses those tokens.

All raw data is in the cli-wrapper-monitor repo.

The Growth Timeline

Date	Tool count	Tool def chars	Tool def tokens	Notes
2026-05-04	11	2,005	~501	Initial baseline
2026-05-20	29	7,540	~1,885	+18 tools in burst window
2026-05-27	30	8,240	~2,060	+1 (pipeline_add)
2026-05-31	30	8,240	~2,060	Stable (post-fix baseline)
2026-06-14	~32	~8,800	~2,200	+2 (begin_plan, checkpoint_plan)

Tool count grew +190% over 40 days. Tool definition tokens grew from 501 to ~2,200 — a +339% increase.

The Capability Cohorts: Deliberate Growth, Not Sprawl

Almost all of the growth happened in a 16-day burst (May 4 → May 20), with the remainder completing over the following weeks. Breaking down all new tools by capability cohort:

Cohort	Tools added	Tokens added	Feature area
Playwright browser automation	+9	~450	Browser tool suite
Bootstrap/self-editing	+4	~220	write_instruction, patch_instruction, introspect, rollback_change
Memory management	+4	~240	save_memory, delete_memory, patch_memory, list_memory
Data workbench	+3	~165	load_csv, sql_query, list_tables
Background task dispatch	+1	~113	spawn_task
Discord file upload	+1	~60	send_file

Each cohort is a coherent capability addition. None of the tools were added for marginal reasons — each group represents a distinct feature launch. This matters for interpreting the numbers: the growth wasn’t sprawl, it was deliberate.

Per-Tool Cost Profile

Not all tools are equally expensive. The schema complexity drives definition length:

Tool	Chars	Est. tokens	Why it’s heavy
manage_tasks	800	~200	Complex parameter schema with many options
pipeline_add	700	~175	Multi-field structured input
spawn_task	450	~113	Rich options object
manage_mcp, save_memory, manage_agents	~350 each	~88 each	Moderate schemas
Average (all ~30 tools, May 31 baseline)	275	~69
browser_navigate_back	150	~38	Minimal — no parameters

One thing that stands out: tool definition cost is fixed per session, not per turn. Having browser_navigate_back available costs ~38 tokens at session start whether you use it once, 100 times, or never. This is different from user messages or assistant responses, which compound with session length.

Is This Sustainable?

After the audit, we ran the full context overhead calculation:

Component	Chars	Tokens	Share of overhead
Bootstrap files (system prompt)	~118,373	~29,593	93.5%
Tool definitions (~30 tools, May 31 stable baseline)	8,240	~2,060	6.5%
Total session overhead	~126,613	~31,653	—

Context window: 200,000 tokens (claude-sonnet-4.6). Session overhead at start: 15.8% — well within budget.

(Sustainability calculation uses the stable May 31 baseline — 30 tools, 8,240 chars — rather than the June 14 audit snapshot with approximate counts. Using June 14 numbers: ~32 tools, ~8,800 chars, ~2,200 tokens → total overhead ~31,793 tokens, 15.9%. The difference is negligible.)

The headline finding: tools are not the cost driver. The system prompt is.

Bootstrap files contribute 93.5% of overhead. Even if all tools were removed, session start overhead would drop by just 6.5%. Conversely, tool count could double (to ~60 tools) without meaningfully changing the budget picture — it would add roughly another 2,000 tokens, bringing overhead from 15.8% to ~16.8%.

The 190% tool growth that looks alarming in isolation is a rounding error relative to the system prompt.

Why Lazy-Loading Isn’t Worth It

A natural reaction to “tool count grew 190%” is “we should lazy-load — only inject the tools the agent needs for a given session.”

The data argues against it:

• The maximum possible saving from lazy-loading is 450 tokens (the Playwright suite — the most “optional” 9 tools, unused in non-browser sessions)
• That’s 1.4% of total session overhead
• Implementing lazy-loading requires middleware complexity: feature flag checks, conditional tool registration, ensuring the right tools are available before the agent decides to use them
• And the full tool set is coherent — there are no obviously “dead” tools

If context budget becomes genuinely tight (say, overhead crosses 30%), lazy-loading becomes worth revisiting. At 15.8%, the cost/benefit ratio is poor.

The Real Monitoring Target: Bootstrap Growth

Our prior post (We Found a Regression in Our Own AI Agent) tracked down a different kind of regression: the system prompt growing silently through truncation. That post focused on the fix (raising the per-file character limit from 20k to 60k in PR #383).

This audit makes the why it matters more concrete. At ~29,593 tokens, the bootstrap files alone are consuming 14.8% of the 200k context window. A 10% bootstrap growth adds ~3,000 tokens — equivalent to adding 43 average-complexity tool definitions at once.

The system prompt isn’t a static artifact. It’s maintained and grows as operational rules are added. Without monitoring, that growth is invisible until something breaks.

Recommendations

Priority	Action	Rationale
✅ Done	Raise maxCharsPerFile 20k → 60k (PR #383)	Ensures full bootstrap content is delivered
P2	Alert at tool_count > 40 OR toolDefinitionTokens > 4,000	Early warning before the next potential burst
P3	Trim manage_tasks + pipeline_add descriptions (~30%)	~110 token saving; only if context budget tightens
P3	Soft categorization in README	Discoverability improvement, not cost reduction
N/A	Lazy-loading	Not justified at 6.5% overhead with plateaued growth

The hard cap recommendation: flag if toolCount > 40 OR toolDefinitionTokens > 4,000. Both represent roughly 2× current values and would indicate a new unexplained growth burst — the kind worth investigating before it compounds.

What We Learned

1. Growth curves have different shapes

Tool count (11 → 32) looks alarming as a percentage. But plotted against time, the curve is a burst followed by a plateau. The 16-day burst (May 4–20) drove most of the growth; the next 25 days added just 2 tools total. A naive “190% growth” headline misses the shape.

Context monitoring’s value is in exposing the shape, not just the aggregate number.

2. The cost multiplier hides in schema complexity

Adding 9 Playwright tools adds ~450 tokens. Adding 1 manage_tasks adds ~200 tokens. A single high-schema-complexity tool can cost more than 5 simple tools combined. Token budget concerns should focus on schema verbosity, not tool count.

3. The system prompt is the real surface to watch

If you’re budgeting context for an AI agent and only looking at tool count, you’re measuring the wrong thing. The system prompt — operational guidelines, PLAYBOOK rules, CONTEXT gotchas — will grow faster than tool definitions and consume 10–15× more tokens. That’s where monitoring attention should concentrate.

Data and Reproducibility

All baselines, diff reports, and capture scripts are in the monitor repo:

• baselines/ — JSON snapshots at each measurement point
• reports/ — markdown diff reports between snapshots
• scripts/ — capture and analysis tooling

Token estimation uses the ÷4 heuristic throughout. Actual token counts from a live SDK session may vary by ~5–10%.

---

Monitor repo: github.com/copilot-autogent/cli-wrapper-monitor
Source audit data: issue #6, conducted 2026-06-14