Repo with all data, patches, and session transcripts: github.com/ncvgl/does-caveman-kill-claude

40,000 people starred the caveman prompt. It promises 65% token savings by making LLMs talk like cavemen, with the slogan “why use many token when few token do trick.” Catchy, viral, fun.

So I tested it.

Result: a marginal 14% on real coding tasks, not 65%. And in 1 instance out of 3, caveman actually made the model use more tokens than baseline.

This post is the receipts.

Setup

Claude Code (claude -p) running Haiku 4.5, on SWE-bench Pro Public, ScaleAI’s hand-picked benchmark of real GitHub issues across multiple languages. I picked 101 instances ranked at difficulty 100–200 (the frontier: hard enough to stress the agent, easy enough that a resolve-rate delta is measurable).

Each task ran twice with the same user prompt. Once vanilla, once with the caveman system prompt appended via --append-system-prompt. Same model, same tools (Read/Edit/Write/Bash/Grep, with WebFetch/WebSearch off), same deterministic grader. Only the system prompt differs.

Headline numbers

92 paired instances completed (9 hit dataset defects on the SWE-bench side and were dropped). Caveman is cheaper, faster, and slightly less reliable, but the resolve-rate gap is not statistically significant at this n.

Why is it 14%, not 65%?

Because in an agentic coding loop, the model doesn’t actually emit much prose.

I went through every session transcript and measured what fraction of the model’s output is narrative text vs. structured content (tool-call JSON, file paths, code, diffs):

• Baseline output: 13.3% prose, 86.7% structured (tool calls, file contents, code).
• Caveman output: 9.5% prose, 90.5% structured.

That number is the ceiling. Even if caveman compressed all prose to zero, the maximum possible savings on output tokens is ~13%. We measured 14%. Caveman is doing roughly the best it could possibly do given how much prose is even available to compress.

The 65% headline figure on caveman’s repo comes from natural-language chat tasks where prose is 90%+ of the output. In an agent loop, that’s flipped: the model is mostly generating Bash commands, Edit operations, and reading code. None of that can be cavemanned. “chk file. edit fn. run test.” is fine for prose; you can’t compress Bash(command="CGO_ENABLED=0 go test ./models -run TestGetCveContentTypes -v 2>&1").

What caveman-speak looks like

Same task, same 13-line patch. Baseline opens:

“I’ll start by understanding the codebase structure and finding the failing tests to understand what needs to be implemented.”

Caveman opens:

“Examining repo structure to understand CVSS handling and locate relevant files.”

Baseline wrote 20 such narrative blocks on that task. Caveman wrote 2.

The case where caveman doubled the tokens

The mean (−14%) hides a wild distribution. Here’s the per-instance histogram of token savings, in 10% bins:

Caveman saved tokens on 66% of instances. But it increased them on 34%, up to +102% on one instance (it literally doubled the output).

I dug into that doubling case (vuls-73f0adad, a Go vulnerability-scanner task). Both conditions resolved the task. But:

Both started identically: read the test, read the source, grep for constants. Both edited the right file and made the test pass. Baseline stopped there. Caveman didn’t. It launched a 30-step exploration sweep through the rest of the codebase looking for callers of the function it just modified, spawned an Explore sub-agent, and edited a second file that didn’t actually need editing. The test passes without those changes.

So caveman’s compressed-output style didn’t make the model write less. It made the model do more work. Each tool call carries its own input/output token overhead. Saving 5 tokens per text block doesn’t help if you make 45 extra tool calls.

This isn’t unique to caveman. It’s a general pattern when you tell a model to be terse. The saved budget gets reinvested somewhere, often in additional exploration.

Same problem, different code

Here’s the surprise nobody asked for. Of the 79 instances where both conditions resolved, only 3 produced byte-identical patches. The other 76 reached different valid solutions:

• 61% of pairs touched the exact same set of files.
• But the actual lines they changed are mostly different. Typically only ~35% of changed lines appear in both patches.
• In 43% of pairs, less than 30% of the changed lines overlap: essentially different implementations of the same fix.

In other words: the two configurations agreed on where the bug was, but wrote substantively different code to fix it. Caveman isn’t just writing a terser version of the baseline patch. The model takes a visibly different path and lands on a different valid fix.

