DeepSeek Super-Agent: quanto custa um agente de código proativo

Atualizado November 2, 2026 · publicado originalmente November 2, 2026

O Super-Agent da DeepSeek (dsh-superagent) é um protótipo de pesquisa com licença MIT que consulta o GitHub periodicamente, transforma pedidos de pessoas autorizadas em tickets e faz uma sessão de trabalho abrir um pull request. Ele limita os workers em paralelo (padrão 3), mas não tem teto de tokens nem de gasto, então a fatura do modelo é controlada apenas pela sua chave de provedor e pelas suas configurações.

Este artigo foi publicado pela primeira vez em 2 de novembro de 2026 a partir do README e da cobertura da imprensa, e reescrito no mesmo dia depois da leitura do próprio repositório (documentação, prompts e código-fonte). Os fatos vêm do repositório do projeto e do Help Net Security. A Bloomberg noticiou o lançamento como um desafio ao Claude Code; a DeepSeek não publicou nenhum benchmark contra ele, então trate esse enquadramento como posicionamento, não como resultado.

O que ele faz?

Entrada: consulta o GitHub pela linha de comando gh, por padrão a cada 60 segundos. Não há webhooks. Menções, issues e pull requests assinados, comentários de revisão e resultados de CI chegam por esse caminho. O chat do Feishu é um plugin opcional separado, desativado por padrão; uma instalação só com GitHub é o padrão documentado.
Admissão: um pedido é explícito quando uma pessoa autorizada se dirige ao agente. Qualquer outra coisa é um candidato inferido que um modelo precisa julgar. Enquanto não houver ninguém na lista de permissões, nenhum pedido pode virar ticket.
Trabalho: uma pequena sessão roteadora decide o que fazer com cada gatilho. Cada ticket aceito recebe sua própria sessão de worker persistente, em seu próprio diretório, geralmente um git worktree. O worker implementa, verifica, faz commit, push e abre um pull request na conta do GitHub do próprio agente, depois acompanha o CI e a revisão.
Status: o README o chama de “protótipo de pesquisa apenas para referência, não um produto oficial da DeepSeek” e diz para tratá-lo como código de pesquisa, não como software pronto para produção.

Para onde vai o dinheiro?

Consultar o GitHub não gasta tokens de modelo. O gasto começa quando um modelo é chamado. No código, isso acontece em três lugares:

A sessão roteadora lê todo gatilho admitido e o encaminha. Cada pedido explícito custa, portanto, pelo menos um turno do roteador antes de qualquer trabalho começar.
O avaliador julga os candidatos inferidos. Isso importa para a configuração padrão: no modo observe o agente ainda executa a avaliação e apenas registra “aceitaria” em vez de agir. O modo observe é um modo sombra para ações, não para custo. Por padrão o agente só recebe mensagens dirigidas a ele, então mensagens não dirigidas chegam ao avaliador apenas se você ativar as chaves de observação em todo o repositório para issues, pull requests, comentários ou CI.
As sessões de worker fazem o trabalho de verdade: ler código, editar, rodar verificações, tentar de novo após falhas e tratar rodadas de revisão. Cada worker tem seu próprio contexto, que é onde vai a maior parte dos tokens.

O modelo do roteador/avaliador e o modelo dos workers são definidos separadamente, e o modelo de um worker é fixado quando a sessão é criada. O código não tem contador de tokens, teto por ticket nem registro de gastos, e o painel não mostra uso nem custo. O único código relacionado a orçamento detecta um erro “budget exceeded” do provedor durante as novas tentativas e o exibe como um alerta de saúde; ele não interrompe o trabalho. A documentação da DeepSeek não informa um custo por pull request.

Que limites existem?

Limite	Valor documentado
Workers em paralelo	3 por padrão, configurável de 1 a 16, mais um slot extra que só abre quando a mensagem de uma pessoa desperta um worker
Intervalo de consulta	60 segundos por padrão (60 a 3600)
Tempo limite da avaliação	120 segundos por padrão (30 a 600); duas recolocações na fila e depois registrada como indisponível
Erros transitórios do modelo	3 novas tentativas automáticas aos 15, 30 e 60 segundos; depois disso o ticket é marcado como falho e espera por uma pessoa
Jobs em segundo plano após o turno de um worker	30 minutos, depois são encerrados
Rodadas de revisão por bot	3 por pull request por revisor automatizado (texto do prompt, não código aplicado)
Merge automático	Desativado, a menos que você indique uma conta de merge separada; nesse caso, só para um pull request pronto com menos de 200 linhas alteradas e aprovações que cubram o commit de cabeça. Isso também é texto do prompt, não código

Um slot de worker continua ocupado enquanto seus jobs em segundo plano rodam, então o limite de workers é também um limite de gasto simultâneo de tokens, embora não seja um limite do quanto cada worker gasta.

O que ele exige e quais são os riscos?

Uma conta de usuário do GitHub dedicada ao agente, com acesso de escrita. Um GitHub App não pode ser o agente porque o agente lê notificações. Ele também precisa do runtime DeepSeek Harness (dsh), Node, pnpm, git, tmux e gh.
Acesso total. As sessões de worker rodam com o perfil de permissão de acesso total, como o usuário do sistema operacional do próprio operador. O projeto diz que seus wrappers de comando são padrões, não uma fronteira de segurança. Execute-o em uma máquina ou conta isolada.
O estado cresce sem limite. As notas de arquitetura dizem que os registros antigos ainda não são apagados.

Como orçar um teste?

