RTK ou Headroom? Por que mudei minha configuração do Claude Code

Autoria: The Gray Cat · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: RTK or Headroom? Why I Changed My Claude Code Setup · Canal: The Gray Cat · 10:25 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Claude Code, Ferramentas de desenvolvimento com IA, Inferência e otimização de modelos

Resumo

O criador comparou Claude Code sem modificações, RTK, Headroom e os dois juntos em tarefas de implementação, após várias execuções e correções de configuração. Nos testes finais, Headroom sozinho usou cerca de 21,7% menos tokens que a configuração padrão, enquanto RTK usou 5,5% a mais; combinar as ferramentas não melhorou o resultado. A comparação também encontrou diferenças de custo, comportamento de cache e uso das ferramentas Serena, mas os resultados não são um benchmark controlado e as implementações ainda precisaram de correções. Por enquanto, ele desativou RTK e manteve Headroom, com a intenção de observar o uso cotidiano e verificar se a economia se sustenta sem perda de qualidade.

Pontos-chave

O teste comparou quatro configurações: Claude Code padrão, RTK, Headroom e RTK com Headroom.
As execuções finais usaram worktrees separados, derivados do mesmo commit, com Opus 5 em esforço médio e modo de planejamento.
RTK usou 5,5% mais tokens que a configuração padrão; Headroom usou 21,7% menos.
Usar RTK e Headroom juntos não melhorou o resultado em relação a Headroom sozinho.
O Headroom foi cerca de 9% mais barato que a configuração padrão, uma diferença menor que a redução no total de tokens.
A configuração de Serena exigiu ativar instruções específicas e adicionar manualmente a linguagem Swift.
As ferramentas e configurações foram usadas de maneiras diferentes entre as execuções, e algumas tentativas iniciais foram excluídas por erros de configuração.
Todas as implementações passaram nos próprios testes, mas falharam em uma verificação adicional de edição da timeline e ainda precisavam de reparos.
O criador desativou RTK por enquanto e pretende acompanhar o Headroom durante o trabalho cotidiano.

Capítulos

Início	Capítulo	Resumo
00:00	Objetivo e configuração da comparação	O criador apresenta a comparação, descreve a tarefa do Gray Cut e explica como organizou as quatro configurações.
02:43	Configuração de Serena e execuções válidas	O vídeo detalha os ajustes necessários para Serena e a conclusão de 12 execuções até obter uma execução utilizável por configuração.
04:14	Resultados de tokens, tempo e diferenças em relação ao teste anterior	O criador compara tokens e duração, investiga o desempenho de RTK e explica por que os resultados anteriores não se repetiram.
07:50	Custos, defeitos e configuração escolhida	O vídeo examina custos e cache, aponta falhas nas implementações e explica por que o criador manteve Headroom e desativou RTK.

Citações

No fim, mudei minha configuração do dia a dia. — 00:00

Somar os dois não melhorou os resultados aqui. — 04:14

A economia anterior não se repetiu aqui. — 07:50

Desativei RTK por enquanto e estou mantendo Headroom ativado. — 09:22

Conceitos e entidades

Claude Code (ferramenta): Ferramenta de programação usada nas quatro configurações comparadas no vídeo.
RTK (ferramenta): Ferramenta que reduz a saída de comandos antes que Claude Code a leia.
Headroom (ferramenta): Proxy local que comprime partes das solicitações antes de elas chegarem ao modelo.
Serena (ferramenta): Ferramenta disponibilizada por meio de MCP para localizar funções e consultar código relevante, além de oferecer recursos de edição.
MCP (conceito): Mecanismo usado no vídeo para conectar Claude Code às ferramentas Serena e de memória.
Opus 5 (modelo): Modelo selecionado para as execuções, configurado com esforço médio.
Gray Cut (ferramenta): Ferramenta de vídeo do criador para acelerar a edição do canal.
CLAUDE.md (ferramenta): Arquivo de instruções usado para orientar Claude Code, inclusive sobre o uso de Serena.
Graphify (ferramenta): Abordagem mencionada como comparação anterior para ajudar Claude a encontrar e ler código.
CodeGraph (ferramenta): Abordagem mencionada como comparação anterior para ajudar Claude a encontrar e ler código.

