DeepSeek em toda parte: Claude Code e uma pilha de agentes locais

O DeepSeek sustentou três componentes diferentes na minha casa em julho de 2026: o “cérebro” da minha pilha de agentes, a interface de linha de comando Claude Code, e o nível de nuvem de um sistema de redundância. O esforço total para a configuração consistiu em algum JSON, algumas variáveis de ambiente e um bug relacionado ao systemd que me tomou uma noite inteira para resolver.

Atualização em 16/09/2026: minha pilha de agentes foi posteriormente reduzida para seis agentes; desde o final de agosto de 2026, o agente principal opera no MiniMax M3, com o DeepSeek atuando como alternativa sob demanda. A lista de oito agentes abaixo descreve a configuração existente na época da redação deste texto. A configuração de conexão permanece inalterada, sendo assim que o DeepSeek continua sendo integrado ao sistema.

O resultado final

Antes de entrarmos nos detalhes práticos, vejam como ficou o sistema que montei em julho. Executei o OpenClaw, um gateway de agentes, com oito agentes nomeados por trás de uma interface de chat; além disso, usei também o CLI do Claude Code para as tarefas de programação propriamente ditas. O DeepSeek serviu de suporte para ambos.

Padrão	O que faz	Custo
1. “Cérebro” do agente	O DeepSeek atua como provedor no arquivo de configuração do gateway; qualquer agente pode escolhê-lo como opção principal ou de reserva	$0,14–$0,87 por milhão de tokens
2. Backend do Claude Code	O systemd redireciona automaticamente o CLI para o endpoint compatível com Anthropic do DeepSeek; não é necessária nenhuma reinstalação	mesmo preço por token
3. Sequência de fallback	Uma lista de critérios que determina quando uma tarefa deve ser enviada ao DeepSeek ou a um modelo local	$0, caso seja processada localmente

O único elemento que torna tudo isso possível: o DeepSeek disponibiliza um endpoint compatível com Anthropic em https://api.deepseek.com/anthropic. Qualquer sistema criado para interagir com o Claude — incluindo o CLI do Claude Code — pode ser configurado para usá-lo apenas por meio de variáveis de ambiente. Não é preciso nenhum script intermediário, nem modificações adicionais.

Padrão 1: DeepSeek como “cérebro” de agentes

Um único bloco de provedor na configuração do gateway. Versão real; chaves foram redigidas:

"deepseek": {
  "baseUrl": "https://api.deepseek.com/v1",
  "api": "openai-completions",
  "apiKey": "CHANGE_ME",
  "timeoutSeconds": 450,
  "models": [
    {
      "id": "deepseek-v4-pro",
      "name": "deepseek-v4-pro",
      "reasoning": true,
      "input": ["text"],
      "cost": { "input": 0.435, "output": 0.87,
                "cacheRead": 0.003625, "cacheWrite": 0.435 },
      "contextWindow": 1000000,
      "maxTokens": 384000
    },
    {
      "id": "deepseek-v4-flash",
      "name": "deepseek-v4-flash",
      "reasoning": true,
      "input": ["text"],
      "cost": { "input": 0.14, "output": 0.28,
                "cacheRead": 0.0028, "cacheWrite": 0.14 },
      "contextWindow": 1000000,
      "maxTokens": 384000
    }
  ]
}

Cada agente, então, escolhe um modelo principal e uma cadeia de modelos de fallback:

"model": {
  "primary": "deepseek/deepseek-v4-flash",
  "fallbacks": ["deepseek/deepseek-v4-pro", "vllm/google/gemma-4-31b"]
}

Veja o que acontece quando uma mensagem chega por esse roteamento:

Minha lista de agentes em agosto de 2026, por função. A maioria dos agentes usava o DeepSeek como modelo principal e recorria a modelos locais como fallback; o modelo local, por sua vez, agia de forma inversa:

Agente	Modelo principal	Modelos de fallback
Agente de chat principal	DeepSeek flash	DeepSeek pro → modelo local gemma-4-31b
Agente de raciocínio	DeepSeek pro	modelo local gemma-4-31b
Trabalhador rápido	DeepSeek flash	DeepSeek pro → modelo local
Agente de implantação	DeepSeek pro	DeepSeek flash → modelo local
Agente seguro para uso familiar	DeepSeek flash	DeepSeek pro → modelo local
Trabalhador local	modelo local 120B	DeepSeek flash (inversamente: o modelo local é priorizado)
Segundo agente seguro para uso familiar	modelo local	DeepSeek flash → DeepSeek pro
Agente de visão	modelo local gemma-31b	DeepSeek pro → DeepSeek flash

