Execute o Claude Code de Graça Com Modelos Locais do Ollama

Execute o Claude Code de Graça Com Modelos Locais do Ollama

Minha assinatura do Claude Pro bateu $20 de novo mês passado. Fiquei encarando a fatura por um segundo, não porque vinte dólares seja muito — não é — mas porque eu vinha lendo sobre a nova camada de compatibilidade com a API da Anthropic do Ollama, e uma pergunta vinha me incomodando por semanas: e se eu pudesse rodar todo o framework agêntico do Claude Code contra um modelo local na minha própria GPU, e nunca enviar um único token para os servidores da Anthropic?

Então tentei. Três modelos diferentes. Duas semanas de trabalho real em projetos. E os resultados genuinamente me surpreenderam — embora não da forma que você esperaria.

A versão curta: sim, você pode rodar o Claude Code completamente de graça com modelos locais pelo Ollama, e para uma categoria específica de trabalho de desenvolvimento, é surpreendentemente capaz. Para outra categoria, falha feio. A parte interessante é descobrir exatamente onde fica essa linha, porque não é onde a maioria assume. Vou te mostrar o limite exato que encontrei — e as tarefas específicas onde os modelos locais realmente superaram minhas expectativas — depois que passarmos pela configuração.

Mas primeiro, um pouco de contexto sobre por que isso importa além de economizar vinte dólares por mês.

Por Que Rodar o Claude Code Localmente Muda o Jogo

O Claude Code é, na minha experiência, o melhor agente de programação com IA disponível agora. Roda dentro do seu terminal. Lê sua base de código, edita arquivos, executa testes, gerencia git, e executa fluxos de trabalho de desenvolvimento de múltiplas etapas com um nível de autonomia que ainda me pega de surpresa às vezes. Já construí sistemas de agentes inteiros com ele, entreguei projetos de clientes, automatizei pipelines de conteúdo em quatro sites.

O problema sempre foi o paywall. Você precisa de uma assinatura Claude Pro ou créditos de API diretos para usá-lo. Essa é uma barreira dura para estudantes, hackers independentes, contribuidores open-source, e qualquer um que só queira experimentar sem se comprometer financeiramente.

O Ollama mudou a equação. Se você não o usou, o Ollama é essencialmente Docker para modelos de linguagem — você baixa modelos da mesma forma que baixa imagens de container, e eles rodam localmente no seu hardware. A adição recente de compatibilidade com a API da Anthropic significa que o Ollama agora pode se passar pelo endpoint da API da Anthropic. O Claude Code não percebe a diferença. Ele envia requisições para o que acha que é o servidor da Anthropic, e o Ollama as intercepta, roteia para qualquer modelo local que você tenha carregado, e envia respostas no formato que o Claude Code espera.

Esse é o truque. Toda a infraestrutura de ferramentas do Claude Code — edição de arquivos, busca de código, comandos de terminal, sub-agentes, prompts agendados — tudo funciona através dessa camada de compatibilidade. O modelo que alimenta a inteligência muda. O framework permanece idêntico.

Mas aqui está o que ninguém te conta: o modelo que você escolhe importa enormemente, e a relação entre tamanho do modelo, requisitos de VRAM e performance real de programação não é linear. Testei três configurações e obtive resultados radicalmente diferentes de cada uma. Chegaremos a esses benchmarks depois da configuração — e um deles genuinamente mudou como eu penso sobre desenvolvimento local com IA.

O Que Você Precisa Antes de Começar

Deixa eu ser direto sobre requisitos de hardware, porque é aqui que muitos tutoriais se tornam desonestos. Te mostram uma configuração rodando em alguma besta de workstation e casualmente esquecem de mencionar que não vai funcionar no seu MacBook Air.

Estou rodando com uma NVIDIA GeForce RTX 4090 com 24GB de VRAM. Essa é uma GPU séria. Para os modelos de 3B parâmetros, você absolutamente não precisa disso — uma placa com 6-8GB de VRAM dá conta. Mas quando chegamos aos modelos de 32B parâmetros que realmente produzem código de qualidade, você quer 24GB no mínimo. Os MacBooks M-series com 32GB+ de memória unificada também aguentam, mas espere velocidades de inferência mais lentas comparadas com uma placa NVIDIA dedicada.