This is partly a property of SWE-bench Pro (its grader admits many valid implementations per task), but it’s also a reminder: a prompt-style change isn’t surface-level. It rewires the trajectory.

So should you use it?

At scale (automated agentic systems running thousands of jobs a day), turn it on. 12% lower cost is millions of dollars at any non-trivial volume. The quality risk is real but small (a ~3% resolve-rate gap that isn’t statistically significant on our data).

As a single user, I wouldn’t bother. You trade a layer of visibility into the model’s reasoning (the prose is where you see why the model is doing what it’s doing) for savings that don’t move the needle on a personal API bill.

Caveats

• Single model (Haiku 4.5). Larger models with more reasoning capacity might respond differently to the compression instruction.
• Single harness (Claude Code in headless mode). Other agent frameworks may show different ratios of prose to tool-args.
• The caveman system prompt itself adds ~69 lines of instructions and examples to caveman’s input.

The real lesson

Tested in chat ≠ works in agent. When the bulk of your model’s output is structured (tool args, code, file contents), output-style tweaks can’t move the needle far. Always run a paired A/B on your actual workload before believing a prompt-engineering claim, especially a viral one.

Caveman works. It was just oversold by the hype, for coding at least.

Try it: murmur.ncvgl.com
Star it: github.com/ncvgl/murmur

Meeting recorders charge $10–30 a month. Murmur is free. Forever.

No installation. No backend. No API costs. No data leaving your computer.

Just open murmur.ncvgl.com and click Start. Works on Zoom, Meet, Teams — anything.

How it works

Moonshine v1, a state-of-the-art speech model from ex-Googlers, runs locally in your browser. It listens to your mic and speakers, transcribes in real-time, and works without internet.

Why it’s free

Other tools cost money because they stream your audio to a server. Murmur has no server. The AI runs on your laptop, so the only cost is the electricity you were already paying for.

The tradeoff

~90% accuracy. English only. No speaker labels. But ChatGPT doesn’t need a perfect transcript to write an accurate meeting summary — it just needs the gist, and Murmur gives it that.

github.com/ncvgl/claude-prompt-queue

Codex launched with task queues. Claude Code was missing one. Not anymore.

You give it a task. It finishes. Then stops. No queue. No batching. Just waiting for you.

You can’t walk away. You have to sit there feeding it prompts like in 2023.

It’s also one of the most requested features on their GitHub.

So I added it with a plugin. 30 lines of bash. Using stop hooks.

next: refactor the auth module
next: write tests for it
next: just keep going, resolve any question by yourself

Queue 10 tasks. Walk away. Come back to finished work.

Install with:

/plugin marketplace add ncvgl/claude-prompt-queue
/plugin install prompt-queue@prompt-queue-marketplace

FAQ: Yes, Claude has an implicit CreateTask tool but it can stop in the middle of a task asking a question that you are not there to answer. This plugin forces Claude to continue.

github.com/ncvgl/slawk

I posted about building a Slack clone using multiple AI agents. Everybody asked: “How did the agents talk to each other?”

I initially treated Claude Code like a smart assistant — write prompt, get code, review, repeat. But after 30 exchanges, context bloat kicked in: slower responses, confusing outputs, compaction takes a few minutes…

So I tried something different: What if I treated AI like a dev team instead of a chatbot?

One persistent “CTO” session that plans, delegates, and reviews. It never writes code. It just thinks.

Ephemeral “developer” sessions that get spawned for single tasks, build the feature, commit, and get deleted. No conversation history. No memory of previous tasks.

Disposable “QA” sessions that test the app like a human user, report bugs, and disappear.

QA sessions use ~10-20 tool calls, developer sessions average 30-50K tokens per feature, the CTO session sits around 80K after 3 days. Total: maybe $20-30. The velocity gains are worth 100x that.

How much the CTO controls the handoff depends on how much you trust the system. Early on I had it write each developer prompt to a local .md file — I’d review it, then manually start the subagent session. Once I stopped changing anything, I let the CTO spawn subagents directly. Same outcome with less friction.

Here’s the prompt I gave the CTO for a real task:

Implement thread replies as the next feature.
Use TDD: write Playwright test first, then implement.
The feature should work end-to-end (backend + frontend).
Commit when done and report back.

