Claude Talk Small. Code Still Big.

AI coding assistants talk a lot. Sometimes that is useful. They explain what they changed, why they changed it, which files were touched, what still needs attention, and which assumptions they made along the way. Sometimes it is also just a lot of words around a small change. Then I came across a skill called “Caveman”.

The idea is simple: make the assistant talk in short, caveman-like sentences. Less explanation, fewer long paragraphs, fewer polite detours. In theory, this should save tokens because the assistant spends less time explaining what it is doing.

Something like:

Me inspect files.
Me change request.
Me run tests.
Tests pass.

Instead of a full paragraph about the implementation plan, risks, ...

Less talking, more coding?

When using AI coding assistants all day, you start noticing how many tokens are spent on communication around the code. A lot of the time that communication is useful. It explains what changed, why something failed, or what still needs attention.

But sometimes it is also a lot. Especially when you already know the codebase, already know what you want, and just need the assistant to do the work. In those moments, a shorter communication style sounds useful. Less talking, more doing.

So I wanted to see if a skill like Caveman could make my a.i agent (lately more Codex then Claude i think Codex (gpt 5.5 model) is a sleeper and has much better ROI with very similar if not better output) cheaper or more efficient in real usage.

Did it save tokens?

Yes. But not as much as I expected or wanted to.

The reason is pretty simple: when you're using Claude for coding, most of the tokens are not always in the explanation. A lot of them are in reading files, understanding context, generating code, applying changes, and checking results.

So even if the assistant says:

Me fix bug.

Instead of:

I found the issue and updated the request class so that the payload is now correctly passed to the API.

The actual code still has to be written. The files still have to be read. The response still includes diffs, function names, namespaces, imports, and tests. In other words: Caveman makes the talking shorter, but coding is not just talking. That was the main thing I underestimated. I expected the token savings to be more dramatic, but the expensive part is often the work itself. The Caveman documentation says you can save around 65% of tokens and I believe that can be true depending on what you are doing but in my experience with coding tasks it was more likely between 5-20% depending on the task.

Was it useful?

Yes I think so. I don't need the multi sentence explanation of what my a.i agent did. I will need to go over the code anyway so having a short description like this below is for me better since i can jump faster to reading the code.

Me update DTO.
Me add missing nullable field.
Me run Pint.
All good.

It also made reviewing the output kind of funny. There is something very entertaining about seeing a coding assistant explain a Laravel refactor like it just discovered fire.

Where it was less useful

For more complicated tasks and planning (instead of plan mode I highly recommend the grill-me skill by Matt Pocock), I still prefer normal explanations.

If something touches multiple parts of the codebase, changes behavior, or has trade-offs, then I do want the assistant to explain itself properly. Short caveman-style updates are funny, but they are not always enough when you need to understand why a certain approach was chosen.

There is also a difference between reducing unnecessary words and removing useful context. Sometimes the extra explanation is exactly what helps you catch a wrong assumption before it turns into a bad implementation. So I would not use this skill for everything.

What I learned

The Caveman skill is a cool example of how small changes in communication style can affect the feeling of working with an AI assistant.

It did save some tokens, just not in the huge way I expected. And that makes sense now. In coding tasks, the assistant spends a lot of tokens on actual code and context, not just on sentences around the code.

It made small tasks feel lighter, reviewing the assistant's output was genuinely funny, and it showed that skills do not always need to be big project-specific automations. Sometimes a skill can simply change the way the assistant behaves, and that alone can be useful.

Would I keep it around for quick tasks and for the fun of it? Yes.

Me like skill. Skill good.