RTK vs Caveman: Which Claude Code Optimization Actually Helps?

Every morning we do a quick standup. What did you do yesterday, what are you doing today, any blockers. Standard stuff.

But we also end up talking about whatever's interesting in the Claude Code ecosystem new plugins, things people are trying, what's actually working. That's where this started.

I Suggested Caveman. The Founding Engineer Said No.

I'd been using Caveman for a bit. The pitch is right there in the repo: "why use many token when few do trick." It makes Claude talk in compressed, stripped-down responses. Output tokens drop significantly. Seemed like a reasonable win.

So I brought it up in standup like, hey, have you all tried this?

Our founding engineer told me to look at RTK instead.

I pushed back a little. Caveman was already working. Then he asked a simple question: what happens when your conversation gets long?

I already knew the answer, I just hadn't connected the dots yet.

The Problem With Caveman For My Workflow

Here's what Caveman actually does: it compresses Claude's output. The responses come back shorter, more telegraphic. The thinking is untouched the repo explicitly says this, "caveman no make brain smaller, caveman make mouth smaller." Reasoning tokens are completely unaffected.

The problem I was hitting wasn't a thinking problem. It was a context problem.

Once sessions got long, usually somewhere after 30-35% context usage, things started degrading. The compressed responses were dropping details that I actually needed edge cases, design reasoning, things the model was cutting because it was in compressed mode.

What RTK Actually Does

Where Caveman compresses what Claude says, RTK compresses what Claude reads.

It's a command prefix. Instead of cargo test, you run rtk cargo test. Instead of git diff, you run rtk git diff. RTK intercepts the output of that command, runs it through a filter tuned specifically for that tool, and hands Claude only what it actually needs to act on.

rtk go test strips everything except failures 90% savings. rtk grep groups results by file instead of dumping every match line 75% savings. rtk git diff gives a compact diff 80% savings. If RTK doesn't have a dedicated filter for a command, it passes through unchanged, so it's always safe to prefix.

The model's reasoning is untouched. The thinking is untouched. The noise just never arrives in the first place.

Then I Tried to Build It on Windows

cargo build

Windows:

error: linker `link.exe` not found
  |
  = note: program not found

note: the msvc targets depend on the msvc linker but `link.exe` was not found
note: please ensure that Visual Studio 2017 or later, or Build Tools for Visual Studio
      were installed with the Visual C++ option.

Standard advice everywhere you look: install Visual Studio Build Tools. These tools are 6–8 GB. Tick the right workloads. Restart.

I opened the installer. Stared at the checklist. And started asking the obvious question: why do I actually need this?

Why The Build Fails And What's Actually Happening

RTK has a build.rs a Rust build script that runs before compilation. On Windows, it contains this:

#[cfg(windows)]
{
    println!("cargo:rustc-link-arg=/STACK:8388608");
}

/STACK:8388608 is a MSVC linker flag. It tells the Windows linker to reserve 8 MB of stack for the binary instead of the default ~1 MB. RTK processes large command outputs and can exhaust the smaller default stack so this is a legitimate requirement.

But /STACK is a MSVC-only flag. I had a GNU Rust toolchain installed. The build script was unconditionally emitting it, which told Cargo to go looking for the MSVC linker (link.exe) a linker I didn't have. That's where the error was actually coming from. Not "you're missing a toolchain," but "this flag is assuming a toolchain you never installed."

The fix wasn't "install 6 GB of Visual Studio." It was two lines in build.rs:

#[cfg(windows)]
{
    if cfg!(target_env = "msvc") {
        println!("cargo:rustc-link-arg=/STACK:8388608");
    } else if cfg!(target_env = "gnu") {
        println!("cargo:rustc-link-arg=-Wl,--stack,8388608");
    }
}

Same stack reservation. Correct flag per toolchain. RTK compiled.

The Part I Found Out While Writing This

Somewhere in the middle of writing this post, I went back to RTK's install docs to double-check something.

There it was, right in the README under "Pre-built Binaries":

Windows: rtk-x86_64-pc-windows-msvc.zip

A zip file. One binary. No Rust toolchain. No build.rs. No linker flags. No 30 minutes of archaeology.

Download → extract → add to PATH → done.

I could have had RTK running in under two minutes. hehe 😭😭😭

I did not do that.

What I Actually Got Out of This

RTK is running. Token usage is down across sessions, and more importantly the quality is better the context window stays clean longer, which means the model retains more useful history and makes fewer garbage decisions mid-conversation.

Also: I still have Serendipity downloaded. I still have all my movies. I did not have to delete 6–8 GB of Visual Studio to make room for a tool whose prebuilt binary I could have downloaded in the time it took to write this paragraph.

838 commands. 4.7M tokens saved. 93.7% efficiency. rtk grep alone ate 4M of those 70 runs, each one that would have flooded the context with raw output the model didn't need.

I basically spent Claude tokens figuring out how to save Claude tokens.

But I do now understand exactly what /STACK:8388608 does, why MSVC and GNU linkers speak different dialects, and how build.rs communicates with the cargo linker. That knowledge will pay forward the next time it will right 😭!?

Worth it. Probably.

How I Spent 30 Minutes Configuring a Tool I Could Have Downloaded in 30 Seconds