That’s it. The CTO plans the task then spawns a developer agent with this prompt:

You are implementing thread replies for a Slack clone.

Backend requirements:
- Add thread_id foreign key to messages table
- Add GET /api/messages/:id/replies endpoint
- Add real-time events for new replies

Frontend requirements:
- Add "Reply in thread" button to messages
- Add right sidebar that shows thread when opened
- Show reply count on parent message
- Real-time updates when new replies arrive

Process:
1. Write Playwright test that verifies the full flow
2. Implement backend changes
3. Implement frontend changes
4. Iterate until test passes
5. Run ALL existing tests to ensure nothing broke
6. Commit with message: "feat: Add thread replies"

The agent has no context about previous features, so it explores the codebase first:

grep -r "messages" backend/src --include="*.ts"
cat backend/src/routes/messages.ts
cat frontend/src/components/MessageList.tsx

5-6% of its context window. It finds what it needs and gets to work.

Fresh eyes catch mistakes. Without context, the agent can’t make assumptions. It reads the actual code, which often reveals inconsistencies a loaded agent would miss.

TDD is the safety net. If the agent misses something, the test fails. It iterates:

Test failed: Thread sidebar doesn't open when clicking reply count

Debugging... found the issue: missing event listener on reply count button
Fixed and re-running tests...

All tests passing ✅

Speed and parallelization. A fresh agent responds in 5 seconds vs 15-20 for a bloated one. And since agents don’t share context, they can work simultaneously using git worktrees.

After building 4-5 features, I tell the CTO:

Spawn a QA agent to test the app using the MCP browser extension.
Have it test the main features and report bugs it finds.

The CTO spawns a QA agent with this brief below. Make sure you have it enabled by typing /chrome in Claude Code. See this chrome extension

You are a QA engineer testing a Slack clone.

Open the app at http://localhost:5173 using Chrome MCP.
Test these features like a real user:
- Register a new account
- Create a channel
- Send messages
- Try replying in a thread
- Upload a file
- Use search

For each bug:
- Take a screenshot
- Note the steps to reproduce
- Rate severity (Critical/High/Medium/Low)

Write your findings to qa-report.md

To validate UI accuracy, I gave it two URLs: my local app and an actual Slack workspace I’m part of. Its job was to test the same features in both and flag differences. It clicks buttons, fills forms, pulls JavaScript from the page for advanced debugging, takes screenshots when things break.

Something I didn’t ask for: halfway through, it created a slack-design-system.md file — colors, spacing, component patterns, all mapped from the real Slack UI. It just decided having a design anchor would help it stay consistent. I thought that was smart.

After 10-15 minutes, I get a markdown file:

# QA Report - Thread Feature Testing

## Bug #1: Thread sidebar doesn't show typing indicators
Severity: Medium
Steps: Open thread, have another user type a reply
Expected: See "User is typing..." in thread
Actual: No typing indicator appears

## Bug #2: Thread reply count doesn't update in real-time
Severity: High
Steps: User A opens channel, User B replies in thread
Expected: Reply count updates immediately
Actual: Need to refresh to see new count

The CTO reads this report and spawns fix agents for each bug. Just ask it for subagents and you will see it spawn them.

The last 20% takes 80% of the time. After the QA agent found 14 bugs, I asked the CTO to fix them all in parallel. It ran them 3 at a time using subagents. Three hours total.

Half that time went to a single bug: removing a star icon stuck in the bottom-right corner of the screen. The agent tried everything — searched the codebase, modified CSS, rebuilt components. Nothing worked. Because the icon wasn’t part of Slawk. It was the Claude MCP extension overlaid on top of the browser.

The agent had no way to know that. It needed me to step in and say: skip this one, it’s not an issue.

That’s the pattern. Parallel AI work is fast until it hits something it can’t resolve alone — and then it waits for you. The moment you step in, 10 agents working simultaneously collapse to one, because your attention can only be in one place. You are the bottleneck.

The key to speed isn’t better prompts. It’s removing yourself from the feedback loop. And occasionally checking if it needs you to step back in.

Redirecting to PolyGPT...

From Static Panels to Moving Animation