O limiar crítico é o comprimento de contexto. Para as funcionalidades agênticas do Claude Code funcionarem corretamente — especialmente a execução paralela de sub-agentes e a edição de múltiplos arquivos — você precisa de pelo menos 32K tokens de contexto. Janelas de contexto menores fazem o agente perder o rastro do conteúdo dos arquivos no meio da edição, esquecer instruções anteriores, e produzir mudanças fragmentadas que quebram sua base de código. Aprendi isso vendo um modelo de 3B com contexto de 8K tentar refatorar uma classe de serviço. Editou a primeira metade lindamente e depois esqueceu completamente que a segunda metade existia.

Aqui está a configuração mínima:

• GPU: 8GB+ VRAM para modelos pequenos (3B-7B), 24GB+ para trabalho sério (32B+)
• RAM: 16GB de memória do sistema mínimo, 32GB recomendado
• Armazenamento: 5-30GB por modelo dependendo do tamanho
• SO: macOS, Linux, ou Windows (WSL2 recomendado no Windows)
• Software: Node.js 18+, npm, Ollama, Claude Code CLI

Existem sites — eu uso sites como ollama.com/search e várias calculadoras de VRAM — que permitem combinar sua GPU exata com modelos compatíveis. Verifique antes de baixar um modelo de 20GB que sua placa não consegue rodar.

Agora a parte pela qual você realmente veio.

A Configuração Completa: Do Zero ao Funcionamento em 10 Minutos

Vou guiar primeiro no macOS/Linux, depois cobrir as diferenças do Windows. Todo o processo leva cerca de dez minutos, assumindo que você tem uma internet decente para o download do modelo.

Passo 1: Instale o Ollama

Vá a ollama.com e pegue o instalador para sua plataforma. No macOS, é um .dmg padrão. No Linux, tem um comando de uma linha:

curl -fsSL https://ollama.com/install.sh | sh

Após a instalação, verifique que está rodando:

ollama --version
# Deve mostrar algo como: ollama version 0.6.x

O Ollama roda como serviço em segundo plano. No macOS inicia automaticamente. No Linux, pode ser necessário iniciar manualmente:

# Iniciar serviço do Ollama (Linux)
systemctl start ollama

# Ou rodar diretamente
ollama serve

O servidor escuta em http://localhost:11434 por padrão. Essa URL importa — é onde o Claude Code vai se conectar.

Passo 2: Baixe Seu Primeiro Modelo

Aqui é onde fica interessante. Você está escolhendo o cérebro que vai alimentar seu agente de programação. Testei três, e te dou a recomendação de cara: comece com qwen2.5-coder:3b para sua primeira execução. É rápido, leve, e bom o suficiente para provar o conceito antes de investir tempo baixando modelos maiores.

# Rápido e leve — ótimo para testar a configuração
ollama pull qwen2.5-coder:3b

# Mais capaz — precisa de 16GB+ VRAM
ollama pull qwen2.5-coder:14b

# O de verdade — precisa de 24GB+ VRAM mas genuinamente impressionante
ollama pull qwen2.5:32b

Os tamanhos de download são aproximadamente 2GB, 9GB e 20GB respectivamente. Enquanto baixa, vamos preparar o Claude Code.

Passo 3: Instale o Claude Code

Se você ainda não tem o Claude Code instalado, é uma instalação npm direta:

npm install -g @anthropic-ai/claude-code

Verifique a instalação:

claude --version

Você também pode usar o app de desktop do Claude Code se preferir — a abordagem de variáveis de ambiente funciona com ambos.

Passo 4: Aponte o Claude Code para o Ollama

Este é o passo crítico. Você precisa dizer ao Claude Code para parar de procurar a API cloud da Anthropic e em vez disso falar com seu servidor local do Ollama. Duas variáveis de ambiente fazem isso acontecer.

No macOS/Linux:

export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_API_KEY=ollama

No Windows (Command Prompt):

set ANTHROPIC_BASE_URL=http://localhost:11434
set ANTHROPIC_API_KEY=ollama

No Windows (PowerShell):

$env:ANTHROPIC_BASE_URL = "http://localhost:11434"
$env:ANTHROPIC_API_KEY = "ollama"

A chave API pode ser literalmente qualquer coisa — o Ollama não verifica. Eu uso "ollama" porque fica óbvio no meu histórico de shell que estou rodando localmente, não queimando créditos reais de API.

Para tornar permanente, adicione essas linhas de export ao seu .bashrc, .zshrc, ou perfil de shell. Eu mantenho as minhas em um script separado que carrego quando quero modo local:

# ~/scripts/claude-local.sh
export ANTHROPIC_BASE_URL=http://localhost:11434
export ANTHROPIC_API_KEY=ollama
echo "Claude Code pointed at local Ollama"

Depois é só rodar source ~/scripts/claude-local.sh quando quero trocar. Quando preciso do Claude real, removo essas variáveis ou abro um terminal novo com minha chave real da Anthropic.

Passo 5: Lance o Claude Code Com Seu Modelo Local

Agora o momento da verdade:

claude --model qwen2.5-coder:3b

Se tudo está conectado corretamente, o Claude Code inicia parecendo exatamente como sempre — mesma interface, mesmos comandos, mesmas capacidades de ferramentas. A única diferença é a inteligência por trás. Seus prompts vão para localhost em vez dos servidores da Anthropic. Seus tokens nunca saem da sua máquina.

Tente algo simples primeiro:

> Create a Python function that reads a CSV file and returns the top 5 rows sorted by a specified column

Se você vê o modelo pensando, gerando código, e oferecendo escrever em um arquivo — parabéns. Você está rodando o Claude Code de graça no seu próprio hardware.

É aqui que a maioria dos tutoriais termina. Mas a história interessante é o que acontece quando você realmente tenta usar isso para trabalho real.

Três Modelos, Duas Semanas, Uma Avaliação Honesta

Me comprometi a usar essa configuração local por duas semanas de trabalho de desenvolvimento real. Não projetos de brinquedo — trabalho real de clientes, prazos reais, bases de código reais. Rotacionei entre três modelos e rastreei o que cada um lidava bem e onde cada um falhava.

Qwen 2.5 Coder 3B: O Velocista

Esse pequeno modelo roda super rápido mesmo em hardware modesto. Os tempos de resposta ficaram abaixo de 2 segundos para a maioria dos prompts. Usei para:

• Gerar endpoints CRUD boilerplate em Laravel
• Escrever esqueletos de testes unitários
• Criar interfaces TypeScript a partir de exemplos JSON
• Scaffolding simples de arquivos e inicialização de projetos
• Geração de mensagens de commit de git

Para essas tarefas, rendeu talvez 70-75% da qualidade do Claude Sonnet. O código compilava. A lógica estava correta. As convenções de nomes eram razoáveis. Para scaffolding especialmente — gerar o esqueleto de uma nova classe de serviço, uma nova rota de API, um novo componente React — foi surpreendentemente capaz.

Onde falhou: qualquer coisa que exigisse consciência de múltiplos arquivos. Pedi para refatorar um serviço de autenticação que tocava quatro arquivos diferentes. Lidou com o primeiro arquivo perfeitamente, fez mudanças razoáveis no segundo, e no terceiro arquivo tinha perdido o rastro das mudanças que já tinha feito. O quarto arquivo foi essencialmente alucinado — referenciando funções que achava ter escrito mas não tinha.

O modelo 3B pensa um arquivo de cada vez. Isso é ok para tarefas isoladas. É um impeditivo para trabalho arquitetural.

Qwen 2.5 32B: A Surpresa

Esperava melhoria incremental. Obtive uma mudança qualitativa. O modelo 32B não apenas cometeu menos erros — demonstrou raciocínio genuíno de múltiplas etapas que o modelo 3B não conseguia nem chegar perto.

Dei a ele a mesma refatoração de autenticação. Planejou as mudanças nos quatro arquivos antes de escrever uma única linha. Identificou uma dependência circular que eu não tinha percebido. Sugeriu extrair uma interface compartilhada para prevenir o tipo de desvio que tipicamente acontece quando você modifica serviços relacionados independentemente.

Foi tão bom quanto o Claude Sonnet? Não. A estrutura do código foi aproximadamente 85% tão limpa, e ocasionalmente usou padrões que eram tecnicamente corretos mas não idiomáticos para o framework que eu estava usando. Mas fez algo que o modelo 3B não conseguia fazer de jeito nenhum: raciocinou sobre as relações entre arquivos em vez de tratar cada um isoladamente.

O trade-off é velocidade. Onde o modelo 3B respondia em 2 segundos, o modelo 32B levava 8-15 segundos por resposta, e operações complexas de múltiplos arquivos podiam levar mais de 30 segundos. Na minha RTX 4090 com 24GB de VRAM, usou quase tudo disponível. Se você tem menos VRAM, espere overhead de quantização e inferência ainda mais lenta.

