Communication

/caveman

Caveman mode: when shorter output actually helps.

01

The cost of a long answer

Sometimes you need the fix, not the preamble

Ask a coding agent for one failing line and it may give you a tour of the framework first. That can be useful while learning. When you already know the system and need the next action, it becomes reading, latency and output-token overhead.

Caveman is an open-source skill that instructs an AI coding agent to answer in short fragments, remove conversational filler and preserve code, commands and errors. Its slogan is deliberately playful: why use many token when few token do trick. The serious question is not whether shorter is better. It is which information may be removed safely.

02

A complete example

Compression works when the success condition is clear

Consider a precise review task: “Check the expiry condition in auth.ts. A token expiring at the current instant must be rejected. Preserve the missing-token path and name the boundary tests.” A normal answer might explain comparison semantics, restate the requirement and then propose the patch. A compressed answer can carry the action in one line: auth.ts:42: use expiresAt <= now; tests before/at/after; preserve missing-token path.

The result is complete because the task supplied an explicit boundary and the reply retained the file, operator, tests and non-regression constraint. The repository's separate React illustration shrinks 69 tokens to 19. That is a project-authored example, not proof that every omitted sentence was dispensable. For a security sign-off, we would still need clock source, skew, units, error behaviour and audit consequences. Brevity is safe only when the acceptance criteria survive it.

Judge compression by what survives

The compressed reply is useful only if it retains every acceptance criterion needed for the decision.

Must survive

  • File and boundary auth.ts:42 and expiry at the current instant
  • Exact change Use expiresAt <= now
  • Tests Before, at and after the boundary
  • Non-regression constraint Preserve the missing-token path

shorter is conditional

May still be needed

  • Clock source and skew Required for a security sign-off
  • Units and error behaviour A terse patch can hide operational assumptions
  • Rationale and audit impact Durable decisions need enough explanation to remain reviewable

Compression succeeded here because the task supplied a complete boundary.

Retention beats token countDo not ask whether the answer became shorter. Ask whether a reviewer can still reconstruct the requirement, change and proof.
03

How the compression happens

It changes the output style, not the underlying files

Caveman is a prompt skill. It adds rules that tell the model to drop filler, prefer fragments and leave code, commands and errors unchanged. It does not mechanically compress the input or hidden reasoning tokens. The agent simply emits a shorter response. A local stats command can read session logs, although the repository says its counter estimates the without-Caveman baseline.

A separate command rewrites persistent instruction files such as CLAUDE.md. That can reduce what loads into a future session's context window, but it is a different operation with a higher cost of error. Compression can erase rationale, exceptions, ownership, priority and the exact language of a policy. Paths and code may remain intact while the reason behind them disappears. Review the diff against the source and keep the original under version control. A smaller file also does not guarantee better use of context, as the dumb-zone discussion explains.

Compress disposable explanation aggressively. Compress durable instructions only when every constraint, exception and decision owner can be verified in the diff.

04

Choose by consequence

The right level depends on what the answer must carry

The repository offers four compression levels, and the selection can last for the session:

  • lite: drops the obvious filler, stays readable.
  • full: the default caveman style.
  • ultra: telegraphic, maximum compression.
  • wenyan: classical Chinese, intentionally translated.

Use ultra for known commands, status checks and narrowly specified fixes. Use full for routine implementation where tests define success. Prefer lite or normal mode for design, teaching, incident analysis, security, policy and any decision where assumptions or alternatives matter. If you cannot state what must survive the compression, do not compress yet.

05

What the numbers establish

Useful project receipts, not independent proof

The project reports a 65% average output-token reduction across ten Claude API prompts, with a 22% to 87% range, compared with default verbose replies. It reports 46% average input-token reduction across five memory-file examples, for those files only. These are maintainer benchmarks with committed harnesses, not independent evaluations, and they do not demonstrate equal accuracy across arbitrary work.

The conditions matter. Caveman's own documentation says the skill rules add roughly 1,000 to 1,500 input tokens per turn. It therefore reports smaller whole-session savings than the 65% headline and warns that terse workloads can become net-negative. Per-request pricing may not fall at all. Explanation-heavy answers have more removable language; code-heavy answers have less. The chart below visualises the project's self-reports, not a universal expectation.

The project's headline savings have an input cost

These are maintainer self-reports. They describe selected benchmark conditions, not guaranteed savings or equal accuracy.

Reported reductions

  • 65% average output reduction Ten prompts versus default verbose replies Range: 22% to 87%
  • 46% average memory-file reduction Five file examples, measured for those files only Project self-report

measure the whole request

Costs and break-even conditions

  • 1,000 to 1,500 input tokens per turn The skill rules add prompt overhead
  • Short replies can be net-negative There may be too little output to offset the added input
  • Long explanations offer more room Measure provider input, output, latency and retained criteria

The repository suggests testing around 1,500 to 2,000 normal output tokens. Your A/B result outranks its average.

Self-report with conditionsThe honest chart includes both sides of the ledger: fewer output tokens and the prompt overhead required to produce them.
06

The practical selection rule

Measure one real task before making brevity the default

Caveman's current rule of thumb is concrete: if a normal reply exceeds roughly 1,500 to 2,000 output tokens, the output reduction may outweigh the prompt overhead. Below that, or when the provider charges per request, it may cost more. Test the same representative task with and without the skill, then compare provider-reported input, output, latency and whether the answer kept every acceptance criterion. Your A/B result outranks the repository average.

Installation instructions include remote shell and PowerShell scripts. Read the pinned script before executing it, or use the documented per-agent installation route. An MIT licence describes permission to use the code; it does not promise future pricing, maintenance or compatibility.

The strongest reason to use terse output may still be attention. A clear operational answer is easier to scan, leaving more of the working day for judgement, learning and the people waiting beyond the screen. But durable knowledge needs enough explanation to remain intelligible to the next person. That is why a useful company brain stores rationale, not merely conclusions. As with renting better intelligence, the tool is broadly available. Choosing where its compression is safe remains your responsibility.


Sources & caveats. Product behaviour, the 69-to-19 illustration, and the 65% and 46% figures come from the project's official repository and README. Benchmark conditions, prompt overhead, net-negative cases and the A/B rule come from its Honest Numbers documentation. They are project self-reports current on 13 July 2026, not independent proof of accuracy or savings on your workload. Verify current installation and licence terms in the repository before use.