Verificando acesso...

Início / Trilha 2 / Módulo 2.3
MÓDULO 2.3

🤖 Integrando DeepSeek V4 como Worker do Triad

Chave própria, BYOK no OpenRouter e rate limits independentes para loops overnight sem interrupção.

7
Tópicos
~45
Minutos
Intermediário
Nível
Prática
Tipo
1

💡 Por que ter chave própria DeepSeek no OpenRouter

Quando você usa DeepSeek pelo pool padrão do OpenRouter, está dividindo um rate limit compartilhado com milhares de outros usuários. Com BYOK (Bring Your Own Key), seu rate limit é dedicado — e loops overnight do Triad rodam sem 429 no meio da madrugada.

O que é

BYOK no OpenRouter é o mecanismo que permite registrar sua própria API key de um provedor (DeepSeek, Anthropic, OpenAI etc.) e fazer com que o OpenRouter encaminhe chamadas usando seus créditos e seus rate limits, em vez do pool compartilhado da plataforma.

✗ Rate limit compartilhado (pool OR)

  • 429 Too Many Requests sem aviso
  • Loops overnight quebram no meio
  • Latência variável por congestionamento
  • Margem do OR somada ao custo final

✓ Rate limit dedicado (BYOK)

  • Limites isolados na sua conta DeepSeek
  • Loop overnight conclui sem interrupção
  • Custo direto ao provedor (sem margem)
  • Logs e billing centralizados no DeepSeek

🔗 Por que isolamento importa no Triad

O Worker é o papel com maior volume de chamadas — explora 3–5 ângulos em paralelo por iteração
O loop Worker-Crítico pode iterar 3–8x por tarefa — multiplicação direta de requests
Em modo overnight, isso vira centenas de calls por hora — pool compartilhado não aguenta

🔑 Conceitos-chave

BYOK = isolamento de rate limit

Sua chave, seu pool, seu limite — independente de outros usuários do OpenRouter

Worker = papel de maior volume

É onde o custo de rate limit dói mais — 3–5 ângulos × N iterações

Sem margem OR no BYOK

Você paga preço direto do provedor — OpenRouter só roteia

Overnight exige limites dedicados

Loops longos sem supervisão não toleram 429 silencioso no pool

2

💳 Criando conta + carregando créditos na DeepSeek Platform

DeepSeek é um dos provedores com melhor custo-benefício do mercado para Worker. $5–$10 em créditos rendem semanas de uso intenso no Triad — desde que você configure BYOK corretamente para não pagar margem dupla.

O que é

A DeepSeek Platform é o portal oficial do provedor onde você cria conta, carrega créditos pré-pagos e gera API keys. É a fonte da chave que você vai registrar no OpenRouter como BYOK.

🧭 Passo a passo

  1. Acessar platform.deepseek.com e criar conta (email + senha ou OAuth)
  2. Verificar email — sem verificação, billing fica bloqueado
  3. Em Billing → Top up, carregar $5 ou $10 em créditos
  4. Confirmar via cartão ou método regional disponível
  5. Aguardar saldo refletir na dashboard (geralmente instantâneo)

💡 Estimativa de custo realista

DeepSeek V4 cobra valores baixíssimos por milhão de tokens. Como referência prática:

  • 1 iteração Worker (3 ângulos, ~8k tokens cada) ≈ poucos centavos
  • $5 cobrem dezenas a centenas de tarefas completas, dependendo do tamanho
  • Confira preços atuais em platform.deepseek.com/api-docs/pricing — mudam

🔑 Conceitos-chave

Conta pré-paga

DeepSeek opera em modelo pré-pago — sem cartão amarrado, sem surpresa de fatura

$5–$10 = semanas de uso

Custo unitário baixo do Worker permite cargas pequenas e longas

Verificação de email obrigatória

Sem verificar, billing fica travado e a chave não autoriza

Saldo ≠ rate limit

Ter crédito não significa requests ilimitados — DeepSeek aplica RPM/TPM por conta

3

🔑 Gerando API key DeepSeek

A API key é o que conecta sua conta DeepSeek ao OpenRouter via BYOK. Ela só é exibida uma única vez — perdeu, gera outra. Não cometa o erro de salvá-la em código versionado.

O que é

Uma API key DeepSeek é um token secreto no formato sk-... que identifica e autoriza chamadas à API do provedor. Pode ser revogada a qualquer momento e rotacionada sem afetar a conta.

🧭 Como gerar

  1. Em platform.deepseek.com/api-keys, clicar em Create new API key
  2. Dar um nome descritivo: triad-worker-byok (facilita revogar depois)
  3. Copiar a chave imediatamente — ela some após fechar o modal
  4. Guardar em gerenciador de segredos (1Password, Bitwarden, pass, env file fora do git)

Formato da chave

sk-abc123def456ghi789jkl012mno345pqr678stu

✗ Onde NÃO colocar a chave

  • Hard-coded no código-fonte
  • Em config.json versionado no git
  • Em screenshots de logs ou tutoriais
  • Em chats públicos ou pastebins

