Esta pequena IA de 2B contra a conta de tokens do Claude Code (teste real)

Autoria: Prompt Engineer 48 · 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: This Tiny 2B AI vs Claude Code’s Token Bill (Real Test) · Canal: Prompt Engineer 48 · 04:43 · Assistir no YouTube

Tópicos: Agentes de IA, Claude Code, Inferência e otimização de modelos, Modelos locais e open source, RAG, busca e recuperação de informação

Resumo

O vídeo testa o CallGrep Agent 2B, uma ferramenta local de busca semântica em código, em um laptop com 8 GB de RAM e compara seu uso com a busca normal do Claude Code. No teste publicado pelos criadores, a ferramenta reduziu tokens e custos, mas ficou mais lenta e teve uma pequena queda na precisão. No teste do vídeo, o custo caiu cerca de 13% e o uso de tokens, 8%, mas o tempo total foi aproximadamente seis vezes maior, e as respostas foram menos completas. O autor conclui que pode valer a pena em bases de código grandes, mas que a economia é pequena em projetos menores e depende do hardware e da configuração.

Pontos-chave

O CallGrep Agent recebe uma pergunta, busca localmente no repositório e retorna caminhos de arquivos e intervalos de linhas para o Claude Code.
No teste publicado, foram avaliados 13 repositórios públicos e 52 perguntas, cada uma executada três vezes.
Segundo os resultados publicados, o uso de tokens caiu 34% e o custo por pergunta passou de 7,3 para 4,4 centavos, mas a precisão caiu de 83% para 81% e o tempo aumentou.
O modelo pode ser instalado no Windows sem Python, servidor ou chave de API; o arquivo Q8 ocupa cerca de 2,7 GB e o Q4KM, 1,56 GB.
No teste local, a indexação de um repositório de aproximadamente 109 mil linhas levou 513 segundos.
Em seis perguntas, o teste local registrou 8% menos tokens e custo total de 75 centavos, ante 86 centavos sem o agente.
O teste local levou 646 segundos com o agente e 98 segundos sem ele; o autor atribui parte da lentidão à execução na GPU integrada.
O agente usou menos tokens em quatro das seis perguntas e custou menos em cinco, mas suas respostas foram completas em quatro casos e parciais em dois.
O autor considera que a ferramenta pode ser mais interessante em bases grandes, nas quais o custo por token pesa mais.

Capítulos

Início	Capítulo	Resumo
00:00	O que o CallGrep Agent promete	O vídeo apresenta a ferramenta e os resultados publicados de custo, uso de tokens, precisão e velocidade.
01:35	Instalação e teste no laptop	O autor explica os arquivos disponíveis, instala o agente e prepara um teste no repositório next-plaid.
02:38	Resultados pergunta por pergunta	O teste mostra casos em que o agente economiza tokens e outros em que é mais lento e produz resultados menos completos.
03:40	Balanço e quando vale a pena	O autor compara os totais, ressalta as limitações do teste e discute o possível valor da ferramenta em bases de código maiores.

Citações

O custo por pergunta cai de 7,3 centavos para 4,4 centavos. — 00:00

Mais barato, sim. Mais rápido, não. — 01:03

A direção corresponde ao que eles afirmam. A magnitude, não — nesta máquina e neste teste. — 03:40

Em um projeto pequeno, mal vale a configuração e os segundos extras. — 04:11

Conceitos e entidades

CallGrep (ferramenta): Mecanismo de busca semântica em código usado para localizar arquivos e trechos relevantes em um repositório.
CallGrep Agent 2B (modelo): Modelo pequeno usado pelo agente para pesquisar localmente o código e retornar caminhos e intervalos de linhas.
Claude Code (ferramenta): Ferramenta de programação usada no vídeo para consultar os repositórios e comparar os resultados com e sem o agente.
Sonnet (modelo): Modelo usado pelo Claude Code nos testes descritos no vídeo.
Opus (modelo): Modelo usado para avaliar as respostas no estudo publicado.
llama.cpp (ferramenta): Implementação mencionada como parte do processo de instalação e execução local.
next-plaid (repo): Repositório usado como base para o teste local, com aproximadamente 109 mil linhas de Rust e Python.
Apache License 2.0 (conceito): Licença indicada no vídeo para o projeto e seus arquivos.
Busca semântica em código (conceito): Método de pesquisa em um repositório usado pelo agente para localizar trechos relacionados a uma pergunta.
GPU integrada (conceito): Processador gráfico integrado do laptop que executou o agente localmente no teste.

Tradução completa (pt-BR)

00:00 Um modelo de 2 bilhões de parâmetros fica diante do Claude Code, e o custo por pergunta cai de 7,3 centavos para 4,4 centavos. É o que a Llama relata. Mas a mesma tabela mostra que ficou mais lento, e a precisão também mudou. Então, rodei o modelo no meu próprio laptop de 8 GB para ver quais desses números se confirmam. Esta é a publicação no blog da Llama, publicada em 12 de outubro. Ela se chama Call Grep Agent. E o código está no repo Next Plaid, no GitHub, com cerca de 585 estrelas no momento. Licença Apache 2.0.

