The Context-Economy Stack
Headroom is one answer to a bigger question: how do you keep an AI agent's context small, cheap, and relevant? This page places Headroom next to Slim Tools and ECC, shows how the three attack the problem at different layers, how to run Slim Tools and Headroom together, and when ECC should enter the picture.
This page synthesizes three sources with different maturity: the Headroom README (concrete, documented), the Slim Tools guide (whose public documentation is thin — treat its architecture as informed inference), and ECC (Everything Claude Code), a third-party workflow methodology discussed in Claude Code skills. The layering below is an architectural recommendation, not a vendor-certified integration.
1. Three layers, three different problems
Token waste in an agent comes from three distinct places. Each tool targets one:
| Layer | Tool | What it reduces | The waste it removes |
|---|---|---|---|
| Tool surface | Slim Tools | The number of tool definitions and the routing logic the model carries | Long tool catalogs; orchestration pushed into the prompt |
| Payload | Headroom | The size of everything flowing through — tool outputs, logs, RAG, files, history, and optionally output tokens | Verbose content the model reads and writes |
| Workflow | ECC | How the agent operates over time — memory hygiene, hooks, subagents, session mechanics | Unrepeatable, undisciplined operating loops |
The key insight: these do not overlap. They stack.
┌─────────────────────────────────────────┐
Workflow │ ECC — operating discipline │
layer │ memory · hooks · subagents · context │
│ economy as a repeatable practice │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
Payload │ Headroom — compress what flows through │
layer │ tool outputs · logs · RAG · history │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
Tool-surface │ Slim Tools — one MCP endpoint, │
layer │ routing moved out of the prompt │
└─────────────────────────────────────────┘
2. Slim Tools + Headroom, together
They sit at different edges of the request, so you can run both:
- Slim Tools sits at the tool-definition edge. Instead of loading many MCP servers and API integrations into the prompt, the agent gets one MCP endpoint plus a small number of tools, and discovery/routing happens in the runtime. That shrinks the tool-catalog tokens and moves orchestration out of the model.
- Headroom sits at the request/response edge. It compresses the tool outputs that come back, plus logs, RAG chunks, files, and the growing history — and can trim output tokens too.
Run together, the flow is:
Agent → (Slim Tools: one endpoint, routed tools) → tool call
→ tool output → (Headroom: compress output + history) → LLM
Slim Tools cuts the breadth of what the model has to know about; Headroom cuts the depth of what each interaction costs. Neither replaces the other.
A practical caveat. Both add a runtime hop and a trust surface, but not the same kind. Headroom is local-first — its stated model is that data stays on your machine. Slim Tools is a hosted gateway, so its own guide flags open questions about where secrets and OAuth tokens live, tenant isolation, and audit logs (see §11 of the Slim Tools guide). In a data-sensitive environment, that asymmetry matters: adopting Headroom is a lighter trust decision than routing tool traffic through a hosted third party. Evaluate them on that basis, not just on tokens saved.
3. A pragmatic adoption order
- Start with Headroom in proxy or wrap mode. It is drop-in, local, reversible, and lets you measure savings before changing anything. See Proxy and agent wrapping.
- Add Slim Tools only if the tool surface is the bottleneck — i.e. your agents carry too many tools, waste context on tool catalogs, or span multiple providers. If you only use a handful of tools, direct MCP stays simpler (per the Slim Tools guide's own advice).
- Reach for ECC when the pain moves up a layer — see below.
4. When ECC should enter the picture
ECC is not a compression tool and not a code-quality standard. As the Claude Code skills guide puts it, ECC is a workflow operating layer: it adds value on orchestration, memory, context management, hooks, subagents, and session mechanics — "how the system runs across time," not "how code looks."
So the sequencing is deliberate:
- Slim Tools and Headroom are mechanical. They reduce token cost per interaction without changing how you work. Adopt them first; the payoff is immediate and measurable.
- ECC is behavioral. It only pays off once the mechanical layers are in place and your remaining pain is about workflow scale — repeatability across sessions, disciplined memory, hooks, and multi-agent operating patterns.
Add ECC when you can say yes to these:
- Headroom (and, if needed, Slim Tools) are already in place, and per-call token cost is no longer the main problem.
- Your pain is now operational: context drifts across long sessions, memory is ad hoc, subagent roles are undefined, or the same workflow is hard to repeat.
- You want an operating system around the agent, not just cheaper calls.
Do not add ECC when your only goal is basic code quality or one-off cost savings — that is what the mechanical layers already deliver, and importing a whole workflow methodology on top would be overkill. Adopt ECC selectively, in the places you feel operational pain, rather than wholesale.
A dedicated ECC page is planned in this site's Skills section but is not written yet. For now, the practical ECC discussion lives in Claude Code skills, and the source material is the ECC repository.
5. Decision summary
| If your main problem is… | Reach for… |
|---|---|
| Context is huge (tool outputs, logs, history) | Headroom |
| Too many tools; agents drown in tool catalogs | Slim Tools |
| Multi-provider tool sprawl, one shared tool runtime | Slim Tools |
| Workflows are unrepeatable; memory and sessions are undisciplined | ECC |
| Output responses are verbose and expensive | Headroom output-token reduction |
| Data must stay local | Headroom (local-first); be cautious with hosted gateways |