Use o registro de pedidos que teriam sido aceitos para dimensionar o trabalho e depois precifique-o com as suas próprias medições. O gasto mensal é itens de trabalho aceitos x custo médio faturado por item, em que o custo por item inclui o turno do roteador, qualquer avaliação, cada chamada de worker, cada nova tentativa e cada tentativa abandonada. Divida o gasto total pelos itens que viraram mudanças aceitas, como no custo por tarefa bem-sucedida.

Ilustração com dados presumidos, não da DeepSeek: 200 itens de trabalho por mês a um custo médio faturado presumido de $4 cada dão $800. Se apenas 140 produzirem uma mudança aceita, o custo por mudança aceita é $800 / 140 = $5,71, não $4. A diferença é o preço do trabalho abandonado e rejeitado.

Que controles definir primeiro?

Mantenha a lista de permissões pequena e adicione pessoas de forma deliberada. Ela é a primeira barreira de gasto.
Deixe desligadas as chaves de receber tudo até ler o registro de “aceitaria”, pois são elas que enviam tráfego não dirigido ao avaliador.
Defina maxWorkers baixo durante um teste e coloque o teto de gasto real na chave do seu provedor de modelo ou no gateway, já que o projeto não tem nenhum. Veja os três orçamentos de agentes e as barreiras de gasto em produção.
Etiquete o gasto por repositório e ticket para que um pull request possa ser rastreado até a sua fatura.
Deixe o merge para as pessoas e trate o prompt de entrega como um arquivo de política com um responsável.

Como ele se compara a outros agentes do GitHub?

Outras três opções transformam um pedido do GitHub em um pull request. O que muda é onde o gasto aparece e o que o limita. Conferido em 2 de novembro de 2026; confirme na página de cada fornecedor.

Opção	Gatilho e runtime	Onde o gasto aparece	Tetos documentados
Claude Code GitHub Action	Mencione `@claude` em um comentário de issue ou PR; roda em runners hospedados pelo GitHub. O usuário que dispara precisa ter acesso de escrita, e atores bot são rejeitados, a menos que estejam listados	Minutos do GitHub Actions mais tokens da API do Claude (ou sua assinatura do Claude, se você usar um token OAuth)	`--max-turns`, tempos limite no nível do workflow e controles de concorrência do GitHub
GitHub Copilot cloud agent	Pesquisa, planeja e implementa em segundo plano em um ambiente de nuvem; um pull request por tarefa	A computação de nuvem e do Actions consome uma franquia mensal da conta do GitHub, separada dos créditos de IA; os detalhes de cobrança estão em outra página	Sessões do Actions têm máximo de 59 minutos. Somente leitura sem acesso de escrita; a proteção de branch pode bloqueá-lo. A nova experiência na nuvem é para planos pagos a partir de 28 de outubro de 2026
OpenHands	Licença MIT, auto-hospedado; roda seu próprio agente ou agentes de terceiros; traga seu próprio modelo. O README não informa como uma issue do GitHub o aciona	Seu provedor de modelo, ou o OpenHands Cloud	Não informado no README. O modo sem sandbox avisa que o agente tem acesso total ao sistema de arquivos
DeepSeek Super-Agent	Consulta o GitHub; conta de agente dedicada; auto-hospedado	Sua chave de provedor de modelo	Apenas número de workers e tempos limite; sem teto de tokens ou de gasto

A diferença prática é que as opções hospedadas ficam dentro de uma fatura que você já governa (uma franquia do Actions, uma chave de API com limites de workspace) e documentam tetos de turnos ou de tempo, enquanto o Super-Agent deixa tudo isso por sua conta. Para comparações de custo entre ferramentas, veja custo do Cursor vs Copilot vs Claude Code.

Você deve implantá-lo agora?

Em produção, não: a própria DeepSeek diz que ele não está pronto para produção. Para um teste contido em um repositório não crítico, em uma máquina isolada, com uma chave com teto, é uma forma barata de aprender quanto agentes proativos custam à sua equipe, porque o código é gratuito e o gasto fica visível no seu próprio provedor. A métrica de decisão é o custo por pull request aceito frente à atenção que ele economiza, não a manchete de que ele concorre com outra ferramenta.

Perguntas frequentes

O que é o Super-Agent da DeepSeek?

O dsh-superagent é um protótipo de pesquisa open source (MIT) de um agente de código proativo da DeepSeek. Ele consulta o GitHub, admite pedidos de pessoas autorizadas, dá a cada ticket aceito uma sessão de worker em seu próprio diretório e abre um pull request na sua própria conta do GitHub.

O Super-Agent tem limite de gasto?

Não. Ele limita os workers em paralelo (padrão 3, de 1 a 16) e tem tempos limite e limites de novas tentativas, mas não tem contador de tokens, teto por ticket nem registro de gastos, e seu painel não mostra uso nem custo. Defina o teto na chave do seu provedor de modelo ou no gateway.

O Super-Agent é gratuito?

O código é gratuito sob a licença MIT. Executá-lo custa o que custarem os modelos, a máquina e as ferramentas que você conectar. A DeepSeek não publica números de custo por tarefa.

O modo observe evita custos de modelo?

Não. O modo observe executa a avaliação e registra que o agente teria aceitado o pedido, em vez de agir sobre ele. Ele economiza o custo do worker, não o do avaliador. Por padrão só são recebidas as mensagens dirigidas ao agente, então mensagens não dirigidas só são avaliadas se você ativar as chaves de observação.

O Super-Agent está pronto para uso em produção?

Não. O README o chama de protótipo de pesquisa apenas para referência, não um produto oficial da DeepSeek, e diz para tratá-lo como código de pesquisa. Seus workers rodam com acesso total como o usuário do operador, e seu estado cresce sem limite.