00:30 Três nomes acabam sendo confundidos. Então, Call Grep é o mecanismo de busca semântica de código, Call Grep Agent 2B é o modelo, e Call Grep – Agent é o comando que executa o modelo. Quando o Claude Code precisa encontrar algo no seu repo, ele busca, lê arquivos e busca de novo, e cada turno custa tokens de API. Mas, neste caso, você envia uma pergunta, o modelo pequeno faz uma busca local e retorna caminhos de arquivos e intervalos de linhas. É daí que vem o número de 34%. Foram 13 repos públicos, 52 perguntas, cada uma executada três vezes, totalizando 624 sessões.

01:03 O Claude Code foi executado com Sonnet, e Opus avaliou as respostas. Grep simples: 142 mil tokens por pergunta. Call Grep Agent: 93 mil, ou seja, 34% menos tokens, e o custo cai de 7,3 centavos para 4,4. Mas as respostas corretas caíram de 83% para 81%, e eles dizem que essa diferença não é significativa, embora o intervalo não descarte uma queda real. E o tempo por pergunta passou de 13 segundos para 21,6. Mais barato, sim. Mais rápido, não. E isso é busca de código, não tarefas completas de engenharia de software. Eles mesmos dizem isso.

01:35 Agora, será que funciona neste laptop? Esta é a página do GGML. O padrão é o arquivo Q8, com cerca de 2,7 GB, e há também o Q4KM, com 1,56. Se a memória estiver apertada, é Apache 2.0. O título diz 2B. Os metadados do GGML dizem 3B. Certo. A instalação no Windows é feita pelo instalador do PowerShell e, depois, por Call Grep – install agent. Sem Python, sem servidor, sem chave de API. Minha primeira tentativa falhou por falta de memória durante o download do llama.cpp, porque eu tinha apenas cerca de 2 GB de RAM livres.

02:05 Executei de novo e deu certo. Depois, ele identificou a GPU como AMD Radeon Graphics. Essa é a GPU integrada deste laptop, não a RTX 4060. Então, leve isso em conta ao considerar os números de velocidade. Meu repo de teste é o próprio repo Next Plaid, com cerca de 109 mil linhas de Rust e Python. A indexação levou 513 segundos, cerca de 8 minutos e meio, uma única vez. Seis perguntas, o mesmo Claude Code, Sonnet, uma nova sessão para cada pergunta. Na execução A, usei grep, glob e read normalmente. Na execução B, pedi ao Claude

02:38 que chamasse grep – agent primeiro e lesse apenas as linhas retornadas. Uma diferença em relação à publicação do blog: eles instalaram o hook do Claude Code. Eu não queria mexer na minha configuração global, então coloquei essa instrução no system prompt. A ideia é a mesma, mas não é exatamente a configuração deles. E foram seis perguntas, uma execução para cada. É um teste pequeno. Pergunta um: sem o agent, cinco turnos, 19 segundos, 21 centavos. Com o agent, três turnos, 20 centavos. Quase não fez diferença, mas o tempo foi de 125 segundos, porque a chamada do agent local foi executada na GPU integrada.

03:09 Pergunta três: como o Call Grep escolhe qual build do llama.cpp baixar? Sem o agent, 267 mil tokens, 17 centavos. Com o agent, 93 mil tokens, menos de 10 centavos. Essa é a vantagem. Pergunta cinco: onde fica a rota de busca no servidor? Com o agent, 292 mil tokens, 15 centavos, 207 segundos. Sem ele, 145 mil tokens, 12 centavos, 15 segundos. Essa é a desvantagem. E, na pergunta um, a resposta com o agent dizia: “Não localizei essa parte nem a ligação desse argumento da CLI.”

03:40 A versão normal listou o enum, o parser, o campo armazenado e o handler da CLI. Totais das seis perguntas: 1,03 milhão de tokens sem o agent, 944 mil com ele, 8% menos. O custo foi de 86 centavos sem o agent e 75 com ele, cerca de 13% mais barato. A Llama relata 34% e 40%; no meu teste pequeno, não cheguei nem perto. Foi mais barato em cinco das seis perguntas e usou menos tokens em quatro das seis. Tempo: 98 segundos no total sem o agent, 646 com ele, cerca de

04:11 seis vezes e meia mais lento. Conferi as respostas corretas com o código: seis de seis sem o agent; quatro completas e duas parciais com ele. E essas contagens de tokens incluem cerca de 135 mil tokens de custos fixos por pergunta, da minha própria configuração do Claude Code, iguais nas duas execuções. Então, em uma configuração limpa, a porcentagem real seria maior. Minha conclusão: a tendência corresponde ao que eles afirmam. A magnitude, não, pelo menos nesta máquina e neste teste. Eles relatam que a economia aumenta conforme o tamanho do repo: 19% abaixo de 50 mil linhas, 40% entre 150 mil e 600 mil.