I got a little addicted to turning my favorite mangas into animated versions using Google’s Nano Banana, Imagen3 and Veo3.1 models. What started as an experiment became a week-long exploration of what’s possible (and what’s not) with current AI video generation. Below is my best creation.

The Reality Check

After spending a day working with Veo 3.1 to turn half a chapter into an animated version, I had to walk back on my initial excitement: we’re still not there yet on full automatic manga-to-anime generation.

Video and image models are mind-blowing, but turning static manga into moving anime is a different beast. The main limitation is that the model has to invent too much. It can’t take a style reference for how the anime should look yet, so it fills in the blanks and drifts too far from the intended style. The results are good enough for fan-made action, but not studio quality.

Another limitation is keeping voice and character consistency across scenes, with currently no feature for those except prompting.

The Recipe

That said, I found a few cheap tricks that make the difference. The key idea is to have very neat “base images” to generate the videos from:

1. Crop the image from the manga with a screenshot tool
2. Remove any undesirable elements using Imagen3 (paint the areas you want removed, like text bubbles)
3. Color the image using Gemini Nano Banana (tell it “Color EVERYTHING in this image” otherwise it gets lazy)
4. Extend the image with Imagen3 to fit a 16:9 format (that’s what Veo 3.1 expects)
5. Animate it using Veo3.1 and mention the text bubbles so they are generated in the audio
6. Stick all the videos together using gemini-cli, with a low volume soundtrack to convey emotions

It’s not anything that can be easily automated with code. A lot of redoing with custom prompting is involved, but it can accelerate the work of artists.

Here is a video breaking down the process visually:

The Verdict

AI is evolving fast, but full studio automation is still a few steps away.

The webapp is here.
The code is here.

… So the other day, I had to fill another government form by paper. Take a photo. Send it back. The usual.

Let’s say I’d had enough of this workflow. Government sends you a PDF, you print it, fill it by hand, scan it, email it back. Or you try some digital tools you have to pay for.

So I got bored of the repetitive work and built a service to fix this. Upload your form, it detects the fields, fills them with fake data, you correct what needs correcting, download, send.

Basically retrofitting legacy forms that organisations could not bother to put into a proper website. Not that I blame them - building web forms is work. PDF Forms are easy to switch and update.

It is a simple side project that helps with daily admin tasks. Taxes, subscriptions, utilities - all those forms that live in the stone age of user experience.

For now it’s fake data only, but I’m considering an extension where you store your actual info and it auto-fills everything.

Every time I use this, I’m reminded that good UX isn’t about flashy animations or trendy frameworks. It’s about removing the gap between what you want to do and actually doing it.

Government forms are the perfect example of that gap. They want your information. You want to give it to them. But somehow we’ve created this elaborate ritual involving printers, scanners, and PDF readers from 2003.

Sometimes the best innovation is just… making things work.

The service is free, no login, no storage, open-source.

You can copy a chip; you can’t copy the city around it. That, more than clock speeds or clever slides, is why NVIDIA - now valued in the 4.4 trillions - keeps its lead. The firm did not just build silicon; it laid roads, wrote the road signs, and taught everyone to drive on them.

Start with the language of the place. For two decades developers have learned to think in CUDA. The popular tools - PyTorch and TensorFlow - lean on it by default. Under the bonnet sit libraries with unsexy names (cuDNN for neural nets, cuBLAS for linear algebra, NCCL for multi-GPU teamwork) that most teams never see but always use. Higher up, deployment tools - TensorRT and Triton - turn models into production workhorses. Try to lift all that code to another brand of chip and you hit the small print: NVIDIA’s CUDA licence forbids translation layers that pretend to be CUDA elsewhere (the ZLUDA saga is the cautionary tale). Like it or not, the city speaks one language.

Then there is the box itself. NVIDIA does not sell loose parts so much as finished appliances. DGX servers and NVL72 racks, built around Grace + GPU “superchips” (GH200 today, GB200/Blackwell tomorrow), are wired with NVLink and NVSwitch so that eight, sixteen or seventy-two GPUs behave like one big one. Imagine seventy-two chefs making one soup. If they shout across a corridor (plain PCIe and ordinary Ethernet), half the day is spent coordinating. Give them a quiet kitchen - fast, private communication - and dinner is ready sooner. Buyers do not pay for theoretical flops; they pay to finish on Tuesday rather than Friday.

