Caveman’s two-layer design — a skill plus a separate proxy — is a clean example of a distinction worth generalizing, because the same two-mechanism pattern shows up anywhere someone’s trying to cut an agent’s token usage.
A skill changes behavior from the inside. As I covered when explaining Agent Skills generally, a skill is instructions the agent itself reads and follows — in this case, a rule file telling the model to respond tersely, dropping filler while keeping technical content intact. It only affects one direction of the conversation: what the model chooses to say back. It requires no separate running process, works the moment it’s installed, and its actual effect depends entirely on the model choosing to follow the instruction — a capable model mostly will, but nothing external is enforcing it.
A proxy intercepts from the outside, structurally, before content ever reaches the model. It sits as a real running process between the agent and whatever it’s calling — a shell command, a file read, a search result — and compresses that content before it becomes part of the context the model has to pay for. This isn’t asking the model to be terse about what it already received; it’s reducing what gets sent in the first place. That distinction matters because it doesn’t depend on model compliance at all — a proxy strips a verbose log down before the model ever sees the verbose version, so there’s no instruction to follow or ignore.
Why you’d want both rather than picking one: they compress genuinely different token sinks. A skill only ever touches what the model generates — its replies, its commit messages, its review comments. A proxy only ever touches what the model receives — command output, file contents, search results, anything read rather than written. An agent’s context accumulates from both directions simultaneously, so a skill alone leaves incoming tool output uncompressed, and a proxy alone leaves the model free to still write a five-paragraph explanation where five words would do. Caveman covers both specifically because a real agentic session burns tokens on both sides of that line, not just one.
The tradeoff that comes with each approach, worth naming plainly: a skill is trivially easy to install and just as easy to disable, but it’s a request, not a guarantee — model compliance can vary by task and by model. A proxy is a stronger guarantee, since it structurally cannot let uncompressed content through, but it’s also a real piece of infrastructure sitting in the critical path of every single call — something that has to stay running, stay correctly configured, and, per the backup-and-restore approach I flagged specifically, needs a real mechanism for recovering the original when compressed content genuinely isn’t enough for whatever the agent needs to do next.
The general lesson past this one tool: when you’re evaluating any claim about cutting agent token usage, it’s worth asking which direction is actually being compressed — what the model says, what it reads, or both — because a solution addressing only one side of that line will look effective on exactly the workloads where the other side doesn’t matter much, and quietly disappoint on the ones where it does.