04:43 Então, em um projeto pequeno, mal vale a pena configurar e esperar os segundos extras. Em uma base de código grande, na qual você paga por token, vale a pena testar. Claude Code tem suporte completo a hooks; open code, Codex e Hermes são, nas palavras deles, básicos por enquanto. Se você está procurando GPUs baratas e confiáveis, eu uso RunPod, e o link está na descrição. Esse é o Call Grep Agent; os links para o repo e o modelo estão abaixo. Conte nos comentários em que tamanho de repo você testaria isso e inscreva-se se quiser ver o próximo teste de um modelo pequeno de coding agent.

Transcrição original

[00:00] A 2-billion parameter model sits in front of Claude Code, and the cost per question drops from 7.3 cents to 4.4 cents. That’s what Llama reports. But the same table shows it got slower, and the accuracy moved, too. So, I ran it on my own 8-GB laptop to see which of those numbers hold up. This is the blog post from Llama, published October 12th. It’s called Call Grep Agent. And the code lives in the next plaid repo on GitHub, about 585 stars right now. Apache 2.0

[00:30] license. Three names get mixed up. So, once Call Grep is the semantic code search engine, Call Grep Agent 2B is the model, and Call Grep {dash} {dash} Agent is the command that runs the model. When Claude Code needs something in your repo, it grabs, reads files, and grabs again, and every turn costs API tokens. But this one question goes in, the small model searches locally, and file paths and line ranges come back. Here is where the 34% comes from. 13 public repos, 52 questions, each run three times, so 624

[01:03] sessions. Claude Code ran on Sonnet, and Opus graded the answers. Plain Grep, 142,000 tokens per question. Call Grep Agent, 93,000, that is 34% fewer tokens, and cost goes from 7.3 cents to 4.4. But correct answers went from 83% to 81, and they say that gap is not significant, though the interval can’t rule out a real drop. And time per question went from 13 seconds to 21.6. Cheaper, yes. Faster, no. And this is code search, not full software engineering tasks. They

[01:35] say that themselves. Now, does it run on this laptop? This is the GGML page. The default is the Q8 file, about 2.7 GB, and there’s Q4KM at 1.56. If memory is tight, it’s Apache 2.0. The title says 2B. The GGML metadata says 3B. Okay. Install on Windows is the PowerShell installer, then Call Grep {dash} {dash} install agent. No Python, no server, no API key. My first try failed with out of memory while downloading llama.cpp because I

[02:05] had only about 2 GB of RAM free. I ran it again and it went through. Then it printed GPU AMD Radeon graphics. That’s the integrated GPU in this laptop, not the RTX 4060. So, keep that in mind for the speed numbers. My test repo is the next plaid repo itself, about 109,000 lines of Rust and Python. Indexing took 513 seconds, about 8 and 1/2 minutes one time. Six questions, same Claude code, Sonnet, fresh session each. Run A uses normal grep, glob, and read. Run B tells Claude

[02:38] to call grep-dash-dash agent first and read only the lines it returns. One difference from the blog, they installed the Claude code hook. I didn’t want to touch my global config, so I put that instruction in the system prompt, same idea, not their exact setup. And it’s six questions, one run each. That’s a small test. Question one, without the agent, five turns, 19 seconds, 21 cents. With the agent, three turns, 20 cents. Barely different, but the time was 125 seconds because the local agent call ran on the integrated GPU.

[03:09] Question three, how does call grep pick which llama.cpp build to download? Without the agent, 267,000 tokens, 17 cents. With the agent, 93,000 tokens, under 10 cents. That is the win. Question five, where is the search route in the server? With the agent, 292,000 tokens, 15 cents, 207 seconds. Without, 145,000 tokens, 12 cents, 15 seconds. That is the loss. And the answers on question one, the agent version said, “I did not locate it

[03:40] or this CLI arg wiring.” The normal version listed the enum, the parser, the stored field, and the CLI handler. Totals over six questions. Tokens, 1.03 million without, 944,000 with 8% fewer cost 86 cents without 75 with about 13% cheaper. Light on reported 34 and 40 on my small test. I did not get close. It was cheaper on five of six questions and used fewer tokens on four of six time. 98 seconds total without 646 with about

[04:11] six and a half times slower. Correct answers checked by me against the code six of six without the agent four complete and two partial with it. And these token counts include about 135,000 tokens of fixed overhead per question from my own Claude code setup the same in both runs. So the real percentage would look bigger on a clean setup. My read, the direction matches their claim. The size doesn’t on this machine in this test. They report the savings grow with repo size 19% under 50,000 lines, 40%

[04:43] for 150 to 600,000. So on a small project it’s barely worth the setup and the extra seconds. On a big code base where you pay per token it’s worth trying. Claude code has full hook support, open code, Codex and Hermes are in their own words basic for now. If you’re looking for cheap and reliable GPUs, I use RunPod and the link is in the description. That’s call grab agent, repo and model links are below. Tell me in the comments what repo size you would test it on and subscribe if you want the next small coding agent model test.