11 — Extended comparison axes

Pages 01–07 compared the four tools on what they do, how they work, and what they save. This page adds the six axes the earlier passes never set side by side — the ones surfaced by the gap analysis: security/privacy, project health, interaction with Claude Code's own context management, build-vs-buy, subscriber economics, and non-coding behavior. Repo stats are a fresh gh api pull (2026-06-20); external claims carry sources; reasoned (not measured) calls are labeled.

(a) Security, privacy, and supply-chain

The tools sit on a surface-area gradient that is roughly the inverse of their reach gradient — except lean-ctx, which is broad-reach yet local-first-by-default, so its surface depends heavily on which opt-in features you enable.

Verdict. Caveman has the smallest surface (a prompt). RTK is next (deterministic, local, tiny binary — but a hook write and the #886 permission concern). lean-ctx and headroom are the two large surfaces, for different reasons: headroom by egress (an ML proxy that sees everything) and a mandatory model download; lean-ctx by footprint (the biggest binary, the most subprocesses, host writes across dozens of agents) — but lean-ctx is local-first by default with no telemetry and a deterministic core, so its egress/ML risks are opt-in, whereas headroom's are on by default in proxy mode. For a security-conscious container: caveman freely; RTK with #886 checked and telemetry off; lean-ctx only in MCP + shell-hook mode (no proxy, no cloud sync), version-pinned, with all host writes scoped into the container; headroom only in MCP/library mode with the model pinned.

(b) Project health and sustainability

Stars are PR-inflated for three of the four and ignored here. The real signals (gh api, 2026-06-20):

Verdict. None is a mature, multi-maintainer project; all four are fast-moving solo/small efforts riding a 2026 hype spike. RTK's 1,260 open issues signal adoption outrunning triage (or thin maintenance); lean-ctx's 13 open issues signal the opposite — either tight triage or simply far less adoption (2,800★ vs 30–74k). Two have funded paths (RTK Cloud, LeanCTX Cloud); lean-ctx's open-core is the cleaner of the two — the local engine is Apache-2.0 and its "free forever" is stated as a CI-enforced invariant, whereas RTK Cloud has the classic risk of features migrating behind the paywall. But lean-ctx is also the youngest (created 2026-03) with the broadest surface to maintain, so its bus-factor risk is real. For a container that pins versions, pin a known-good version of any of the four and re-verify on upgrade — most acutely for lean-ctx, whose fast cadence and large surface make doc drift and regressions likeliest. (Reasoned from repo metrics; not a measured reliability study.)

(c) Interaction with Claude Code's native context management

Claude Code already ships context-management features that touch the same tokens these tools target. Do the tools conflict or compose?

Verdict. Caveman composes cleanly with everything (output-side). RTK composes (upstream of all of them). lean-ctx composes in MCP + shell-hook mode — and uniquely complements compaction with its session-survival snapshot — but its proxy, like headroom's, is a second stabilizer that can fight Claude Code's own caching/compaction. Headroom's proxy is the most conflict-prone. The repeated lesson: for both runtimes, use MCP/hook and avoid the whole-prompt proxy in front of Claude Code. And: microcompact already does, for free, a slice of what all three input tools charge reach/ML/footprint for — measure the incremental win over native microcompact, not over a naive baseline.

(d) Build-vs-buy: the spectrum from a 5-line style to a daemon runtime

Mechanically, caveman is a Claude Code output-style plus two hooks — so hand-rolling its core is a ~5-line file. lean-ctx is the opposite extreme: you cannot hand-roll a property graph + RRF search + LSP + CCP memory. The four span the whole build-vs-buy spectrum.

Verdict. For pure output compression, a hand-written output-style is leaner and lower-risk than the caveman plugin (no hooks, no ~940-tok rent) — buy the plugin only for the ecosystem/UX. For shell compression, RTK's "buy" is justified by its 100+-command coverage over a hand-written filter. For the code graph + memory + verification, lean-ctx is the only "buy" available — those capabilities are genuinely not hand-rollable, which is the strongest single argument for adopting it if you need them. The spectrum: build the output style, buy RTK's patterns, buy lean-ctx's runtime only when you need what cannot be built cheaply. (Reasoned from the teardowns; token deltas in the harness backlog.)

(e) Subscriber economics — tasks-per-cap ranking

For a Max-plan subscriber, dollars below the cap are sunk; the objective is tasks-per-cap — how far each tool stretches the 5-hour window (dossier chapter 41). This re-orders the $-per-task recommendation.

• The window fills with input volume — and page 10 measured 94% of token volume here is cache-read. Reducing what gets written (and thus later re-read) extends the window; reducing output (caveman's target, 0.9% of volume) barely moves it.
• So for window extension: headroom ≈ lean-ctx (broad input) ≳ RTK (Bash input) ≫ caveman (output) — the inverse of the $-per-task lean stack. lean-ctx's ~13-token cache-handle re-reads directly cut re-read volume, the dominant occupancy cost, so it is as strong a window-extender as headroom (and stronger on code-read-heavy work). The community "30 min → 3 hr session" headline is a tasks-per-cap/occupancy win, not a dollar cut, and it is driven by the input tools, not caveman.
• Caveat (not proven): the cap's token denominator and exact cache-read weighting are unpublished (dossier chapter 41, bounded INCOMPLETE); cap cache-read weight is community-triangulated at ≈0.1× (T3). The direction (input tools extend the window most) is solid; the magnitude is not.

The metric you optimize flips the ranking. State which one you are on before picking a tool.

(f) Non-coding / multi-domain behavior

All four are benchmarked on coding; their behavior off the code path is uneven, and it inverts the usual ranking.

Verdict. Caveman generalizes best (its lever is prose, useful anywhere output is verbose). Headroom is second (typed compressors cover logs/JSON/HTML/RAG, not just code). RTK and lean-ctx are the most code/dev-bound — RTK because it keys on dev commands, lean-ctx because its compression strength is code (it barely touches prose/config, as measured on page 10). So for a non-coding agent (research, data, ops) the ranking is caveman ≳ headroom ≫ RTK ≈ lean-ctx; lean-ctx's edge (the code graph) is precisely a code feature, which is no help off the code path. (Reasoned + the page-10 measurement; no broader non-code benchmark run.)

Summary: how the rankings move by axis

No tool wins every axis — the hub's thesis restated from six new angles: they specialize (and lean-ctx consolidates, at a footprint cost), and the "best" one is the one matched to your axis (workload, metric, threat model). The overview and combining pages turn that into a stack-or-runtime decision.

---

Back to the overview · gaps & open questions.