RTK or Headroom? Why I Changed My Claude Code Setup

Author: The Gray Cat · Watch on YouTube

Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.

Original language: English

Original video: RTK or Headroom? Why I Changed My Claude Code Setup · Channel: The Gray Cat · 10:25 · Watch on YouTube

Topics: AI agents, AI evaluation and benchmarks, Claude Code, AI developer tools, Model inference and optimization

Summary

The creator compares vanilla Claude Code, RTK, Headroom, and both tools together across final runs of the same coding task, after fixing setup mistakes and completing 12 runs. RTK used more tokens than vanilla in this test, while Headroom used 21.7% fewer; combining them did not improve on Headroom alone. Headroom also cost less in the comparison, though caching behavior and the subscription model make the practical savings uncertain. All implementations needed fixes, so the creator has turned RTK off for now, kept Headroom enabled, and plans to evaluate it during ordinary work.

Key points

The task was to add corrected subtitles and playback word highlighting to Gray Cut, with each setup tested in a separate worktree from the same commit.
RTK reduces command output before Claude reads it; Headroom uses a local proxy to compress requests and can provide Serena through MCP.
The creator corrected several setup issues, including an outdated RTK version, a lingering Headroom proxy address, and missing Serena instructions and Swift configuration.
In the final runs, RTK used 5.5% more tokens than vanilla, while Headroom used 21.7% fewer; using both together did not improve on Headroom alone.
Headroom finished about 20 seconds ahead of vanilla in one run, which the creator did not consider a meaningful speed advantage.
RTK truncated Swift build output in one example, but the extra command to check the result took about two seconds and did not explain the full slowdown.
The earlier RTK comparison had different task conditions and subagent use, so its token savings did not carry over and cannot be directly attributed to a single cause.
Headroom was about 9% cheaper than vanilla in the comparison, but cache pricing and the creator’s subscription mean the figures do not show how much more work the subscription allows.
All four implementations passed their own tests but failed an additional timeline-cut check, and each still required repairs.
The creator is keeping Headroom enabled for now, plans to configure Serena for all relevant languages, and will compare usage from everyday sessions.

Chapters

Start	Chapter	Summary
00:00	The comparison and setup	The creator explains the feature being tested, the four Claude Code configurations, and setup problems involving subagents, RTK, the Headroom proxy, and Serena.
03:44	Results and why RTK differed	The final runs show Headroom using fewer tokens than vanilla, while RTK uses more, and the creator examines why this differs from an earlier comparison.
07:50	Costs, caching, and implementation quality	The creator compares costs, discusses an unexplained caching pattern through Headroom’s proxy, and notes that every implementation failed an extra timeline-cut check.
09:22	What the creator will use next	The creator turns RTK off, keeps Headroom enabled for ordinary work, plans further usage analysis, and asks viewers to support a follow-up.

Quotes

This time even the clean rerun used more than vanilla. — 00:00

RTK used 19 million, which was 5.5% more. — 04:14

Headroom used 21.7% fewer tokens than vanilla in its final configured run. — 04:14

So I’ve turned RTK off for now and I’m keeping Headroom enabled. — 09:22

Concepts and entities

Claude Code, RTK, Headroom, Serena, MCP, Opus 5, Gray Cut, CLAUDE.md, Graphify, CodeGraph

Full transcript (original language)

00:00 I thought comparing RTK and Headroom in Claude Code would be quick and easy. RTK saved tokens in my previous video. This time even the clean rerun used more than vanilla. I ended up building this feature 12 times across two evenings that went late into the night. Some reruns were my fault. Others needed more setup than I expected. By the end, I had changed my everyday setup. I’ll show you what actually saved tokens in these runs and why I changed what I use.

00:36 As usual, the feature was for Gray Cut. It’s the video tool I used to speed up editing for this channel. I wanted corrected subtitles and word highlighting during playback, both following my timeline edits. Every run used a separate worktree, branched from the same commit on main. I selected Opus 5 at medium effort and started in plan mode. I’ll leave the prompt on the screen. Plain Claude Code was the baseline. Then I tested RTK and Headroom separately, followed by both together.

01:07 RTK shrinks command output before Claude reads it. Headroom runs a local proxy that compresses parts of requests before they reach the model. Headroom also brings Serena through MCP. It helps Claude find specific functions and read the relevant code. That’s a similar goal to Graphify and CodeGraph from my previous video. Although the implementation is different, Headroom also offers optional shared memory in a local database. Claude Code accesses it through the proxy. Codex uses a memory MCP server

01:39 with matching settings. Agents can share saved facts. That interests me as I switch between agents, but I haven’t tested it yet. The basic Headroom setup is two commands install the Python package, then launch Claude Code through the wrapper. The first problem was subagents. My prompt already said not to delegate, but Claude spawned workers anyway, So I made the restriction harder to miss in caps, covering both planning and implementation. I also disabled the Agent

02:11 tool at launch. I also discovered I’d tested RTK 0.46.0, while 0.49.0 was already available. So I upgraded it and started retesting. During those retests, I caught another mistake My terminal still had Headroom’s proxy address set. So the supposed RTK-only runs went through Headroom too. Disabling the MCP servers hadn’t cleared that environment variable. That was my setup mistake. And it meant another rerun.

02:43 Serena was more confusing because I could see activity in its web UI. In the file explorer, The .serena folder also contained cached codebase data. But Claude wasn’t calling Serena’s tools. When I asked why, it said it had reached for Read and Grep out of habit. Headroom registered Serena by default, but I had to separately enable the instructions telling Claude to prefer Serena. That’s what the –serena-instructions flag does. it adds guidance to CLAUDE.md. And I also