A funcionalidade de sub-agentes paralelos me surpreendeu mais aqui. Configurei dois sub-agentes — um pesquisando a API de um pacote npm e outro escrevendo o código de integração. Ambos rodaram simultaneamente pelo modelo local. A coordenação não foi perfeita (o agente de pesquisa às vezes produzia resumos que o agente de programação interpretava errado), mas o fato de funcionar de todo com um modelo local rodando em hardware de consumo genuinamente me impressionou.

O Claude Sonnet Real: Ainda a Referência

Depois de duas semanas com modelos locais, voltei para o Claude Sonnet real por um dia. A diferença foi imediatamente aparente em três áreas:

Cadeias de raciocínio complexas. Uma tarefa que exigia entender lógica de negócio, mapeá-la para mudanças de schema de banco de dados, gerar migrations, atualizar relações de modelos, e modificar respostas de API — o Claude Sonnet lidou com isso como um único pensamento coerente. Os modelos locais precisavam de orientação constante a cada etapa.

Nuances de qualidade de código. O Claude Sonnet não apenas escreve código funcional. Escreve código que segue as convenções do projeto específico que está olhando. Capta padrões na sua base de código existente e os espelha. Os modelos locais escreveram código genericamente correto que muitas vezes parecia vir de um projeto diferente.

Recuperação de erros. Quando algo não funcionava, o Claude Sonnet analisava o erro, rastreava até a causa raiz, e corrigia — frequentemente antecipando problemas secundários. Os modelos locais tendiam a corrigir o sintoma superficial e criar um novo problema mais adiante.

Dito isso — e essa é a parte que me manteve pensando — para provavelmente 40-50% das minhas tarefas diárias de programação, o modelo local de 32B era bom o suficiente. Não perfeito. Não um substituto. Mas bom o suficiente para não perder tempo nem qualidade na saída.

Aqui está a verdadeira questão que isso levanta, e é uma que ainda estou processando.

Os Trade-Offs Honestos Que Ninguém Quer Discutir

Vi uma dúzia de posts afirmando que você pode "substituir sua assinatura do Claude completamente" com modelos locais. Isso é desonesto ou escrito por alguém que não usa o Claude Code para trabalho sério. Deixa eu ser direto sobre as limitações.

A qualidade do uso de ferramentas varia enormemente. O poder do Claude Code vem da sua capacidade de usar ferramentas — ler arquivos, executar comandos, buscar em bases de código, editar múltiplos arquivos atomicamente. Os modelos oficiais do Claude foram especificamente treinados e ajustados para esse comportamento de chamada de ferramentas. Os modelos locais suportam o formato de API para chamadas de ferramentas, mas seu uso real de ferramentas é menos confiável. Vi o modelo 3B tentar editar um arquivo que não existia aproximadamente uma vez por sessão. O modelo 32B foi melhor mas ainda ocasionalmente chamava ferramentas com argumentos malformados.

Trabalho sensível à segurança é um não absoluto. Faço consultoria de cibersegurança. Revisão de código para vulnerabilidades, automação de testes de penetração, geração de relatórios de auditoria de segurança — eu nunca confiaria em um modelo open-source de 3B para esse trabalho. Os modos de falha são perigosos demais. Um vetor de SQL injection perdido ou uma avaliação alucinada de "esse código é seguro" poderia causar dano real. Para trabalho de segurança, uso o Claude Sonnet real sem exceção.

O gerenciamento da janela de contexto parece diferente. Mesmo com 32K de contexto, os modelos locais parecem "esquecer" o contexto anterior mais agressivamente que os modelos oficiais do Claude. Suspeito que é uma combinação de diferenças no mecanismo de atenção e artefatos de quantização. O impacto prático: você precisa re-declarar restrições importantes com mais frequência, e sessões longas degradam mais rápido.

Atualizações de modelos são sua responsabilidade. Quando a Anthropic melhora o Claude, todo usuário recebe a atualização instantaneamente. Com modelos locais, você precisa rastrear lançamentos, baixar novas versões, testá-las contra seus fluxos de trabalho, e lidar com regressões ocasionais. Já fui pego por uma atualização de modelo que quebrou a compatibilidade de chamada de ferramentas por dois dias antes de um fix ser lançado.

Aqui está minha avaliação honesta, e gostaria que alguém tivesse me dito isso antes de começar: essa configuração é um complemento, não um substituto. Uso modelos locais para os 40-50% inferiores de tarefas — scaffolding, boilerplate, automação simples, geração de testes, rascunhos de documentação. Uso o Claude real para os 50-60% superiores — decisões de arquitetura, refatoração complexa, trabalho sensível à segurança, qualquer coisa onde diferenças sutis de qualidade se acumulam em problemas reais.

