OpenClaw agora suporta Ollama: configuração com um único comando

OpenClaw agora suporta Ollama: configuração com um único comando

Eu estava no meio da configuração de mais uma chave de API na nuvem — a quarta deste mês — quando uma notificação apareceu no Discord do OpenClaw. O Ollama agora era um provedor oficial. Não um hack da comunidade. Não um contorno envolvendo três arquivos de configuração e uma reza. Uma integração oficial de primeira classe sustentada por um único comando de configuração.

Larguei o que estava fazendo e executei imediatamente.

openclaw onboard --auth-choice ollama

Só isso. Meus modelos locais do Ollama — aqueles que eu vinha usando para geração de código, assistência na escrita e análise de dados — estavam de repente disponíveis em todos os apps de mensagens que uso. WhatsApp. Telegram. Discord. Sem chaves de API. Sem contas da nuvem. Sem picos de latência às 14h quando metade do planeta decide acessar o mesmo endpoint de inferência.

O que aconteceu na semana seguinte mudou fundamentalmente como eu penso sobre assistentes pessoais de IA. E honestamente, me fez questionar por que eu vinha pagando por inferência na nuvem todo esse tempo.

Por que este anúncio importa mais do que você imagina

Aqui está um contexto que torna essa integração com o Ollama significativa além da óbvia reação "legal, mais um provedor".

O OpenClaw — o assistente pessoal de IA de código aberto criado por Peter Steinberger (@steipete) — explodiu em popularidade desde o final de janeiro de 2026. O projeto atingiu 247.000 estrelas no GitHub no início de março. Não é apenas um chatbot no seu terminal. O OpenClaw é um sistema agêntico completo que roda localmente na sua máquina e se conecta aos seus apps de mensagens. Ele lê e-mails, gerencia calendários, faz check-in em voos, navega na web, escreve e executa código — tudo acionado a partir de uma simples mensagem de chat.

O problema, até agora, era a espinha dorsal de IA. Você precisava de um provedor de LLM na nuvem. Claude, GPT, DeepSeek — todas opções sólidas, mas todas exigindo chaves de API, rastreamento de uso e contas mensais que escalam conforme você realmente usa seu assistente. Para desenvolvedores como eu que usam agentes de IA dezenas de vezes por dia, esses custos se acumulam rápido.

O Ollama muda essa equação completamente. Execute seus modelos localmente, não pague nada pela inferência e mantenha cada conversa no seu próprio hardware. As implicações de privacidade por si só merecem atenção — mas a economia de custos e a execução local sem latência? Foi isso que me empolgou o suficiente para testar na mesma hora em que foi lançado.

Mas antes de guiá-lo pela configuração e pelo que aprendi rodando isso por uma semana, há uma parte desta história que a maioria está perdendo — e tem a ver com quais modelos realmente funcionam bem como cérebro do OpenClaw.

A história de origem que você deveria conhecer

Se você tem acompanhado a saga do OpenClaw, sabe que o nome passou por uma jornada e tanto. Peter Steinberger originalmente o lançou como Clawdbot em novembro de 2025. O projeto viralizou no final de janeiro de 2026 — em parte porque o conceito de rodar um agente pessoal de IA pelo WhatsApp era genuinamente inovador, e em parte porque o @steipete tem um talento para construir coisas que desenvolvedores imediatamente querem usar.

Então veio a situação de marca registrada com a Anthropic, uma rápida mudança de nome para Moltbot (que, sendo justo, nunca soou muito bem), e finalmente o pouso em OpenClaw. A marca da lagosta se manteve em tudo isso. Se você tem visto o icônico emoji de lagosta por toda parte nos círculos de desenvolvedores de IA ultimamente, agora sabe de onde vem.

O nome "OpenClaw" e a metáfora da muda realmente capturam o que torna este projeto especial. Lagostas trocam de carapaça para crescer. O OpenClaw continua se livrando de limitações — primeiro o modelo de código fechado, depois a dependência de um único provedor, e agora o requisito de APIs na nuvem por completo.