03:13 made Serena usage explicit in the task prompt. After another run, Claude said Serena helped with Python but not Swift. I checked the configuration, only Python was listed, so I added Swift. Headroom’s CLAUDE.md guidance focuses on finding and reading code. Serena also has editing tools. Serena has an MCP tool called initial_instructions. Calling it gives Claude a usage guide including instructions for editing code. The final Headroom-only run didn’t load that guide

03:44 Claude used Serena for Python navigation and its built-in tools for editing. The combined run loaded the guide and used editing tools extensively. Both had Python and Swift configured, but Claude still used the tools differently. Serena deserves its own deep dive, Meanwhile, the Headroom proxy was working. The local logs showed the proxy changing requests by midnight on the second evening, I had completed 12 coding runs. I finally had a usable run for each setup.

04:14 those four go into the results. The earlier attempts stay out. Okay. So here are the four runs I’m comparing. these totals cover planning through the final coding answer. cached input counts again every time it appears in a request. Plain Claude Code used about 18 million tokens. RTK used 19 million, which was 5.5% more. Headroom used 21.7% fewer tokens than vanilla in its final configured run. The combined run

04:46 used fewer tokens than vanilla, but more than Headroom alone, so stacking them didn’t improve the results here. Time was my secondary concern Vanilla took about 17 minutes of active time, while RTK took almost 20. Headroom finished only about 20 seconds ahead of vanilla. I wouldn’t call that a meaningful speed advantage from one run. The combined setup took over 19 minutes After the runs, I asked Claude whether RTK had helped. Claude said it had to run

05:16 extra commands because RTK cut off information it needed. The audit confirmed one example. In the clean RTK run, RTK truncated the Swift build output, hiding its final status. Claude ran another build command to check it, but that follow-up took about two seconds. It doesn’t explain the whole slowdown. And some other complaints didn’t match the logs. Vanilla and RTK each made 111 requests to the model. But with RTK

05:47 those requests were larger on average. So smaller command output didn’t give me a smaller, complete session. If you want more comparisons measured through the complete task, subscribe. Someone bought me a hundred coffees, but I couldn’t withdraw the money in my country. I refunded it and set up Patreon instead. It’s minimal for now. If more people join, I’ll add supporter credits and Discord roles. Member-only content is another possibility. Patreon and Discord links are in the description.

06:18 RTK did save tokens in the previous comparison and it finished faster, But that was a different feature. Adding vocabulary hints for transcription. I expected the larger reading-heavy task to give RTK more opportunities. Apparently task size alone doesn’t tell me much. The older runs also used subagents. Vanilla spawned three workers, while RTK spawned one. Their direct usage accounts for about 14% of the token gap. Most of the difference

06:48 was still in the main conversations. Back then, RTK’s main conversation made fewer requests with less input per request on average. That advantage disappeared in this test. Vanilla also used targeted searches and commands like tail to limit output itself. That probably left RTK less room to help. The versions changed too. Version 0.49 can shrink command output before tail takes the last few lines. It also adds rtk recall to recover output

07:20 that was cut. Claude received that recovery hint during the Swift build, but ran another command instead. Claude Code changed its own prompts and caching behavior between the videos. Those changes could matter, but I haven’t isolated their effect. My first RTK attempt used version 0.46, but it also used more tokens than vanilla. I discarded it to test the current version, but I can’t simply blame the upgrade for the result. The task and Claude’s approach changed and individual

07:50 runs vary. The earlier savings didn’t carry over here. The totals I have shown come from the session logs, including cached input and generated output. Headroom’s own compression estimates measure the proxy’s changes. They are separate from these complete-session totals. Now let’s put dollars next to them. Headroom alone comes out about a dollar cheaper than vanilla. That’s 9% lower cost. Despite using almost 22% fewer tokens.

08:20 caching explains part of that gap. Reading cached input costs much less than writing it again. Every run needed the tool for leaving plan mode. Here’s what happened when Claude loaded it in the final Headroom-only run. Most of that context had to be written into the cache. Again, at those prices, that’s much more expensive than reusing it. The requests were only two seconds apart, so normal cache expiry seems very unlikely. The pattern appeared in every audited run through Headroom’s proxy.

08:51 It didn’t appear in vanilla or pure RTK. The logs still don’t prove whether Headroom itself caused it, or Claude Code behaved differently through the proxy. I’m on a subscription. These dollar figures help me compare usage. But they aren’t amounts deducted from my account. I still can’t say how much longer Headroom lets me work before hitting my subscription limit. Finally, all four final implementations passed their own tests but failed an additional timeline-cut check. A word with estimated

09:22 timing remained in the subtitles after an edit should have removed it. The defects differed too. In another check, Headroom dropped a final full stop that vanilla kept. Every implementation still needed fixes. These totals exclude that repair work. So I’ve turned RTK off for now and I’m keeping Headroom enabled. I want to see whether the savings hold up during ordinary work. If your repo uses several programming languages, check Serena’s configuration and add any missing languages

09:53 manually. I’ll add this rule to my global CLAUDE.md when Serena is available. Claude should call its initialization tool before exploring the code. Then I’ll run an analyzer over those sessions and compare them with my previous usage. My first priority is saving tokens without losing quality. Finishing faster would be a bonus. Daily tasks will differ, so this won’t be a controlled benchmark. I’m heading out on vacation next week, so don’t expect results in a week. On the previous video, I asked for a hundred likes

10:25 and got them overnight. Apparently I set the bar too low. This time let’s make it 500 likes by the time I’m back at work. If it gets there, I’ll make a follow-up. Once I’ve collected and analyzed enough usage That might still end with me switching Headroom off, and my cat spent those two evenings asking for attention and getting none. She is very, very pissed right now For another approach to helping Claude read less code, watch my Graphify versus CodeGraph comparison.