O agente de visão é importante aqui: as configurações do DeepSeek são apenas para texto ("input": ["text"]), portanto todo o processamento de imagens permanece local, independentemente da cadeia de modelos escolhida. Os aliases (ds-flash, ds-brain) permitem que eu troque os modelos durante uma conversa, sem precisar editar a configuração.

Duas configurações podem causar problemas se forem ignoradas:

• "reasoning": true é obrigatório para modelos de raciocínio. Eles transmitem o reasoning_content antes da resposta final; sem essa opção ativada, o gateway interpreta isso como silêncio, presume que o modelo travou e encerra a conversa após cerca de 390 segundos. Perguntem-me como eu sei disso.
• Aumente o valor de timeoutSeconds. O timeout padrão para requisições era de 120 segundos; execuções longas de raciocínio ultrapassavam esse limite e “falhavam” aleatoriamente. Aqui, definir o valor como 450 resolveu o problema; as configurações dos provedores são recarregadas dinamicamente — não é preciso reiniciar o gateway.

Padrão 2: Claude Code CLI no DeepSeek

O Claude Code CLI lê as variáveis ANTHROPIC_BASE_URL, ANTHROPIC_MODEL e ANTHROPIC_AUTH_TOKEN/ANTHROPIC_API_KEY a partir do seu ambiente; o endpoint /anthropic do DeepSeek utiliza o mesmo formato de comunicação que o Claude. Portanto, para redirecionar o CLI, basta alterar o ambiente que o gateway fornece a cada subprocesso do Claude Code — o próprio CLI permanece como uma instalação padrão.

O arquivo em questão é um “drop-in” do systemd. Em julho, o meu foi gerado por um pequeno aplicativo GTK que eu desenvolvi, capaz de alternar entre quatro modos (Local com LM Studio / DeepSeek / Cloud da Anthropic / Desativado); porém, o arquivo é curto o suficiente para ser escrito manualmente:

# ~/.config/systemd/user/openclaw-gateway.service.d/60-subagent-routing.conf
[Service]
# Routes Claude Code CLI sub-processes to DeepSeek's Anthropic-compatible
# endpoint. The key is NOT copied here: $$DEEPSEEK_API_KEY is systemd's escape
# for a literal $DEEPSEEK_API_KEY, which bash expands at runtime from the
# gateway EnvironmentFile -- the secret never enters the unit or the argv.
Environment="ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic"
Environment="ANTHROPIC_MODEL=deepseek-v4-pro"
ExecStart=
ExecStart=/usr/bin/bash -c 'export ANTHROPIC_AUTH_TOKEN="$$DEEPSEEK_API_KEY"; export ANTHROPIC_API_KEY="$$DEEPSEEK_API_KEY"; exec node /path/to/openclaw/dist/index.js gateway --port 18789'

A chave de autenticação fica armazenada em um único local: no arquivo EnvironmentFile do serviço (um arquivo de ambiente controlado pelo gateway, com permissões chmod 600), que contém apenas a linha DEEPSEEK_API_KEY=CHANGE_ME.

O “truque” com $$ (o motivo real deste post)

Na minha primeira tentativa, usei um único $. Não deu certo. Dentro de um arquivo de unidade do systemd, o valor de $VAR é expandido pelo próprio systemd no momento da execução; isso faz com que a chave seja inserida diretamente na linha de comando — ficando visível em ps, em /proc/<pid>/cmdline e em systemctl show. Definitivamente não é o lugar ideal para guardar um segredo.

O uso de $$VAR é uma forma de “escapar” o valor de $VAR: o systemd passa essa string sem alterações, e o bash a expande posteriormente, a partir do ambiente já preenchido pelo EnvironmentFile. Resultado final: a chave fica armazenada apenas num arquivo com permissões chmod 600; ela nunca aparece no arquivo de unidade, em systemctl show ou nos argumentos do comando. É, na prática, um “gerenciador de segredos” rudimentar baseado no systemd e no bash — e funciona perfeitamente.

Outros cuidados ao implementar isso na prática:

• Defina ambas as variáveis de autenticação. Versões diferentes do CLI lêem ANTHROPIC_AUTH_TOKEN ou ANTHROPIC_API_KEY; definir apenas uma é um “jogo de azar”.
• Defina também ANTHROPIC_MODEL, caso contrário os aliases padrão do CLI (sonnet/opus) são enviados ao endpoint do DeepSeek, resultando em erro 404.
• O “drop-in” sobrescreve qualquer chave da Anthropic real. Um único ambiente controla todo o funcionamento do CLI; percebi isso quando meus aliases para redirecionar as requisições ao Claude real pararam de funcionar sem aviso.
• Inclua uma linha vazia antes de ExecStart=; senão o systemd simplesmente adiciona seu comando ao original, em vez de substituí-lo.
• Atualizações de pacotes podem “desativar” esse wrapper. Como ele codifica o comando de execução, uma atualização que altere o ExecStart original exige a regeração do arquivo “drop-in”. Meu gerador lê o comando padrão a partir do FragmentPath da unidade e se recusa a modificar qualquer coisa que já contenha $$DEEPSEEK_API_KEY.
• Por fim, recarregue o systemd: systemctl --user daemon-reload && systemctl --user restart <service>.

Para testar todo esse fluxo de ponta a ponta, basta pular o CLI e usar o curl diretamente:

curl https://api.deepseek.com/anthropic/v1/messages \
  -H "x-api-key: $DEEPSEEK_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"deepseek-v4-pro","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}'

Se o retorno for um objeto "type":"message", significa que todo o caminho compatível com a Anthropic está funcionando perfeitamente.

Padrão 3: quando usar efetivamente o DeepSeek em vez do modelo local

Ter ambos os modelos não significa que todas as tarefas sejam enviadas para a nuvem. Por milhão de tokens, considerando os preços listados da Claude para diferentes escalas (Opus: $5/$25; Sonnet: $3/$15; Haiku: $1/$5):

Opção	Entrada	Saída	Observações
DeepSeek flash	$0,14	$0,28	Custo de leitura do cache: $0,0028; o uso em agentes de chat custa apenas alguns centavos por dia
DeepSeek pro	$0,435	$0,87	A versão “avançada” do modelo; ainda assim é 7 a 17 vezes mais barata que o Sonnet
Local (no mesmo computador)	$0	$0	Apenas custos com eletricidade

A velocidade foi a maior surpresa. Os modelos locais de 100 bilhões de parâmetros me forçaram a aumentar os limites de tempo de resposta para 20–30 minutos; além disso, dois agentes compartilhando uma única GPU acabavam travando um ao outro. O DeepSeek responde em segundos; o limite máximo de 450 segundos só se torna relevante nos casos mais complexos de raciocínio. Outra diferença importante é o tamanho do contexto: o DeepSeek suporta até 1 milhão de tokens, enquanto os modelos locais permitem apenas cerca de 128 mil tokens. Por isso, sessões longas com agentes ou tarefas que envolvem grandes bases de código são melhor resolvidas pelo DeepSeek. Já no caso de processamento de imagens, o cenário é inverso: minhas integrações com o DeepSeek trabalham apenas com texto; portanto, tarefas como “analise esta imagem” devem ser feitas por um modelo local especializado em visão computacional.

O critério prático que eu uso para questões de privacidade é: não envie à nuvem nada que você não enviaria por e-mail.

As cadeias de fallback funcionam nos dois sentidos, e essa é a parte que mais gosto. Os agentes que usam principalmente a nuvem recorrem ao modelo local quando a internet ou a API falham; já os sistemas que dependem do modelo local caem no DeepSeek flash quando o servidor local está sobrecarregado ou indisponível. Assim, ninguém fica completamente sem resposta.

Armadilhas comuns – lista resumida

O sinalizador reasoning: true, o limite de tempo de 120 segundos, o caractere de escape $$ e o mecanismo de substituição que mascara sua chave real da Anthropic são todos abordados nos Padrões 1 e 2. Mais dois pontos importantes:

• Uma lista de permissões de plugins não vazia é rigorosa. No OpenClaw, um provedor habilitado que não consta na lista plugins.allow simplesmente não é carregado. Sem erros, sem avisos — apenas silêncio.
• O DeepSeek aqui funciona apenas com texto. Verifique o campo "input" na configuração do modelo antes de enviar tarefas que envolvam processamento visual para ele.

Quer rodar tudo localmente — sem chave de API, sem custos na nuvem? Também escrevi sobre isso: DeepSeek: Executando Localmente — um Guia em 4 Passos. O DeepSeek pode ser executado na sua própria GPU usando Ollama, Docker e Open WebUI. Esse é o caminho para iniciantes; este guia, por sua vez, destina-se a situações em que as tarefas pesadas ultrapassam a capacidade da GPU, mas os dados confidenciais precisam permanecer no seu ambiente local.

Relacionado: a pilha de agentes de IA local na qual essa configuração opera, OpenClaw Model Manager (a interface gráfica que gera o mecanismo de substituição do Claude Code), execução totalmente local do DeepSeek e como configurar um assistente de IA baseado em LLM.