Reasonix: um Agente de Codificação no Estilo Claude Code Rodando no DeepSeek

Se você gosta do jeito de trabalhar do Claude Code — um agente de codificação morando no seu terminal, lendo arquivos, rodando comandos, corrigindo os próprios erros — mas prefere pagar frações de centavo por tarefa a uma assinatura mensal, esta é a receita: o Reasonix, uma CLI agente no estilo Claude Code, apontada para a API do DeepSeek.

O que você ganha

Você abre um terminal num projeto, digita reasonix e descreve o que quer: "adicione uma flag --dry-run a este script e atualize o README." O agente lê os arquivos relevantes, edita-os, roda o script para conferir o próprio trabalho e reporta de volta — o mesmo ciclo que os usuários do Claude Code já conhecem. As diferenças estão na encanação:

• O cérebro é o DeepSeek, cobrado por token. Dois níveis cobrem tudo: um modelo flash para edições do dia a dia e trabalho de cola, e um modelo de raciocínio pro para refatorações complicadas e depuração. Minha stack de agentes sempre ativos roda nesses mesmos dois níveis e custou $24,08 num mês inteiro ($9,54 de flash + $14,54 de pro) — a mesma carga de trabalho sairia por algo entre $475 e $915 nas APIs de ponta.
• É seu para agendar. Como não há licença por assento, você pode deixá-lo moendo trabalho braçal longo — refatorações em lote, escrita de testes, passadas de documentação — sem ficar de olho num medidor de uso.
• O estado vive no seu diretório home. O Reasonix mantém uma pasta oculta (~/.reasonix/) com seu arquivo de configuração mais o histórico de sessão e a memória por projeto, então ele lembra o contexto de cada repositório entre execuções.

Passo 1: instalar

É um pacote global do npm:

npm install -g reasonix
reasonix --version

É essa a instalação inteira. Se você mantém o Node num prefixo fora do padrão, anote o caminho completo do npm — você vai precisar dele de novo no atualizador do passo 4.

Passo 2: apontar para o DeepSeek

Crie uma chave de API no site da plataforma do DeepSeek (pagamento por uso; os primeiros onze dias de julho de toda a minha stack de agentes deram $2,23). Depois descreva o provedor em ~/.reasonix/config.toml:

# ~/.reasonix/config.toml — the shape, not a paste of mine
default_model = "deepseek-flash"

[[providers]]
name        = "deepseek"
base_url    = "https://api.deepseek.com"
models      = ["deepseek-v4-flash", "deepseek-v4-pro"]
api_key_env = "DEEPSEEK_API_KEY"    # NAME of the variable, not the key itself

Os nomes dos campos variam entre CLIs de agente, mas todas se resumem ao mesmo trio: URL base, credencial, id(s) de modelo. Duas regras de higiene, independente da ferramenta:

• chmod 600 em qualquer coisa que contenha a chave, e nunca a passe numa linha de comando — ela acaba no histórico do shell e na saída do ps. A indireção do api_key_env existe justamente para que o segredo e a configuração possam ser tratados de forma diferente: a configuração é um arquivo que você poderia colar num chat para pedir ajuda, o .env não.
• Configure os dois níveis. Flash-por-padrão, pro-para-o-difícil é toda a história do custo: a maioria dos turnos sai barata, e você só escala quando o modelo está visivelmente patinando.

Passo 3: subagentes e skills

Subagentes são workers com escopo limitado que o agente principal gera — "procure no código-base cada chamador desta função" — e, no faturamento por token, também são a alavanca de custo, já que os workers podem rodar no nível flash enquanto o orquestrador pensa no pro. Skills são arquivos de instrução que o agente carrega sob demanda, então um procedimento de deploy ou uma convenção de escrita de teste fica registrado uma vez, em vez de reexplicado a cada sessão.

As versões atuais permitem definir esse roteamento explicitamente, em vez de confiar que os padrões sejam sensatos, e este é o bloco de configuração que vale a pena entender, porque é ele que determina a conta:

[agent]
# planner_model  = "deepseek-pro"    # two-model collaboration: pro plans, flash executes
# subagent_model = "deepseek-pro"    # default tier for spawned workers
# subagent_models = { review = "deepseek-pro", security_review = "deepseek-pro" }
# recovery_model = "deepseek-pro"    # steps in when a turn fails

O mapa por skill na terceira linha é o mais útil. A maior parte do trabalho delegado — dar um grep aqui, renomear ali, escrever o teste óbvio — é trabalho de nível flash. Uma revisão de código ou uma checagem de segurança não é; são exatamente as tarefas em que um modelo barato produz uma saída confiante, plausível e errada. Nomear as poucas skills que merecem o nível caro te dá bom julgamento onde importa e deixa tudo o resto barato, o que é uma troca melhor do que escolher um único nível para todos os subagentes.

Passo 4: manter atualizado com um agendamento

As CLIs de agente evoluem rápido, e uma versão desatualizada perde correções de ferramentas. Agora existe um comando embutido para isso, que é a resposta certa em primeiro lugar:

reasonix upgrade

com o canal escolhido na configuração:

[cli]
update_channel = "stable"   # stable | preview

Se você preferir que isso aconteça sem você, agende. A minha roda sem supervisão e a CLI está atualmente na v1.18.0 sem eu ter precisado pensar nisso. O script abaixo encapsula o npm diretamente, e vale a pena conhecê-lo mesmo se você usar o comando embutido, porque um npm update -g ingênuo num agendamento tem dois modos de falha que vale a pena vigiar:

#!/usr/bin/env bash
set -euo pipefail
LOG="$HOME/logs/update-reasonix.log"
NPM="$(command -v npm)"