Quero fazer um reconhecimento específico ao @steipete aqui. Não apenas por construir o OpenClaw em primeiro lugar, mas pela forma como o projeto foi conduzido durante sua fase de crescimento explosivo. A integração com o Ollama não aconteceu isoladamente — foi revisada, testada e refinada com contribuições reais da comunidade. E honestamente, ter alguém com a formação em engenharia do Steinberger (ele construiu o PSPDFKit, um dos SDKs de PDF mais respeitados em desenvolvimento mobile) liderando as decisões de arquitetura me dá confiança de que isso não é apenas um trabalho improvisado colado na lateral. A integração é sólida porque o processo de revisão foi rigoroso.

Agradecimento especial ao @steipete por ajudar e revisar a integração do provedor Ollama. A comunidade de IA de código aberto fica melhor quando engenheiros experientes investem seu tempo em acertar os fundamentos.

Então, como é a configuração real? É quase anticlimáticamente simples.

Como configurar o OpenClaw com Ollama em menos de cinco minutos

Vou explicar exatamente o que fiz, incluindo os pequenos obstáculos que encontrei, para que você possa evitá-los.

Passo 1: Certifique-se de que o Ollama está rodando

Isso parece óbvio, mas já vi pessoas tropeçarem nisso. Você precisa do Ollama instalado e rodando com pelo menos um modelo baixado.

# Check Ollama is running
ollama list

# If you don't have a model yet, grab one
# OpenClaw recommends models with 64K+ context windows
ollama pull qwen3-coder

O requisito da janela de contexto é o que a maioria dos guias pula. O OpenClaw precisa de pelo menos 64.000 tokens de contexto para lidar confiavelmente com tarefas agênticas de múltiplos passos — do tipo em que ele está lendo uma thread de e-mail, redigindo uma resposta, verificando seu calendário em busca de conflitos e depois enviando a resposta. Modelos com contexto curto funcionarão para consultas simples, mas falharão em qualquer coisa que exija raciocínio sustentado através de múltiplas chamadas de ferramentas.

Meus modelos recomendados para o OpenClaw em março de 2026:

Tenho usado o qwen3-coder para a maioria das tarefas e alternando para o glm-4.7-flash quando preciso apenas de respostas rápidas. A beleza dos modelos locais é que trocar não custa nada — não precisa de uma chave de API diferente, nem de um nível de cobrança diferente. Basta mudar o nome do modelo.

Passo 2: Execute o comando de configuração

Aqui é onde a mágica acontece:

openclaw onboard --auth-choice ollama

O assistente faz várias coisas automaticamente:

1. Detecta sua instalação do Ollama — verifica o endereço padrão (geralmente http://localhost:11434) e confirma a conexão
2. Lista seus modelos disponíveis — cada modelo que você baixou aparece para seleção
3. Define seu modelo padrão — se você só tem um modelo, ele seleciona automaticamente. Caso contrário, você escolhe.
4. Configura o provedor — escreve a configuração necessária para que o OpenClaw saiba rotear todas as solicitações de inferência para sua instância local do Ollama
5. Instala o daemon gateway — o processo em segundo plano que conecta seus apps de mensagens ao agente OpenClaw

Todo o processo levou cerca de 90 segundos. Sem arquivos JSON para editar manualmente. Sem variáveis de ambiente para exportar. Sem containers Docker para orquestrar. Apenas responda às perguntas e pronto.

🦞 OpenClaw Onboard — Provider Setup
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Detected Ollama at localhost:11434 ✓
Available models:
  → qwen3-coder (128K context) ✓ recommended
  → glm-4.7-flash (64K context) ✓ compatible
  → llama3.3 (8K context) ⚠ low context

Selected: qwen3-coder
Gateway daemon installed ✓
Provider configured ✓

Your lobster is ready. 🦞

Essa última linha me arrancou um sorriso. A personalidade da equipe do OpenClaw transparece até na saída do CLI.

Passo 3: Conecte seus apps de mensagens

Esta é a parte onde o OpenClaw se torna genuinamente diferente de rodar o Ollama sozinho. O Ollama por si só é um servidor de inferência local — poderoso, mas você interage com ele através de um terminal ou uma chamada de API. O OpenClaw o transforma em um assistente que mora nos apps que você já tem abertos o dia todo.

# Connect WhatsApp (uses QR code pairing)
openclaw connect whatsapp

# Connect Telegram
openclaw connect telegram --token YOUR_BOT_TOKEN

# Connect Discord
openclaw connect discord --token YOUR_BOT_TOKEN

Conectei o WhatsApp primeiro porque é onde passo a maior parte do meu tempo de mensagens. O pareamento por código QR levou cerca de 10 segundos. Depois disso, eu podia mandar mensagem para meu bot do OpenClaw pelo WhatsApp e receber respostas alimentadas inteiramente pelo meu modelo local qwen3-coder.

Nenhum dado saindo da minha máquina. Sem custos de API. A resposta vinha da GPU a um metro de mim.

Passo 4: Teste com uma tarefa real

Não diga apenas "olá" e dê por encerrado. Dê algo que exercite as capacidades agênticas:

Me: Check my calendar for tomorrow and draft a summary
    of what I have scheduled. If there are any conflicts,
    flag them.

OpenClaw 🦞: Looking at your calendar for March 17...

You have 4 events tomorrow:
- 9:00 AM - Standup (30 min)
- 10:30 AM - Client call with Ramlit team (1 hr)
- 11:00 AM - Code review session (1 hr) ⚠️ CONFLICT
- 2:00 PM - Deploy planning (45 min)

⚠️ Conflict detected: "Client call" (10:30-11:30)
overlaps with "Code review" (11:00-12:00) by 30 minutes.

Suggestion: Move code review to 1:00 PM? That gives you
a 1-hour buffer before deploy planning. Want me to
reschedule it?

Toda essa interação — acesso ao calendário, detecção de conflitos, geração de sugestões — rodou no meu modelo local do Ollama. A resposta chegou em cerca de 4 segundos. Com uma API na nuvem, eu teria latência de rede além do tempo de inferência, mais pagando pelo privilégio.

A coisa que mais me surpreendeu: a diferença de qualidade entre rodar o qwen3-coder localmente pelo OpenClaw versus usar um modelo na nuvem foi menor do que eu esperava. Para tarefas rotineiras de assistente — redação de e-mails, gerenciamento de calendário, perguntas rápidas de código, organização de arquivos — o modelo local lidou perfeitamente. Só notei a diferença ao fazer cadeias de raciocínio complexas de múltiplos passos que exigiam manter grandes quantidades de contexto simultaneamente.

Se você prefere que alguém construa esse tipo de configuração de assistente pessoal de IA do zero, adaptado ao seu fluxo de trabalho, aceito projetos personalizados de automação com IA. Você pode ver o que já construí em fiverr.com/s/EgxYmWD.

O que acontece quando todos os seus modelos do Ollama funcionam com o OpenClaw?

Esta é a parte que eu não apreciei totalmente até ter rodado a configuração por alguns dias. Quando o Ollama é seu provedor do OpenClaw, você não tem acesso a apenas um modelo. Você tem acesso a cada modelo que baixou. E pode alternar entre eles instantaneamente.

Me: /model glm-4.7-flash
OpenClaw 🦞: Switched to glm-4.7-flash ✓

Me: Quick — what's the CORS header syntax for allowing
    specific origins?

OpenClaw 🦞: Access-Control-Allow-Origin: https://yourdomain.com

For multiple origins, you'll need server-side logic —
the header only accepts one origin or *. In Express:

app.use(cors({
  origin: ['https://a.com', 'https://b.com']
}));

A resposta do glm-4.7-flash chegou em menos de um segundo. Para consultas rápidas e lembretes de sintaxe, o modelo menor é perfeito. Não preciso de um modelo de 120 bilhões de parâmetros para me lembrar de um cabeçalho CORS.

Mas para tarefas profundas — depurar uma condição de corrida complexa, analisar uma base de código ou redigir um documento técnico detalhado — eu troco para o qwen3-coder e deixo ele trabalhar no seu tempo. A capacidade de combinar a capacidade do modelo com a complexidade da tarefa é algo que você simplesmente não consegue fazer tão fluidamente com provedores na nuvem. Com o Ollama, o custo de trocar é literalmente zero.

O padrão de roteamento de modelos que adotei

Depois de uma semana de experimentação, aqui está como tenho usado os diferentes modelos:

Perguntas rápidas e consultas — glm-4.7-flash. Rápido, barato (grátis), preciso para conteúdo factual. Uso para provavelmente 60% das minhas interações diárias.

Geração e revisão de código — qwen3-coder. Melhor em manter o contexto ao longo de arquivos de código longos, entende padrões específicos de frameworks e gera código mais pronto para produção.

Escrita longa e análise — glm-4.7 ou kimi-k2.5. Quando preciso que o modelo mantenha muito contexto e produza resultados nuançados, essas são minhas escolhas principais.

Solicitações experimentais e inusitadas — qualquer modelo novo que baixei naquela semana. Um dos prazeres do Ollama é testar novos modelos assim que são lançados. Na semana passada testei o gpt-oss:20b pela primeira vez e fiquei impressionado com seu raciocínio em tarefas com muita matemática.

O ponto é: o OpenClaw não se importa com qual modelo você está rodando. A integração trata o Ollama como um provedor unificado. Seus apps de mensagens não sabem nem se importam se a resposta veio de um modelo de 7 bilhões ou de 120 bilhões de parâmetros. Essa camada de abstração é limpa, e é uma das razões pelas quais essa integração parece uma funcionalidade de primeira classe em vez de um remendo improvisado.

Rodando OpenClaw localmente: o que ninguém te avisa

Eu faria um desserviço se fizesse isso parecer pura magia sem compromissos. Encontrei limitações reais durante minha semana de testes, e você deveria conhecê-las antes de apostar tudo na inferência local.

A memória da GPU é seu gargalo

Os modelos maiores — gpt-oss:120b, kimi-k2.5, qualquer coisa acima de 30 bilhões de parâmetros — precisam de VRAM séria. Estou rodando uma máquina com uma GPU capaz, e ainda assim tive que ser cuidadoso sobre qual modelo mantinha carregado. O Ollama pode descarregar para CPU, mas a diferença de velocidade é brutal. Uma consulta que leva 3 segundos na GPU leva 40 segundos na CPU para um modelo grande.

Meu conselho: Comece com um modelo que caiba confortavelmente na memória da sua GPU. O qwen3-coder na sua quantização padrão roda perfeitamente com 16GB de VRAM. Não busque o modelo maior porque parece impressionante — busque aquele que responde rápido o suficiente para não quebrar seu fluxo.

A janela de contexto não é só um número

A documentação do OpenClaw diz 64K de contexto mínimo, e eles falam sério. Tentei rodar um modelo com 32K de contexto e tive problemas na terceira tarefa de múltiplos passos. O agente perdeu o controle do histórico da conversa no meio da tarefa e começou a repetir ações que já havia completado. Mudar para um modelo de 64K+ resolveu instantaneamente.

Isso faz sentido quando você pensa no que o OpenClaw está fazendo. Ele não está apenas tendo uma conversa — está mantendo histórico de chamadas de ferramentas, resultados de funções, prompts do sistema e toda a sua thread de mensagens. Essa sobrecarga consome contexto rapidamente. Um modelo com 8K de contexto pode responder uma única pergunta bem, mas desmorona no momento em que o OpenClaw precisa encadear três ou quatro ações juntas.

A primeira resposta é lenta (depois é rápida)

O Ollama carrega os modelos na memória no primeiro uso. Se o modelo não estiver carregado quando você envia sua primeira mensagem do dia, espere um atraso de 10-30 segundos enquanto ele carrega. Depois disso, as respostas são rápidas — muitas vezes mais rápidas que APIs na nuvem porque você eliminou as viagens de ida e volta da rede por completo.

Resolvi o problema de inicialização fria adicionando um cron job simples que envia uma solicitação fictícia ao Ollama toda manhã às 8h:

# Add to crontab: keep model warm
0 8 * * * curl -s http://localhost:11434/api/generate \
  -d '{"model":"qwen3-coder","prompt":"ping","stream":false}' \
  > /dev/null 2>&1

Um pequeno truque, uma grande melhoria na qualidade de vida.

Nem toda tarefa pertence a um modelo local

Vou ser honesto sobre isso: para fluxos de trabalho agênticos complexos de múltiplos passos que exigem raciocínio forte sobre contextos muito longos — pense em "analise toda esta base de código e gere um plano de migração" — os modelos na nuvem como o Claude ainda levam vantagem. A diferença está diminuindo a cada mês conforme os modelos de código aberto melhoram, mas ela existe hoje.

Minha abordagem é pragmática. Uso modelos locais do Ollama pelo OpenClaw para 80% das minhas tarefas diárias — as coisas rotineiras que acontecem dezenas de vezes por dia. Para os 20% restantes que demandam raciocínio de nível fronteira, mantenho um provedor na nuvem configurado como fallback. O OpenClaw suporta múltiplos provedores simultaneamente, então a troca é fluida.

A economia ao mover 80% das consultas para inferência local tem sido significativa. Minha conta mensal de API na nuvem caiu de cerca de $45/mês para menos de $10.

Além do chat: as tarefas que me surpreenderam

Eu esperava que o OpenClaw + Ollama lidasse bem com chat. O que não esperava era o quão capaz seria em tarefas que eu nunca tinha me dado ao trabalho de tentar com um modelo local antes.

Triagem de e-mail pelo WhatsApp

Toda manhã, envio uma mensagem para meu bot do OpenClaw:

Me: Morning brief — check email, flag anything urgent,
    summarize the rest

Dois minutos depois (a varredura de e-mails leva um momento), recebo um resumo priorizado. Itens urgentes no topo com ações recomendadas. Não urgentes agrupados por categoria. Spam de newsletters identificado e pronto para arquivar. Tudo processado pelo qwen3-coder na minha mesa.

O fato de isso acontecer pelo WhatsApp — o mesmo app que já estou verificando — significa que realmente uso todos os dias. Quando exigia abrir um terminal separado e rodar um script Python, eu pulava metade das vezes.

Solicitações de revisão de código via Telegram

Conectei o OpenClaw ao grupo do Telegram que uso para colaboração em projetos pessoais. Agora posso colar um trecho de código ou um link de PR e obter feedback instantâneo:

Me: Review this function — anything wrong?

[pastes function]

OpenClaw 🦞: Two issues:

1. Line 12: You're not awaiting the async call inside
   the loop. This will fire all requests simultaneously
   instead of sequentially. If the API has rate limits,
   you'll hit them.

2. Line 23: The error catch swallows the exception
   silently. At minimum, log it. Better: propagate it
   with context about which iteration failed.

Want me to rewrite it with both fixes?

Essa revisão veio de um modelo local. Nenhum código saiu da minha máquina. Para alguém trabalhando em projetos de clientes com NDAs, o aspecto de privacidade não é um luxo — é um requisito.

Gerenciamento e organização de arquivos

Essa me pegou de surpresa. Pedi ao OpenClaw para ajudar a organizar uma pasta de downloads bagunçada:

Me: Organize my ~/Downloads folder — group files by type,
    move anything older than 30 days to archive, and list
    what you did

OpenClaw 🦞: Done. Here's what I moved:

📁 Documents (14 files) → ~/Downloads/docs/
📁 Images (43 files) → ~/Downloads/images/
📁 Code (8 files) → ~/Downloads/code/
📁 Archives (6 files) → ~/Downloads/archives/
📁 Misc (3 files) → ~/Downloads/other/

Archived (>30 days): 23 files → ~/Archive/2026-02/

Total: 97 files organized. 23 archived.

Rodar isso através de uma API na nuvem significaria enviar minha listagem de arquivos para o servidor de outra pessoa. Com o Ollama local, o diretório nunca sai da minha máquina.

Como o OpenClaw + Ollama se compara com configurações apenas na nuvem?

Rodei ambas as configurações lado a lado por cinco dias. Aqui está o que encontrei — sem benchmarks fabricados, apenas minha experiência honesta no uso real diário.

Velocidade de resposta para tarefas simples: O Ollama local foi consistentemente mais rápido. Sem latência de rede significa respostas em menos de um segundo para consultas rápidas. Provedores na nuvem tipicamente adicionavam 1-3 segundos de overhead mesmo para respostas simples.

Qualidade de resposta para raciocínio complexo: Modelos na nuvem (particularmente o Claude) ainda lidaram com raciocínio de múltiplos passos de forma mais confiável. Quando pedi ao OpenClaw para planejar um fluxo de trabalho de deploy complexo envolvendo oito passos sequenciais com ramificação condicional, o modelo na nuvem acertou em cheio. O modelo local acertou cerca de 80% e precisou de uma correção.

Custo em cinco dias: A configuração apenas na nuvem me custou aproximadamente $8 em chamadas de API. A configuração com Ollama custou $0. Minha conta de eletricidade não mudou notavelmente — a GPU já estava rodando para outras tarefas.

Privacidade: Sem competição. O local ganha absolutamente. Cada consulta, cada referência de arquivo, cada trecho de e-mail permaneceu no meu hardware.

Confiabilidade: A nuvem depende de conectividade com a internet e do uptime do provedor. Durante uma breve queda de internet no terceiro dia, minha configuração local do OpenClaw continuou funcionando sem perder o ritmo. A configuração na nuvem estava completamente morta.

A abordagem híbrida — Ollama para tarefas diárias, nuvem para raciocínio complexo — me deu o melhor dos dois mundos. E o OpenClaw torna a troca trivialmente fácil.

Configurando a abordagem híbrida: local + fallback na nuvem

Se o modelo híbrido parece atraente, aqui está como configurei:

# Primary: Ollama (local, free, private)
openclaw onboard --auth-choice ollama

# Secondary: Cloud provider as fallback
openclaw provider add --name claude --type anthropic \
  --api-key $ANTHROPIC_API_KEY

# Set routing rules
openclaw config set routing.default ollama
openclaw config set routing.complex claude

Com essa configuração, o OpenClaw roteia a maioria das solicitações para o Ollama por padrão. Quando peço explicitamente o modelo na nuvem (usando /model claude no chat) ou quando uma tarefa ultrapassa um limiar de complexidade, ele roteia para o provedor na nuvem.

A configuração me dá uma conta mensal de IA abaixo de $10 enquanto ainda tenho acesso a modelos de fronteira quando realmente preciso deles. Antes disso, eu gastava $40-50/mês. Ao longo de um ano, são quase $500 economizados — e minha experiência diária com o assistente é na verdade melhor porque a inferência local é mais rápida para tarefas rotineiras.

O que isso significa para o futuro da IA pessoal

Quero dar um passo atrás por um momento porque essa integração com o Ollama representa algo maior do que o anúncio de uma única funcionalidade.

Quando o OpenClaw foi lançado, a suposição era que assistentes pessoais de IA precisavam de LLMs na nuvem. O cenário de modelos locais no final de 2025 simplesmente não era bom o suficiente para trabalho agêntico confiável. Os modelos não conseguiam manter contexto suficiente. Não eram rápidos o bastante. Cometiam erros demais em tarefas de múltiplos passos.

Isso mudou rapidamente. No início de 2026, modelos como qwen3-coder e glm-4.7 se tornaram capazes o suficiente para lidar com cargas de trabalho reais de assistente. O Ollama tornou rodá-los localmente extremamente simples. E agora o OpenClaw fez com que conectá-los ao seu fluxo de trabalho diário seja um único comando.

A trajetória é clara: a IA pessoal está indo para o local primeiro. A nuvem se torna a exceção para tarefas de nível fronteira, não o padrão para tudo. E a stack OpenClaw + Ollama é a forma mais acessível de fazer essa transição agora mesmo.

O @steipete tomou uma decisão cedo de manter o OpenClaw agnóstico em relação ao modelo. Sem lock-in a um provedor. Sem tratamento preferencial para nuvem sobre local. Essa decisão arquitetural está rendendo dividendos agora. Quando o Ollama se tornou viável como um provedor sério, a integração foi limpa porque a camada de abstração já estava lá. Boas decisões de engenharia se acumulam com o tempo — e este é um exemplo de livro.

O desafio de uma hora: experimente hoje

Não quero que este seja mais um artigo que você lê, concorda com a cabeça e depois esquece. Então aqui está um desafio concreto.

Coloque um timer de uma hora. Nessa hora:

1. Instale o Ollama se ainda não o fez (5 minutos)
2. Baixe o qwen3-coder — ollama pull qwen3-coder (depende da sua velocidade de internet, mas o download roda em segundo plano)
3. Instale o OpenClaw do repositório no GitHub (10 minutos incluindo a compilação)
4. Execute o comando de configuração — openclaw onboard --auth-choice ollama (2 minutos)
5. Conecte um app de mensagens — o que você mais usa (5 minutos)
6. Dê três tarefas reais — não "olá," não exemplos de brinquedo. Peça para fazer algo que você normalmente abriria um navegador ou terminal para resolver.

Se sua experiência for parecida com a minha, você vai ficar viciado na segunda tarefa. Há algo genuinamente encantador em enviar uma mensagem no WhatsApp e receber de volta uma resposta útil alimentada inteiramente por hardware que você possui.

A lagosta chegou à sua máquina local. E está pronta para trabalhar.

Perguntas frequentes

O OpenClaw funciona com todos os modelos do Ollama?

Sim — cada modelo disponível na sua instalação local do Ollama funciona com o OpenClaw depois de executar openclaw onboard --auth-choice ollama. O assistente de configuração detecta todos os modelos baixados automaticamente. Para tarefas agênticas confiáveis de múltiplos passos, escolha modelos com janelas de contexto de pelo menos 64K. Para a lista completa de modelos recomendados, consulte a seção de configuração acima.

Quanta VRAM preciso para rodar o OpenClaw com Ollama?

Planeje um mínimo de 8-16GB de VRAM. Modelos como o qwen3-coder rodam confortavelmente com 16GB de VRAM na quantização padrão. Modelos menores como o glm-4.7-flash funcionam com 8GB. Você pode descarregar para CPU, mas os tempos de resposta aumentam significativamente — de 3 segundos para mais de 30 segundos para modelos maiores.

Posso usar o OpenClaw com Ollama e um provedor na nuvem?

Com certeza. O OpenClaw suporta múltiplos provedores simultaneamente. Configure o Ollama como seu padrão para tarefas diárias e adicione um provedor na nuvem (Claude, GPT, DeepSeek) como fallback para raciocínio complexo. Consulte o tutorial de configuração híbrida acima para os comandos exatos.

Meus dados são privados ao usar o OpenClaw com Ollama?

Completamente. Com o Ollama como seu provedor, toda a inferência roda na sua máquina local. Nenhuma consulta, conteúdo de arquivos ou dados de conversa saem do seu hardware. Isso torna a configuração ideal para desenvolvedores que trabalham sob NDAs ou lidam com dados sensíveis de clientes.

Quais apps de mensagens o OpenClaw suporta?

O OpenClaw se conecta ao WhatsApp, Telegram, Discord, Signal, Slack e iMessage. Cada app tem seu próprio comando de conexão — openclaw connect [app] — e a configuração tipicamente leva menos de cinco minutos por plataforma.

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