Tradução completa (pt-BR)

00:00 Achei que comparar RTK e Headroom no Claude Code seria rápido e fácil. RTK economizou tokens no meu vídeo anterior. Desta vez, até a repetição limpa usou mais do que a versão padrão. Acabei criando esse recurso 12 vezes ao longo de duas noites que avançaram até tarde. Algumas repetições foram culpa minha. Outras exigiram mais configuração do que eu esperava. No fim, mudei minha configuração do dia a dia. Vou mostrar o que realmente economizou tokens nessas execuções e por que mudei o que uso.

00:36 Como de costume, o recurso era para Gray Cut. É a ferramenta de vídeo que usei para acelerar a edição deste canal. Eu queria legendas corrigidas e destaque das palavras durante a reprodução, ambos acompanhando minhas edições na linha do tempo. Cada execução usou um worktree separado, criado a partir do mesmo commit na branch main. Selecionei Opus 5 com esforço médio e comecei no modo de planejamento. Vou deixar o prompt na tela. Claude Code puro foi a referência. Depois, testei RTK e Headroom separadamente, seguidos pelos dois juntos.

01:07 RTK reduz a saída dos comandos antes de Claude lê-la. Headroom executa um proxy local que comprime partes das solicitações antes que elas cheguem ao modelo. Headroom também disponibiliza Serena por meio de MCP. Isso ajuda Claude a encontrar funções específicas e ler o código relevante. O objetivo é parecido com o de Graphify e CodeGraph, do meu vídeo anterior. Embora a implementação seja diferente, Headroom também oferece memória compartilhada opcional em um banco de dados local. Claude Code a acessa pelo proxy. Codex usa um servidor MCP de memória

01:39 com configurações correspondentes. Os agents podem compartilhar fatos salvos. Isso me interessa, já que alterno entre agents, mas ainda não testei. A configuração básica do Headroom consiste em dois comandos: instalar o pacote Python e, depois, iniciar Claude Code pelo wrapper. O primeiro problema foram os subagents. Meu prompt já dizia para não delegar, mas Claude ainda assim iniciou workers. Então, deixei a restrição mais difícil de ignorar, usando letras maiúsculas e abrangendo tanto o planejamento quanto a implementação. Também desativei a ferramenta Agent

02:11 na inicialização. Também descobri que tinha testado o RTK 0.46.0, embora o 0.49.0 já estivesse disponível. Então, atualizei e comecei a testar de novo. Durante esses novos testes, percebi outro erro: meu terminal ainda estava com o endereço do proxy do Headroom definido. Assim, as supostas execuções apenas com RTK também passaram pelo Headroom. Desativar os servidores MCP não tinha removido essa variável de ambiente. Foi um erro na minha configuração. E isso significou mais uma repetição.

02:43 Serena foi mais confuso porque eu conseguia ver atividade na interface web dela. No explorador de arquivos, a pasta .serena também continha dados em cache da base de código. Mas Claude não estava chamando as ferramentas da Serena. Quando perguntei por quê, ele disse que, por hábito, tinha recorrido a Read e Grep. Headroom registrou Serena por padrão, mas eu precisava ativar separadamente as instruções que diziam a Claude para dar preferência à Serena. É isso que a flag –serena-instructions faz: ela adiciona orientações ao CLAUDE.md. Também

03:13 deixei explícito no prompt da tarefa que Serena deveria ser usada. Depois de outra execução, Claude disse que Serena ajudou com Python, mas não com Swift. Conferi a configuração e só Python estava listado, então adicionei Swift. As orientações do CLAUDE.md do Headroom se concentram em encontrar e ler código. Serena também tem ferramentas de edição. Serena tem uma ferramenta MCP chamada initial_instructions. Chamá-la fornece a Claude um guia de uso, incluindo instruções para editar código. A execução final apenas com Headroom não carregou esse guia