Essa divisão reduziu meu uso da API do Claude em quase metade. O que significa que mesmo ainda pagando pelo Pro, estou obtendo mais valor de cada dólar porque só envio os problemas difíceis para o melhor modelo.

Essa é a mudança de mentalidade. Não pense "substituto gratuito." Pense "roteamento inteligente."

Configuração Avançada: Tirando o Máximo do Seu Setup

Uma vez que a configuração básica funciona, há algumas otimizações que fizeram diferença significativa no meu fluxo de trabalho.

Configuração Persistente do Modelo

Em vez de especificar o modelo a cada lançamento, você pode defini-lo como padrão:

# Adicione ao seu .bashrc ou .zshrc
export CLAUDE_MODEL=qwen2.5-coder:3b

# Depois é só lançar com
claude

Na verdade mantenho dois aliases:

# No .zshrc
alias claude-local='source ~/scripts/claude-local.sh && claude --model qwen2.5:32b'
alias claude-fast='source ~/scripts/claude-local.sh && claude --model qwen2.5-coder:3b'
alias claude-pro='unset ANTHROPIC_BASE_URL && claude'

Três comandos. Três níveis. Local rápido para tarefas rápidas, local pesado para trabalho substancial, e Pro para o de verdade. Alterno entre eles múltiplas vezes por dia dependendo do que estou fazendo.

Otimização de Comprimento de Contexto

Por padrão, o Ollama pode não expor a janela de contexto completa que seu modelo suporta. Você pode configurar isso no Modelfile ou em tempo de execução:

# Verifique a configuração atual do seu modelo
ollama show qwen2.5-coder:3b

# Crie um Modelfile personalizado com contexto estendido
cat << 'EOF' > Modelfile
FROM qwen2.5-coder:3b
PARAMETER num_ctx 32768
PARAMETER temperature 0.1
EOF

ollama create qwen-code-extended -f Modelfile

Definir a temperatura para 0.1 (em vez do padrão) torna a geração de código mais determinística e menos criativa. Para tarefas de programação, você quer consistência acima de criatividade. Subi para 0.4 apenas quando gerava documentação ou mensagens de commit onde alguma variedade ajuda.

Monitoramento de Uso da GPU

Fique de olho no uso da sua VRAM, especialmente com modelos maiores:

# GPUs NVIDIA
watch -n 1 nvidia-smi

# macOS com Apple Silicon
sudo powermetrics --samplers gpu_power -i 1000

Se sua GPU fica sem VRAM, o Ollama silenciosamente volta para inferência na CPU, e os tempos de resposta passam de segundos para minutos. Tive sessões onde não percebi que isso aconteceu porque as respostas continuavam chegando — só que dolorosamente lentas. Verifique a utilização da sua GPU se as coisas ficarem repentinamente lentas.

Usando Diferentes Modelos para Diferentes Sub-Tarefas

Isso é experimental, mas o sistema de sub-agentes do Claude Code teoricamente permite que diferentes agentes usem diferentes modelos. Na prática, todos são roteados pelo mesmo endpoint do Ollama, mas você pode rodar múltiplas instâncias do Ollama em portas diferentes com diferentes modelos carregados:

# Terminal 1: Modelo pesado para o agente principal
OLLAMA_HOST=0.0.0.0:11434 ollama serve

# Terminal 2: Modelo leve para sub-agentes
OLLAMA_HOST=0.0.0.0:11435 ollama serve

Ainda não encontrei uma forma limpa de fazer o Claude Code rotear sub-agentes para uma porta diferente, mas esse é o tipo de otimização que a comunidade provavelmente vai resolver nos próximos meses. A arquitetura suporta em teoria.

O Que Realmente Melhorou no Meu Fluxo de Trabalho

Depois de duas semanas de uso híbrido — modelos locais para trabalho rotineiro, Claude real para tarefas complexas — três coisas mensuráveis mudaram.

Os custos de tokens caíram aproximadamente 45%. Meu painel da Anthropic mostrou a diminuição claramente. Todas as tarefas simples que antes queimavam tokens reais — scaffolding de arquivos, geração de esqueletos de testes, endpoints de API boilerplate, operações de git — agora rodavam em computação local. Enviava menos requisições para a Anthropic, e as que enviava eram tarefas de maior complexidade que realmente precisavam da capacidade de raciocínio do Claude.

