Caveman is one of the fastest-growing projects in the AI tooling world right now: created in April 2026, it passed 100,000 GitHub stars in under five months. Its pitch is irresistible — "why use many token when few token do trick" — and its numbers are real: a compression proxy that cuts input tokens by ~33%, a skill that trims agent output by ~65%, and a browse mode that shrinks accessibility-tree queries by two orders of magnitude.
We run a fleet of roughly twenty autonomous Claude Code lanes — build pipelines, code-review lanes, QA sweeps, scheduled board runners — that operate around the clock, largely unattended. Token spend across that fleet is a real line item. So when a tool promises to cut it by more than half, we evaluate it seriously. We did, and we decided not to deploy it. This post explains why, because the reasoning matters more than the verdict — and because one idea from Caveman survived the review.
What Caveman actually is
Caveman ships two distinct products under one name, with two different licenses:
- The skill (MIT-licensed): instructions that make the agent's own responses terse. Fewer pleasantries, compressed phrasing, "caveman speak." This is where the headline ~65% output-token saving comes from.
- The proxy (BSL-1.1-licensed): a local Go binary that sits between your coding agent and the model provider. It detects content types — JSON, logs, diffs, search results, browser accessibility trees — and compresses them before they enter the model's context window, with byte-exact recovery on the way back.
Both work. The benchmarks are credible, the project is actively maintained, and the engineering is genuinely clever. None of our objections are about quality.
Reason #1: verbatim-text pipelines break under compression
This was the decisive one. An autonomous agent fleet is held together by exact text: memory files with rules that must be quoted verbatim, ticket comments that future runs search for specific phrases, structured reports that downstream sessions parse, incident postmortems whose precise wording encodes what went wrong. In an interactive session, a human reads a terse summary and fills in the gaps. In an unattended pipeline, there is no human — the next agent acts on exactly what the previous one wrote.
Our own incident history is full of cases where a slightly imprecise report caused a wrong action days later. A style layer that systematically compresses agent prose is a machine for generating those incidents. The 65% saving on output tokens is real; so is the cost of a pipeline that misfires because "deployed to staging, QA pending, do not promote" got compressed to "deployed."
The general lesson: token optimization is workload-dependent. Terse output is nearly free in a human-in-the-loop session and actively dangerous in agent-to-agent handoffs. Any team running autonomous agents should classify their sessions along that axis before installing any output-shaping tool.
Reason #2: the proxy sits on your credential flow
The Caveman proxy wraps the agent's entire conversation with the provider, including OAuth-authenticated sessions. That means every request — including sessions that touch client data, internal credentials, and production infrastructure — flows through a third-party binary installed via a shell script with hooks into the agent's configuration.
For a hobbyist setup, that's a reasonable trade. For an agency running client workloads under a strict security framework, it's a supply-chain exposure we can't justify for a cost optimization — and interposing on a provider's authenticated flow lives in terms-of-service gray territory we have no interest in occupying. This objection is permanent: no version bump fixes an architectural trust problem.
Reason #3: the license split matters if you redistribute
The skill is MIT, but the engine, proxy, and MCP server are BSL-1.1 (converting to Apache 2.0 around 2030). Internal use is fine; redistribution is not. We maintain a public plugin marketplace, so anything we adopt tends to want to flow outward into packaged tooling — and the useful half of Caveman is exactly the half we couldn't ship.
Reason #4: "learn" mode reads your history
Caveman's learn command analyzes your agent transcripts to find token sinks. It's a great feature — and a non-starter on machines where transcripts contain client PII and credential-adjacent material, at least until someone audits precisely what it reads and where anything is sent. We didn't get that far, because reasons 1–3 had already decided the question.
The one idea we kept: ARIA-tree compression for QA
Buried in Caveman's feature list is its best idea: compressing browser accessibility trees before they enter the context window, with a claimed 129.8× reduction. Anyone who has run browser-automation QA with an AI agent knows why that number is plausible — ARIA snapshots of real-world pages are enormous, deeply repetitive, and mostly irrelevant to any single assertion.
We're not installing Caveman's binary for this. We're stealing the technique: a pre-compression step in our own Playwright QA harness that prunes and deduplicates the accessibility tree before the agent sees it. That's a contained, auditable change in code we own — all of the benefit, none of the trust surface.
How we decide (and how you should)
Our evaluation checklist for any tool entering an autonomous fleet, in the order that kills fastest:
- Does it touch the credential path? If yes, the bar becomes "would we write this ourselves" — not "is it popular."
- Does it alter text that other machines act on? Compression, summarization, and reformatting are all mutations. Unattended pipelines are allergic to mutations.
- Can we adopt the idea without the dependency? Often the answer is yes, and the idea is the valuable part.
- Does the license permit where the code will actually end up? Check before integrating, not after.
A hundred thousand stars answer none of those questions. Popularity is evidence that a tool solves a real problem — it is not evidence that it solves your problem safely.
If your team is building or operating AI agent systems and wrestling with exactly these trade-offs — cost, safety, and autonomy — that's the work we do every day at MSApps and OpsAgents. Talk to us.