✓ Onde colocar com segurança

  • Campo BYOK do OpenRouter (criptografado)
  • Arquivo .env ignorado pelo git
  • Gerenciador de segredos (1Password, Bitwarden)
  • Variável de ambiente do shell

🔑 Conceitos-chave

Formato sk-...

Padrão herdado da OpenAI, adotado por quase todos provedores

Exibida uma única vez

Não é recuperável — perdeu, revoga e gera nova

Nomeação descritiva

Um nome por uso facilita auditoria e revogação cirúrgica

Rotação sem dor

Revogar e gerar nova não afeta saldo nem histórico da conta

4

🔗 Adicionando a chave no OpenRouter (BYOK)

Aqui acontece a mágica do BYOK. Você cola a chave DeepSeek dentro do OpenRouter em uma área específica de integrações — e a partir daí, qualquer chamada que use modelos DeepSeek será roteada pela sua chave, não pelo pool da plataforma.

O que é

A área de Integrations do OpenRouter é onde se registram chaves BYOK de provedores suportados. Cada provedor tem seu próprio slot — você cola a chave DeepSeek apenas no slot DeepSeek, nunca no slot genérico ou no de outro provedor.

🧭 Caminho exato no OpenRouter

1. Login em openrouter.ai

2. Avatar (canto sup. direito) → Settings

3. Aba Integrationsopenrouter.ai/settings/integrations

4. Localizar provedor DeepSeek na lista

5. Clicar em Add key → colar a chave sk-...

6. Salvar — o OpenRouter valida a chave fazendo uma chamada de teste

✗ Colocação errada da chave

  • No slot "Anthropic" ou "OpenAI" por engano
  • Como header Authorization do client
  • Em variável OPENROUTER_API_KEY
  • No campo "default fallback key"

✓ Colocação correta

  • Slot DeepSeek em Settings → Integrations
  • Status fica "BYOK active" verde após salvar
  • Validação OK → próxima chamada já usa sua chave
  • Sua OPENROUTER_API_KEY continua sendo a do OR

💡 O que muda no fluxo

Você continua autenticando seu cliente HTTP com a key do OpenRouter (sk-or-v1-...). O que muda é que, quando você pede um modelo DeepSeek, o OR detecta a chave BYOK registrada e encaminha a chamada usando ela em vez do pool. Para você, a API permanece idêntica — só o billing e os rate limits mudam de origem.

🔑 Conceitos-chave

Settings → Integrations

Único caminho oficial para registrar BYOK no OpenRouter

Slot por provedor

Cada provedor tem seu campo — não confunda DeepSeek com OpenAI ou Anthropic

Validação automática

OR faz uma chamada de teste ao salvar — chave inválida não fica ativa

API permanece igual

Sem mudança no código cliente — apenas o roteamento interno do OR muda

5

⚙️ Configurando DeepSeek como Worker no Hermes

Com BYOK ativo, falta dizer ao Hermes (orquestrador do Triad) que o papel Worker deve usar DeepSeek. Isso é feito no config.json ou via CLI, e inclui parâmetros de amostragem específicos para divergência.

O que é

A configuração de Worker no Hermes mapeia o papel lógico ("Worker") a um modelo concreto (DeepSeek V4 via OpenRouter) e fixa parâmetros como temperature e max_tokens, que controlam diversidade de ângulos e tamanho da resposta por chamada.

Via CLI

hermes config set models.worker deepseek/deepseek-chat
hermes config set models.worker.temperature 0.7
hermes config set models.worker.max_tokens 8000

Via arquivo ~/.hermes/worker_config.json

{
  "role": "worker",
  "provider": "openrouter",
  "model": "deepseek/deepseek-chat",
  "params": {
    "temperature": 0.7,
    "max_tokens": 8000,
    "top_p": 0.95
  },
  "fallback": {
    "model": "deepseek/deepseek-chat",
    "on_429": "wait_and_retry"
  }
}

🎛️ Por que esses parâmetros

  • temperature: 0.7 — alta o suficiente para gerar diversidade entre ângulos, baixa o suficiente para manter coerência interna
  • max_tokens: 8000 — cobre ângulos longos sem truncar, mas força o Worker a respeitar o fallback PARTIAL_DELIVERY
  • top_p: 0.95 — nucleus sampling que filtra cauda muito improvável sem matar criatividade
  • fallback on_429 — espera e reenvia em caso de rate limit, em vez de explodir o loop

🔑 Conceitos-chave

Papel ≠ modelo

Worker é um papel lógico — modelo concreto é configurável e trocável

Temperature 0.7 para Worker

Faixa que equilibra divergência entre ângulos e coerência interna

max_tokens dimensiona orçamento

Limite por chamada — define quando PARTIAL_DELIVERY deve disparar

Fallback explícito on_429

Espera-e-retenta evita que rate limit eventual mate a sessão inteira

6

🧪 Testando o Worker — tarefa ponta a ponta