03:44 Claude usou Serena para navegar pelo código Python e as ferramentas integradas para editar. A execução combinada carregou o guia e usou bastante as ferramentas de edição. Python e Swift estavam configurados nos dois casos, mas Claude ainda usou as ferramentas de formas diferentes. Serena merece uma análise aprofundada própria. Enquanto isso, o proxy do Headroom estava funcionando. Os logs locais mostraram o proxy alterando as solicitações. À meia-noite da segunda noite, eu tinha concluído 12 execuções de programação. Finalmente, tinha uma execução utilizável para cada configuração.

04:14 Essas quatro entram nos resultados. As tentativas anteriores ficam de fora. Certo. Então, estas são as quatro execuções que estou comparando. Esses totais abrangem desde o planejamento até a resposta final de programação. A entrada em cache é contabilizada de novo toda vez que aparece em uma solicitação. Claude Code puro usou cerca de 18 milhões de tokens. RTK usou 19 milhões, ou seja, 5,5% a mais. Na execução final configurada, Headroom usou 21,7% menos tokens do que a versão padrão. A execução combinada

04:46 usou menos tokens do que a versão padrão, mas mais do que Headroom sozinho; portanto, combinar os dois não melhorou os resultados neste caso. O tempo era minha preocupação secundária. A versão padrão levou cerca de 17 minutos de tempo ativo, enquanto RTK levou quase 20. Headroom terminou apenas cerca de 20 segundos antes da versão padrão. Não chamaria isso de uma vantagem significativa de velocidade com base em uma única execução. A configuração combinada levou mais de 19 minutos. Depois das execuções, perguntei a Claude se RTK tinha ajudado. Claude disse que precisou executar

05:16 comandos extras porque RTK cortou informações de que precisava. A auditoria confirmou um exemplo. Na execução limpa com RTK, RTK truncou a saída da compilação de Swift, ocultando o status final. Claude executou outro comando de compilação para verificar, mas essa verificação adicional levou cerca de dois segundos. Isso não explica toda a lentidão. E algumas outras reclamações não correspondiam aos logs. Tanto a versão padrão quanto RTK fizeram 111 solicitações ao modelo. Mas, com RTK,

05:47 essas solicitações eram maiores, em média. Portanto, uma saída menor dos comandos não resultou em uma sessão completa menor. Se quiser mais comparações medidas ao longo da tarefa inteira, inscreva-se. Alguém me comprou cem cafés, mas não consegui sacar o dinheiro no meu país. Devolvi o valor e criei um Patreon. Por enquanto, é bem simples. Se mais pessoas entrarem, vou adicionar créditos para apoiadores e cargos no Discord. Conteúdo exclusivo para membros é outra possibilidade. Os links do Patreon e do Discord estão na descrição.

06:18 RTK economizou tokens na comparação anterior e terminou mais rápido, mas era um recurso diferente: adicionar dicas de vocabulário para a transcrição. Eu esperava que a tarefa maior, que exigia mais leitura, desse mais oportunidades ao RTK. Pelo visto, só o tamanho da tarefa não me diz muita coisa. As execuções anteriores também usaram subagents. A versão padrão iniciou três workers, enquanto RTK iniciou um. O uso direto deles explica cerca de 14% da diferença de tokens. A maior parte da diferença

06:48 ainda estava nas conversas principais. Naquela ocasião, a conversa principal com RTK fez menos solicitações, com menos entrada por solicitação, em média. Essa vantagem desapareceu neste teste. A versão padrão também usou buscas direcionadas e comandos como tail para limitar a saída por conta própria. Isso provavelmente deixou menos oportunidades para RTK ajudar. As versões também mudaram. A versão 0.49 consegue reduzir a saída dos comandos antes que tail pegue as últimas linhas. Ela também adiciona rtk recall para recuperar a saída