Owning the plumbing turned out to be strategy, not housekeeping. When NVIDIA bought Mellanox, it acquired the city’s transit system: InfiniBand for low-latency links, an AI-tuned flavour of Ethernet called Spectrum-X, and programmable adapters known as BlueField DPUs (with a software kit called DOCA). With the roads in hand, the company can co-design cars and traffic lights. That is hard to rent by the hour.

All of this still needs a place to be built. At the frontier, that place is Taiwan. NVIDIA’s top chips are fabricated at TSMC on custom processes (4N/4NP) and assembled with advanced packaging called CoWoS, which stitches huge dies to stacks of very fast memory. The memory - HBM3E - comes from SK Hynix, Micron and Samsung, but not on a whim: parts must be qualified, and capacity is reserved years ahead. The limiting factor in this boom has often been CoWoS slots and HBM allocation, not bravado. Without those golden tickets, an “H100-killer” remains a handsome rendering.

Who, then, looks capable of building a rival metropolis ? Startup Graphcore tried. A brilliant architecture that struggled to win ecosystem & customers at scale, it was ultimately sold to SoftBank in 2024. And on the grown-ups side ? We have some cloud landlords and a few chip specialists. Google’s TPUs are tightly woven into its own software mill; AWS pushes Trainium and Inferentia (now Trainium 2) to control cost across a global fleet; Microsoft’s Maia and Cobalt are co-designed with frontier models in mind; Meta’s MTIA leans on the gravity of PyTorch. Among chipmakers, AMD’s MI300/MI325X/MI350 paired with ROCm is the closest on raw silicon and is steadily improving the software; Intel’s Gaudi 3 offers sharp price-per-job in some training and inference, especially for Ethernet-centric shops. Inside China, Huawei’s Ascend 910B/910C rides a home-grown software stack called CANN, a deliberate CUDA alternative for a parallel ecosystem.

Beating NVIDIA, then, is not a single trick but a city plan. You need a developer path that feels native in PyTorch and TensorFlow rather than “ported”. You need racks that scale as one machine, not a suggestion to “use more Ethernet”. You need control over the network - InfiniBand-class links or an AI-tuned Ethernet like Spectrum-X, ideally with offload smarts in the BlueField mould. You need manufacturing booked, not promised: CoWoS capacity at TSMC and HBM3E from the big three, with qualification signed off. And if your migration story is “we’ll just run CUDA elsewhere”, you will have to explain how you navigate the licence.

None of this says NVIDIA is immortal. Cities ossify; fashions change. A rival that offers a familiar software path, rack-scale smoothness, owned plumbing and a guaranteed Taiwanese supply chain could yet siphon tenants. Until then, the premium is not only hype. It is the rent you pay for a place where the streets are paved, the buses run on time and the favourite coffee cart knows your order.

Since working at Google, I’ve come to see big corporations like a human brain. Complex, adaptive, full of redundant paths.

If one neuron goes silent, the signal finds a way around. It always does. You know the person I’m talking about. The one who’s supposed to own some piece of work, but hardly replies. You try to loop them in, move a piece forward — but nothing. Just radio silence.

That’s what I call the dead neuron.

In a startup, that’d be a blocker. In a big corp ? Not really. People route around. They find a workaround. The task moves, the project progresses, just without them.

And here’s the thing: dead neurons train people to stop depending on them. To skip them. To forget them. They become a name you avoid mentioning. A calendar invite you don’t bother sending. Not because you’re mad - but because you’ve adapted. Some folks even lean into it. “If I stop replying, they’ll stop asking.” And sure, they do.

So if someone sent you this, maybe they tried to ping you — and the signal died in your synapse.

Reconnect.

Post scriptum

The opposite is just as real. If you always reply - even to things you don’t own - just to help out, you slowly become the default active neuron for that signal.

In big corps, work is just a chain of neuron activations: one ping lighting up another. And if someone manages to pass a task to you once, they’ll come back. That’s how you become the go-to, the shortcut.

My manager used to say, “Nathan, be careful - because the reward for good work is always more work”.

So yeah, don’t be a dead neuron. But also set your boundaries. Or you’ll get wired into flows you never meant to be part of.