Antes de rodar overnight, valide com uma tarefa pequena. Você quer confirmar três coisas: a chamada chega no DeepSeek (não no pool OR), os logs do Worker estão isolados, e o Crítico recebe um draft válido em formato esperado.

O que é

Um teste ponta a ponta é uma tarefa real, pequena e barata (1 iteração, 2–3 ângulos) executada com o objetivo único de validar pipeline — chave BYOK ativa, modelo respondendo, logs gravando, Crítico consumindo o output.

Executar e acompanhar logs

# Terminal 1 — tail dos logs do Worker
tail -f ~/.hermes/logs/worker.log

# Terminal 2 — disparar tarefa de teste
hermes run --task "Liste 3 ângulos sobre nichos B2B locais" \
  --max-iterations 1 \
  --verbose

🔍 O que procurar no log

  • provider=openrouter model=deepseek/deepseek-chat — modelo correto
  • byok=true ou header x-or-byok: deepseek — chave própria em uso
  • status=200 em todas as calls do ângulo
  • Ausência de 429 ou 529
  • Tamanho do response coerente com max_tokens=8000

Exemplo de linha de log esperada

2026-05-17T06:42:11Z role=worker angle=2/3 provider=openrouter \
  model=deepseek/deepseek-chat byok=true status=200 \
  tokens_in=412 tokens_out=2841 latency_ms=4120

🔑 Conceitos-chave

Tarefa de fumaça

Pequena, barata, com objetivo único de validar pipeline — não qualidade

Logs isolados por papel

worker.log separado de critic.log facilita debug cirúrgico

Flag byok=true

Indicador objetivo de que o roteamento BYOK está ativo na chamada

Validação antes do overnight

10 minutos de teste evitam acordar com pipeline quebrado às 3am

7

📈 Monitorando uso e custo no primeiro ciclo real

Depois do teste de fumaça, rode um ciclo real e calibre custo + verificação BYOK em duas frentes: a página de Activity do OpenRouter e o dashboard de billing do DeepSeek. Os números têm que bater.

O que é

A calibragem do primeiro ciclo é o processo de cruzar três fontes — Activity do OR, billing do DeepSeek e logs do Hermes — para confirmar que: (a) as chamadas DeepSeek estão marcadas como BYOK no OR, (b) o débito está saindo do crédito DeepSeek e não do crédito OR, (c) o custo total bate com a estimativa.

🧭 Três checagens cruzadas

  1. openrouter.ai/activity — calls DeepSeek aparecem com tag BYOK e custo $0 (ou só taxa de roteamento)
  2. platform.deepseek.com/usage — débito reflete exatamente as mesmas calls que apareceram no Activity
  3. ~/.hermes/logs/worker.log — número de requests bate com o que está no Activity (sem requests fantasma)

💰 Cálculo rápido por ciclo

Conta típica de uma tarefa do Triad com DeepSeek como Worker:

Iterações Worker-Crítico:  3
Ângulos por iteração:      4
Tokens médios out/ângulo:  3000
─────────────────────────────────
Total tokens Worker out:  36000
Total tokens Worker in:   ~6000  (briefing + crítica)
─────────────────────────────────
Custo Worker DeepSeek:    poucos centavos
Custo Crítico (Claude):   dominante na fatura

Conclusão: trocar Worker para DeepSeek BYOK derruba a fatia Worker quase a zero. O custo dominante passa a ser o Crítico — e é nele que a próxima otimização vai mirar.

Checagem rápida no terminal

# Quantas calls foram para DeepSeek na última hora
grep "model=deepseek" ~/.hermes/logs/worker.log | wc -l

# Quantas marcadas como BYOK
grep "byok=true" ~/.hermes/logs/worker.log | wc -l

# Devem ser iguais — se não, BYOK não está ativo em todas

🔑 Conceitos-chave

Três fontes cruzadas

OR Activity + DeepSeek Usage + worker.log — números têm que coincidir

Tag BYOK no Activity

Confirmação visual de que a call não consumiu crédito do OR

Custo Worker → quase zero

DeepSeek BYOK derruba a fatia Worker; foco vai para o Crítico

Grep como auditor

Contagem simples de linhas no log valida cobertura BYOK em 100% das calls

Resumo do Módulo

BYOK = isolamento — sua chave DeepSeek elimina dependência do pool compartilhado do OpenRouter e libera loops overnight
$5–$10 rendem semanas — DeepSeek pré-pago tem custo unitário baixíssimo para o papel Worker
Chave sk-... em slot certo — Settings → Integrations → DeepSeek; nunca no slot de outro provedor
Worker = temperature 0.7, max_tokens 8000 — divergência entre ângulos com coerência interna preservada
Teste de fumaça antes do overnight — tail no worker.log + tarefa de 1 iteração validam pipeline em minutos
Calibragem por 3 fontes — OR Activity, DeepSeek Usage e worker.log têm que bater para garantir BYOK 100% ativo

Próximo Módulo:

2.4 — Gemini CLI: instalação, autenticação e uso como Worker complementar