07:20 que foi cortada. Claude recebeu essa dica de recuperação durante a compilação de Swift, mas executou outro comando em vez disso. Claude Code mudou seus próprios prompts e o comportamento de cache entre os vídeos. Essas mudanças podem ser relevantes, mas não isolei o efeito delas. Minha primeira tentativa com RTK usou a versão 0.46, mas também consumiu mais tokens do que a versão padrão. Descartei essa tentativa para testar a versão atual, mas não posso simplesmente atribuir o resultado à atualização. A tarefa e a abordagem de Claude mudaram, e as execuções individuais

07:50 variam. A economia anterior não se repetiu aqui. Os totais que mostrei vêm dos logs da sessão, incluindo entrada em cache e saída gerada. As estimativas de compressão próprias do Headroom medem as alterações feitas pelo proxy. Elas são diferentes desses totais da sessão completa. Agora, vamos comparar os custos. Headroom sozinho sai cerca de um dólar mais barato do que a versão padrão. Isso representa um custo 9% menor, apesar de usar quase 22% menos tokens.

08:20 O cache explica parte dessa diferença. Ler a entrada em cache custa muito menos do que gravá-la de novo. Todas as execuções precisaram da ferramenta para sair do modo de planejamento. Veja o que aconteceu quando Claude a carregou na execução final apenas com Headroom. A maior parte desse contexto precisou ser gravada no cache. Mais uma vez, com esses preços, isso custa muito mais do que reutilizá-lo. As solicitações ocorreram com apenas dois segundos de intervalo, então é muito improvável que o cache tenha expirado normalmente. Esse padrão apareceu em todas as execuções auditadas que passaram pelo proxy do Headroom.

08:51 Isso não aconteceu na versão padrão nem no RTK puro. Os logs ainda não comprovam se foi o próprio Headroom que causou isso ou se Claude Code se comportou de outra forma por meio do proxy. Tenho uma assinatura. Esses valores em dólares me ajudam a comparar o uso, mas não são quantias descontadas da minha conta. Ainda não posso dizer por quanto tempo a mais o Headroom me permite trabalhar antes de atingir o limite da minha assinatura. Por fim, as quatro implementações finais passaram nos próprios testes, mas falharam em uma verificação adicional de cortes na linha do tempo. Uma palavra com tempo estimado

09:22 permaneceu nas legendas depois de uma edição que deveria tê-la removido. Os defeitos também foram diferentes. Em outra verificação, Headroom removeu um ponto final que a versão padrão manteve. Todas as implementações ainda precisavam de correções. Esses totais não incluem esse trabalho de reparo. Então, por enquanto, desativei RTK e estou mantendo Headroom ativado. Quero ver se a economia se mantém no trabalho do dia a dia. Se o seu repo usa várias linguagens de programação, confira a configuração da Serena e adicione as linguagens que estiverem faltando.

09:53 manualmente. Vou adicionar essa regra ao meu CLAUDE.md global quando o Serena estiver disponível. Claude deve chamar sua ferramenta de inicialização antes de explorar o código. Depois, vou analisar essas sessões e compará-las com meu uso anterior. Minha prioridade inicial é economizar tokens sem perder qualidade. Terminar mais rápido seria um bônus. As tarefas diárias serão diferentes, então isso não será um benchmark controlado. Vou sair de férias na semana que vem, então não esperem resultados em uma semana. No vídeo anterior, pedi cem curtidas

10:25 e consegui todas durante a noite. Pelo visto, defini uma meta muito baixa. Desta vez, vamos tentar chegar a 500 curtidas até eu voltar ao trabalho. Se chegarmos lá, vou fazer um vídeo de acompanhamento. Depois que eu tiver coletado e analisado dados de uso suficientes, talvez eu ainda acabe desativando o Headroom, e minha gata passou aquelas duas noites pedindo atenção e não recebendo nenhuma. Ela está muito, muito irritada agora. Para ver outra abordagem para ajudar Claude a ler menos código, assista à minha comparação entre Graphify e CodeGraph.

Transcrição original

[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.