A velocidade de iteração aumentou para tarefas rápidas. Sem latência de rede. Sem limitação de taxa. Sem esperar pelos servidores da Anthropic em horários de pico. O modelo local de 3B respondia mais rápido que qualquer API na nuvem poderia, e para tarefas simples, velocidade importa mais que brilhantismo. Gerar uma interface TypeScript a partir de um payload JSON? Não preciso de inteligência nível Sonnet para isso. Preciso que seja feito em menos de 2 segundos.

Me tornei mais intencional sobre a seleção de modelos. Esse foi o benefício inesperado. Antes desse experimento, cada tarefa ia para o mesmo modelo ao mesmo custo. Agora penso ativamente sobre qual nível de inteligência uma tarefa requer antes de começá-la. Esse framework mental — "essa é uma tarefa de 3B, de 32B, ou de Sonnet?" — me tornou um desenvolvedor mais eficiente independente das ferramentas. Comecei a agrupar tarefas de complexidade similar. Melhorei em decompor trabalho complexo em sub-tarefas simples que podiam ser tratadas localmente.

Os resultados não são dramáticos — não estou afirmando uma melhoria de produtividade de 10x. O número honesto é talvez uma melhoria de 15-20% na produtividade diária, principalmente por eliminar latência em tarefas rotineiras e ser mais reflexivo sobre quando invoco computação cara.

Para uma configuração que não custa nada além do hardware que você já tem, é um bom retorno.

Os Modelos Que Valem a Pena Testar Agora

Referência rápida do que é realmente bom para tarefas de programação no início de 2026:

Qwen 2.5 Coder Series — Minha recomendação atual. As variantes específicas para código são fine-tuned em código e superam substancialmente os modelos Qwen de propósito geral para tarefas de desenvolvimento. O de 3B é ótimo para velocidade, o de 14B é um bom meio-termo, e o de 32B é genuinamente impressionante.

DeepSeek Coder V2 — Alternativa forte, especialmente para trabalho pesado em Python. O suporte a chamada de ferramentas é bom. O gerenciamento de contexto é competitivo com o Qwen.

GLM 4 — Vale testar se suas tarefas envolvem manipulação de dados estruturados ou integração de API. Lida bem com JSON e sua implementação de chamada de funções é limpa.

Variantes do CodeLlama — Ficando para trás das opções Qwen e DeepSeek para a maioria das tarefas, mas ainda viáveis se você está em hardware limitado e precisa de algo que rode bem a 7B parâmetros.

Verifique a compatibilidade do modelo com seu hardware antes de se comprometer com um download. Um modelo que não cabe na sua VRAM e volta para inferência na CPU não está te economizando nada — está te custando tempo.

Seu Desafio de 24 Horas

Aqui está o que eu quero que você faça antes de amanhã a esta hora. Não semana que vem. Não "quando der tempo." Hoje.

Instale o Ollama. Baixe qwen2.5-coder:3b. Configure as duas variáveis de ambiente. Lance o Claude Code com --model qwen2.5-coder:3b. Depois dê a ele uma tarefa real do seu projeto atual — não um exercício de hello-world, mas algo que você realmente precisaria feito. Uma função utilitária. Um arquivo de testes. Uma migração de configuração.

Observe o que acontece. Note onde acerta e onde tropeça. Essa experiência em primeira mão vai te dizer mais sobre se essa configuração se encaixa no seu fluxo de trabalho do que qualquer blog post — incluindo este.

Se o modelo 3B te impressionar (e para tarefas simples, provavelmente vai), baixe o de 32B depois e tente a mesma tarefa. O salto de qualidade vai te fazer repensar o que "bom o suficiente" significa para IA local.

Ainda estou rodando tanto local quanto cloud. Suspeito que vou continuar por muito tempo. Mas a opção de cair para computação local gratuita para metade das minhas tarefas diárias enquanto mantenho o modelo premium para o trabalho que o exige — isso não é um compromisso. É simplesmente alocação inteligente de recursos.

E honestamente? A melhor parte não é o dinheiro economizado. É a velocidade. Sem ida e volta pela rede. Sem limites de taxa. Sem mensagens de "Anthropic está enfrentando alta demanda" às 14h quando todo mundo está enviando prompts. Apenas IA de programação instantânea, local, privada — nos seus termos, no seu hardware, quando você quiser.

Sua vez.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io