# 1. Lock guard — two overlapping npm runs corrupt the install
exec 9>"${LOG%.log}.lock"
flock -n 9 || { echo "update already running"; exit 0; }

# 2. Log rotation — cron logs grow forever unless you trim them
[ -f "$LOG" ] && tail -n 5000 "$LOG" > "$LOG.tmp" && mv "$LOG.tmp" "$LOG"

echo "before: $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"
"$NPM" update -g reasonix >> "$LOG" 2>&1
echo "after:  $("$NPM" list -g reasonix --depth=0 | grep reasonix)" >> "$LOG"

Conecte a um cron ou a um timer do systemd — os dois funcionam. Registrar a versão antes e depois importa mais do que parece: quando o comportamento do agente muda da noite para o dia, o log te diz se foi uma atualização que fez isso.

Usando isso num projeto de verdade

Tudo acima é configuração global. O que torna uma CLI de agente realmente útil é a camada por projeto, e o Reasonix resolve a configuração numa ordem específica que vale a pena conhecer:

flag  >  ./reasonix.toml  >  ~/.reasonix/config.toml  >  built-in defaults

Então um reasonix.toml commitado na raiz de um repositório se torna as instruções permanentes daquele projeto, enquanto seu arquivo global guarda a credencial e suas preferências pessoais. Alguns campos são deliberadamente só-globais — o canal de atualização, preferências da CLI — para que um repositório que você clonou não possa mudar silenciosamente como a sua instalação se atualiza. Esse é um limite sensato, e é o motivo pelo qual é seguro aceitar um arquivo por projeto vindo de outra pessoa.

O estado de sessão e a memória também são delimitados por projeto, em ~/.reasonix/projects/<project>/sessions/. Inicie-o a partir de um diretório de projeto em vez da sua pasta pessoal e você ganha continuidade por repositório — ele lembra o que aprendeu sobre aquele código-base da última vez, em vez de começar do zero. Iniciar a partir de $HOME funciona, mas você ganha uma única pilha indiferenciada de contexto, o que vale a pena evitar se você trabalha em vários repositórios.

O que eu colocaria num arquivo de projeto, em ordem aproximada de retorno:

• Os comandos de build e teste. A linha de maior valor, isoladamente. Um agente que sabe verificar o próprio trabalho para de adivinhar.
• O mapa de escalonamento — o bloco subagent_models mostrado acima, ajustado por repositório. Um projeto com superfície de segurança quer um padrão diferente do de um site estático.
• As coisas que ele não deve fazer. Portões de deploy, arquivos que ele nunca pode tocar, "nunca rode isso contra produção." Escreva uma vez.
• Skills para qualquer coisa procedural — o runbook de deploy, o checklist de release — para que o procedimento fique registrado no repositório em vez de na sua memória.

Para exemplos práticos do tipo de projeto que combina com isso, o app de chat autogerenciado, a interface de backup e a reconstrução de WordPress para estático têm todos o mesmo formato: um código-base definido, um comando de verificação de verdade, e um portão antes de qualquer coisa ir ao ar.

Bônus: coloque no seu app de chat

Um agente de terminal não precisa ficar preso a um terminal. Como o Reasonix é só uma CLI sobre um PTY, dá para transmiti-lo para uma interface web com xterm.js e usá-lo de qualquer dispositivo na sua rede. Meu aplicativo de chat autogerenciado faz exatamente isso — o Reasonix aparece como um "bot de terminal" ao lado dos agentes de chat normais, com controles de iniciar/reiniciar/parar. A configuração completa está descrita em DisPatch: um chat de IA autogerenciado.

Pegadinhas

• Modelos de raciocínio parecem travados antes de responder. O nível pro transmite o próprio pensamento antes da resposta; se um wrapper ou gateway em volta do agente tem um timeout de inatividade curto, pensamentos longos são derrubados no meio. Aumente o timeout, não culpe o modelo.
• Nunca coloque a chave no argv. Só arquivo de configuração (chmod 600) ou arquivo de ambiente. Flags de linha de comando vazam pelo histórico e por listagens de processo.
• Fixe o caminho do npm no atualizador. O cron roda com um PATH mínimo; o npm num shell interativo e no cron pode resolver para caminhos diferentes. Fixe o caminho ou resolva-o explicitamente no script.
• Trave sua tarefa de atualização. Sem flock, um registro npm lento somado a um agendamento entusiasmado eventualmente te dá duas instalações globais concorrentes e uma CLI quebrada.
• Fique de olho no hábito de escalar. Pagar por token só continua barato se o flash for o padrão. Se toda tarefa roda no pro "só por garantia", você reinventou a assinatura — acompanhe o gasto na primeira semana.
• Pastas de sessão crescem. Histórico por projeto é ótimo até um agente tagarela acumular meses dele; limpe os dados de sessão da pasta oculta de vez em quando.
• Os esquemas de configuração mudam debaixo dos seus pés. Esta ferramenta carrega um marcador config_version justamente porque o formato muda entre versões — a credencial saindo do config.toml e indo para trás do api_key_env é uma dessas mudanças. Se o agente de repente não conseguir mais autenticar depois de uma atualização, confira o formato da configuração contra a documentação atual antes de regenerar sua chave.
• Retomar uma sessão antiga não é de graça. Reabrir uma conversa depois que a janela de cache de prompt do provedor expirou significa que o contexto é reenviado a preço cheio. Existe uma opção para podar saídas de ferramentas obsoletas ao retomar uma sessão fria; deixe-a ativada. Uma sessão nova costuma sair mais barato do que ressuscitar uma velha.

Leitura relacionada: o guia mais amplo DeepSeek em todo lugar cobre como apontar a própria CLI do Claude Code para o endpoint compatível com Anthropic do DeepSeek — a mesma ideia, na direção oposta.