DEV Community: Lucas

Como Usar a CLI do Apidog no DeepSeek Harness

Lucas — Thu, 20 Aug 2026 08:01:23 +0000

DeepSeek Harness é um loop: o agente lê o espaço de trabalho, edita arquivos, executa comandos com a ferramenta bash e decide o próximo passo com base na saída. Seus testes de API também devem fazer parte desse loop, em vez de ficarem apenas na GUI do Apidog aguardando alguém clicar em Executar.

Experimente o Apidog hoje

A integração depende de um único bloco de configuração. O CLI do Apidog, o pacote npm apidog-cli, executa cenários de teste criados no Apidog diretamente no terminal. Depois de instalar o CLI e informar sua existência ao DeepSeek Harness, o agente pode executar um cenário do Apidog como executa testes de unidade: roda o comando, verifica o código de saída e corrige o código quando houver falhas.

Isso também economiza contexto. Em vez de reler handlers e inferir se os formatos de resposta ainda estão corretos, o agente executa um comando e recebe uma resposta objetiva. O CLI transforma a pergunta “a API está correta?” em um código de saída e em um relatório de asserções. Assim, o agente usa o contexto para corrigir o problema, não para especular sobre ele.

Este guia cobre a configuração específica do harness: qual arquivo de instruções o DeepSeek Harness lê, como a ferramenta bash executa apidog run e como validar que o agente realmente testou a API. Antes de continuar, instale e autentique o CLI. Veja como instalar o Apidog CLI com um agente de codificação de IA. Este artigo pressupõe que apidog --version retorna uma versão e que a máquina já está autenticada.

Sobre qual DeepSeek Harness este artigo trata

DeepSeek Harness, disponível como dsh na linha de comando, é o harness de agente de código aberto lançado pela DeepSeek em 13 de agosto de 2026, junto com o V4-Pro na API. Ele é licenciado sob MIT, está em github.com/deepseek-ai/deepseek-harness e já havia ultrapassado 169 mil estrelas em 20 de agosto.

Inicie a interface web local com:

npx @deepseek-ai/dsh web

A interface fica disponível em:

http://127.0.0.1:3080

Nela, selecione o espaço de trabalho — normalmente o diretório do projeto — e deixe o agente trabalhar dentro dele. O agente pode ler e editar arquivos, executar comandos e solicitar aprovação para operações cobertas pela política de permissões ativa.

Dois pontos são importantes:

O harness é uma prévia para desenvolvedores. O README avisa que mudanças incompatíveis podem ocorrer. Os nomes de arquivos e chaves de configuração deste artigo refletem o final de agosto de 2026. Se algo não funcionar, consulte a documentação do repositório.
Tudo no dsh é um plugin, baseado na arquitetura Cordis. Isso permite identificar exatamente qual plugin carrega regras de projeto e quais arquivos ele procura.

Para uma visão geral, veja o que é DeepSeek Harness. Para uma comparação com outro harness, veja DeepSeek Harness vs Claude Code.

Passo 1: adicione o Apidog CLI ao `AGENTS.md`

O DeepSeek Harness carrega instruções do workspace por meio do plugin @deepseek-ai/dsh-agent-instructions.

Segundo o código do plugin e o catálogo de configuração, o carregador percorre o caminho entre o diretório de trabalho da sessão e a raiz do projeto, identificada por .git. Em cada diretório, ele procura:

AGENTS.md
CLAUDE.md como fallback
AGENTS.local.md como overlay local
CLAUDE.local.md como overlay local

Também é possível manter um arquivo global em:

$DSH_HOME/AGENTS.md

Por padrão, DSH_HOME é:

~/.dsh

Arquivos com mais de 1 MiB são ignorados.

Na prática, se o repositório já possui um AGENTS.md usado por Codex ou um CLAUDE.md usado por Claude Code, o DeepSeek Harness pode reutilizá-lo sem configuração adicional.

Adicione um bloco explícito para os testes da API:

## Testes de API com o Apidog CLI

- Para testar a API, execute o cenário do Apidog. Não use a GUI.
- Comando: apidog run -t <scenario_id> -e <env_id> -r cli
- Código de saída 0 significa que todas as asserções passaram.
- Um código diferente de zero indica falha: leia o relatório e corrija o código.
- A máquina já está autenticada. Nunca adicione --access-token e nunca armazene tokens neste arquivo.

Substitua <scenario_id> e <env_id> pelos IDs reais do seu projeto.

Esse arquivo é mais confiável do que instruções enviadas no chat. Uma mensagem da sessão desaparece ao final da conversa. Um comando documentado em AGENTS.md é carregado em novas sessões, por colegas de equipe e em máquinas que clonam o repositório.

Se você trabalha em muitos projetos, use o arquivo global ~/.dsh/AGENTS.md para a regra geral:

Sempre valide mudanças de API com o comando apidog run definido no projeto.

Depois, mantenha os IDs específicos de cenário e ambiente no AGENTS.md de cada repositório.

Passo 2: copie o comando gerado pelo Apidog

Não adivinhe os IDs do cenário e do ambiente.

Abra o cenário de teste no Apidog.
Acesse a aba CI/CD.
Copie o comando gerado.

O comando terá este formato:

apidog run -t 123456 -e 789012 -r cli

Onde:

-t é o ID do cenário de teste.
-e é o ID do ambiente.
-r cli seleciona o reporter de terminal.

O reporter cli é importante porque imprime requisições, asserções e erros diretamente na saída que o agente consegue ler.

Cole o comando real no AGENTS.md. Dessa forma, o agente executa o comando gerado pelo Apidog, e não uma combinação de IDs inventada ou inferida.

Passo 3: faça o agente executar o teste

Inicie uma sessão na interface web do dsh com o workspace correto selecionado. Como o AGENTS.md já foi carregado, o agente saberá que o Apidog CLI está disponível.

Depois de alterar um endpoint, handler ou contrato de API, envie uma solicitação direta:

Execute o cenário de teste do Apidog e informe o código de saída.

O agente executará o comando pela ferramenta bash.

Segundo o catálogo de ferramentas, a ferramenta bash padrão executa cada chamada em um shell limpo. Isso significa que diretório atual, variáveis e funções não persistem entre chamadas.

Por exemplo, isto não é confiável como duas chamadas separadas:

cd services/api

apidog run -t 123456 -e 789012 -r cli

A segunda chamada não herdará o cd.

Se o cenário precisar ser executado em um subdiretório, informe o caminho completo em uma única instrução no arquivo de regras:

- Execute o teste a partir de services/api:
  cd services/api && apidog run -t 123456 -e 789012 -r cli

Ou use o parâmetro workdir da ferramenta quando ele estiver disponível.

Também observe estes comportamentos:

Falhas retornam um marcador explícito como [exit code: 1].
O código de saída continua visível mesmo se uma saída longa for truncada.
Operações bloqueadas por sandbox são reportadas como negação de política, não como falha do comando.
Um teste somente leitura geralmente não deve ser bloqueado, mas um reporter que grava arquivos pode depender da política de permissões ativa.

A interface web pode solicitar aprovação antes de executar apidog run. Conforme o guia do usuário, isso depende da política configurada. Aprovar a execução de um cenário contra staging é um caso esperado para esse fluxo.

Passo 4: leia o relatório e corrija a falha

Quando o comando falhar, use o reporter inline para localizar a causa.

Com -r cli, o agente recebe informações como:

requisição executada;
status retornado;
asserção que falhou;
valor esperado;
valor real.

Isso normalmente é suficiente para encontrar a correção no handler, no schema ou na lógica de negócio.

Para também gerar um relatório navegável, inclua o reporter HTML:

apidog run -t 123456 -e 789012 -r cli,html

O reporter html grava um relatório autocontido em:

./apidog-reports

Mantenha cli na lista. O HTML é útil para revisão humana, mas o agente precisa da saída inline para decidir o próximo passo.

O loop completo: editar, testar, corrigir

Com a configuração pronta, o fluxo fica assim:

O agente edita um handler, por exemplo, de checkout.
Ele executa o cenário:

   apidog run -t 123456 -e 789012 -r cli

Ele lê o resultado.
Se o comando retornar 0, ele segue para a próxima tarefa.
Se retornar algo como [exit code: 1], ele identifica a asserção quebrada.
Ele corrige o código.
Ele executa o cenário novamente.

Uma falha pode indicar, por exemplo:

retorno 500 onde era esperado 200;
campo total ausente;
código de moeda incorreto;
schema de resposta incompatível.

O cenário de teste já codifica o contrato esperado. Em vez de o agente reler todas as rotas para tentar provar que a API funciona, ele delega a validação a uma ferramenta determinística.

A divisão de responsabilidades fica clara:

o dsh escreve e altera código;
o Apidog CLI verifica o comportamento da API;
sua equipe cria e mantém cenários visualmente no Apidog, sem escrever código de teste.

Verifique se o dsh realmente executou o cenário

Não aceite apenas um resumo como “os testes passaram”. Valide a execução em três etapas.

1. Confirme a chamada do comando

A interface do dsh mostra chamadas de ferramentas e suas saídas. Procure pelo comando bash literal:

apidog run ...

Se o agente afirma que executou os testes, mas não existe uma chamada correspondente, ele não executou o cenário. Peça para rodar novamente e mostrar a saída bruta.

2. Confirme o código de saída

Pergunte diretamente:

Qual foi o código de saída do comando apidog run?

Em falhas, o harness retorna um marcador como:

[exit code: 1]

Se o resumo disser que os testes passaram, mas o marcador indicar valor diferente de zero, confie no código de saída.

3. Confirme os IDs do cenário e do ambiente

Um erro como “cenário não encontrado” normalmente significa que o agente usou IDs errados.

Compare os valores de:

-t <scenario_id> -e <env_id>

com:

o bloco em AGENTS.md;
o comando exibido na aba CI/CD do Apidog.

Os IDs documentados no arquivo de regras são a fonte de verdade. Qualquer outro valor digitado pelo agente é uma suposição.

Opcional: adicione o servidor Apidog MCP para acessar a especificação

O CLI resolve a parte de verificação. Se você também quer que o agente consulte a especificação da API enquanto implementa endpoints, use MCP.

A partir do final de agosto de 2026, o suporte a MCP não está documentado no README principal nem no guia do usuário do DeepSeek Harness. Existe, porém, um plugin da comunidade: hyqhyq3/dsh-mcp-manager.

Esse plugin, descoberto pelo tópico dsh-plugin no GitHub, adiciona uma página MCP em Configurações e oferece suporte a:

servidores HTTP remotos;
servidores stdio locais;
ferramentas registradas como mcp__<name>__*;
definições por projeto em:

  <workspace>/.dsh/dshmm/mcp.json

Com ele, você pode conectar o servidor Apidog MCP. Isso permite que o agente consulte especificações de API por MCP antes de escrever um handler.

Trate essa integração como complementar. Um plugin comunitário em um harness de prévia pode sofrer incompatibilidades em atualizações. O caminho essencial continua sendo o CLI: ele depende apenas de um shell e de um comando apidog run.

Ressalvas da prévia e próximos passos

O DeepSeek Harness evolui rapidamente e declara que pode introduzir mudanças incompatíveis. As partes mais propensas a mudar são:

arquivos carregados pelo plugin de instruções;
comportamento do sandbox da ferramenta bash;
detalhes do plugin MCP da comunidade.

O padrão principal, porém, é portátil:

Documente no arquivo de regras como validar a API.
Execute um único comando determinístico.
Use o código de saída como sinal objetivo de sucesso ou falha.

Isso funciona no dsh pela mesma razão que funciona no Claude Code e em outros harnesses: agentes leem bem a saída de comandos, mas não devem validar a própria implementação apenas por raciocínio.

Para implementar:

Baixe o Apidog.
Crie um cenário de teste visualmente.
Copie o comando apidog run da aba CI/CD.
Adicione esse comando ao AGENTS.md.
Peça ao DeepSeek Harness para executar o cenário após cada alteração relevante na API.

Na próxima vez que o agente modificar código de API, ele poderá verificar o próprio trabalho antes de informar que concluiu a tarefa.

FAQ

O DeepSeek Harness lê AGENTS.md nativamente?

Sim. O plugin @deepseek-ai/dsh-agent-instructions carrega AGENTS.md ou usa CLAUDE.md como fallback. Ele procura arquivos desde a raiz do projeto até os diretórios acima do diretório de trabalho da sessão.

Também reconhece os overlays:

AGENTS.local.md
CLAUDE.local.md

Além disso, carrega um AGENTS.md global em:

~/.dsh

Se você já mantém um AGENTS.md para outros agentes, o dsh pode reutilizá-lo sem alterações.

Preciso de um plano pago do DeepSeek para usar o Apidog CLI no dsh?

Não. O harness é de código aberto e licenciado sob MIT. Você fornece o modelo que deseja usar: provedores de catálogo incluem Anthropic, OpenAI, Bedrock, Vertex e Azure, enquanto gateways personalizados funcionam por meio de settings.yaml.

Veja como executar qualquer modelo no DeepSeek Harness.

O Apidog CLI é um pacote npm gratuito. Ele exige um cenário de teste do Apidog e autenticação, não um modelo específico.

Por que o segundo comando esquece o diretório alterado pelo primeiro?

Isso acontece por design. A ferramenta bash padrão do dsh executa cada chamada em um shell limpo, então um cd não persiste entre comandos.

Use uma das opções:

cd services/api && apidog run -t 123456 -e 789012 -r cli

Ou passe o workdir para a ferramenta bash, quando disponível.

A opção mais simples é manter toda a invocação em uma linha no arquivo de regras.

O dsh pode executar o cenário sem pedir aprovação toda vez?

Depende da política de permissão ativa. A interface web solicita aprovação para operações que exigem consentimento conforme a política configurada.

O guia do usuário não enumera todos os níveis dessa política. Verifique as Configurações da sua compilação para entender o que sua implantação permite.

Quando o dsh solicitar aprovação, executar apidog run contra um ambiente de staging é um caso adequado para permitir.

DeepSeek Harness vs Claude Code: Qual o Agente de Código Ideal para Sua Stack?

Lucas — Thu, 20 Aug 2026 06:07:46 +0000

O DeepSeek Harness (dsh) foi lançado em 13 de agosto de 2026, e sua abordagem chamou atenção imediatamente. A manchete de lançamento do VentureBeat o descreveu como um “rival de código aberto do Claude Code”, lançado junto com o DeepSeek V4-Pro na API. Em 20 de agosto, o repositório tinha aproximadamente 169 mil estrelas.

Experimente o Apidog hoje

Mas estrelas no GitHub não respondem à pergunta prática: vale mais a pena executar um agente de código com DeepSeek Harness ou Claude Code?

As ferramentas adotam estratégias diferentes:

O dsh é uma prévia para desenvolvedores, open source sob licença MIT, baseada em um kernel de plug-ins e uma interface web local.
O Claude Code é um produto proprietário e maduro, com habilidades, hooks, MCP nativo, subagentes e várias interfaces.

Este guia compara licenciamento, interface, modelos, custos, extensibilidade, permissões e MCP — sem benchmarks inventados. Se você ainda não conhece o dsh, leia primeiro o que é o DeepSeek Harness e como ele funciona.

💡 Ambos os agentes escrevem código para APIs e dependem da qualidade da especificação fornecida. O Apidog ajuda a manter essa especificação testada e atualizada, independentemente do agente escolhido.

Comparação rápida

Dimensão	DeepSeek Harness (dsh)	Claude Code
Licença	MIT, código-fonte no GitHub	Proprietária; termos comerciais da Anthropic
Idade	Lançado em 13 de agosto de 2026; prévia para desenvolvedores	Produto maduro e geralmente disponível
Estabilidade	README alerta sobre mudanças que quebram compatibilidade	Canais de lançamento estáveis e configurações versionadas
Interface	UI web local em `127.0.0.1:3080`, CLI e modo headless	Terminal, VS Code, JetBrains, desktop, web e mobile
Modelos	DeepSeek, Anthropic, OpenAI, Bedrock, Vertex, Azure e endpoints compatíveis com OpenAI	Apenas modelos Claude, diretos ou via provedores de nuvem
Preço	Harness gratuito; cobrança por token da API conectada	Claude Pro/Max ou faturamento por uso de API
Extensibilidade	Arquitetura baseada em plug-ins Cordis	Plug-ins, habilidades, hooks, subagentes e SDK de Agente
Permissões	Aprovações conforme a política ativa	Seis modos e regras granulares de permissão/negação
MCP	Plug-in da comunidade	Nativo e de primeira classe

Código aberto vs. proprietário

O DeepSeek Harness usa licença MIT e rastreia dependências de terceiros em THIRD_PARTY_NOTICES.md.

Na prática, isso permite:

Inspecionar o loop do agente.
Fazer fork do projeto.
Corrigir ou adaptar comportamentos.
Incorporar o harness em produtos comerciais.
Auditar o que a ferramenta envia pela rede.

Isso é relevante para equipes com exigências de conformidade, ambientes regulados ou ferramentas internas que não podem depender exclusivamente de um fornecedor.

O Claude Code segue o modelo oposto. O repositório público da Anthropic inclui o aviso:

© Anthropic PBC. Todos os direitos reservados.

Você recebe um produto, documentação e suporte, mas não pode auditar ou alterar o código-fonte do agente.

Quando isso importa?

Escolha o dsh se sua equipe precisa de:

Auditabilidade de código.
Capacidade de fork.
Controle da infraestrutura.
Menor dependência de fornecedor.

Mas considere o risco: licença MIT garante direitos de uso, não manutenção contínua. O dsh ainda é um projeto muito recente.

Interface: UI web local vs. múltiplos ambientes

O fluxo inicial do dsh é:

npx @deepseek-ai/dsh web

Esse comando inicia uma interface web local em:

http://127.0.0.1:3080

Para evitar que o navegador seja aberto automaticamente:

npx @deepseek-ai/dsh web --no-open

A interface trabalha sobre o diretório do projeto em que o dsh foi iniciado.

Além da UI web, o README da CLI documenta perfis nomeados:

dsh --profile <name>

Os perfis ficam em:

$DSH_HOME/profiles/<name>

Também há suporte a execução headless para automação, scripts e pipelines. O comando abaixo usa o perfil web:

dsh web

E o gerenciamento de plug-ins pode ser feito com:

dsh plugin

O Claude Code oferece uma cobertura maior de interfaces. Segundo a documentação oficial, ele funciona em:

Terminal.
VS Code.
JetBrains.
Aplicativo desktop.
Navegador em claude.ai/code.
Mobile.

Para automação, a execução headless é direta:

claude -p "implemente testes para este módulo"

Esse formato se encaixa em CI, cron jobs e scripts shell.

Decisão prática

Use o dsh se você trabalha principalmente em uma máquina e quer uma UI local simples.

Use o Claude Code se seu fluxo alterna entre IDE, terminal, CI, navegador e dispositivos móveis.

Liberdade de modelo

Essa é a maior diferença arquitetural entre as ferramentas.

O dsh é agnóstico a modelos. A documentação de provedores inclui catálogos para:

Anthropic
OpenAI
Amazon Bedrock
Google Vertex AI
Azure

Ele também aceita endpoints compatíveis com OpenAI configurados em:

$DSH_HOME/settings.yaml

Uma configuração típica exige:

apiKeyEnv: MINHA_API_KEY
api: openai-completions
baseURL: https://api.exemplo.com/v1
models:
  - meu-modelo

As credenciais ficam separadas em:

.credentials.yaml

Isso permite compartilhar o arquivo de configuração sem expor chaves de API.

Com essa arquitetura, o dsh pode usar modelos DeepSeek, APIs de outros provedores ou modelos locais expostos por servidores compatíveis com OpenAI. Veja o passo a passo em como executar qualquer modelo no DeepSeek Harness.

O Claude Code executa apenas modelos Claude. A inferência pode passar por Bedrock, Vertex ou Foundry, mas o modelo continua sendo Claude.

Decisão prática

Escolha o dsh se você precisa alternar modelos, reduzir lock-in ou testar provedores locais.

Escolha o Claude Code se você prefere uma integração otimizada entre o harness e os modelos Claude.

Preço: pagamento por token vs. assinatura

O DeepSeek Harness é gratuito. O custo está na inferência da API conectada.

Se você usar a API da DeepSeek, pagará as taxas por token da DeepSeek. O DeepSeek V4-Pro foi lançado no mesmo período do dsh com preços superiores aos de seus predecessores, segundo a cobertura do VentureBeat.

Para usar a API V4-Pro, consulte como usar a API DeepSeek V4-Pro-0813.

O modelo de custo do dsh é simples:

Custo total = tokens consumidos × preço do provedor

Isso favorece uso leve ou esporádico, mas sessões agênticas longas podem consumir muitos tokens sem um teto fixo.

O Claude Code geralmente usa:

Claude Pro: US$ 20/mês.
Claude Max: US$ 100 ou US$ 200/mês.
API com cobrança por uso, via Claude Console.

A assinatura torna o gasto mais previsível, embora existam limites de uso. A Anthropic aumentou os limites semanais em 50% em julho de 2026, conforme detalhado em nossa cobertura do aumento dos limites semanais do Claude Code.

Regra prática

Uso ocasional: pagamento por token costuma ser mais vantajoso.
Uso diário intenso: assinatura pode oferecer maior previsibilidade.
Necessidade de múltiplos provedores: dsh oferece mais flexibilidade.

Maturidade: prévia vs. produto estabelecido

O DeepSeek Harness é explicitamente uma prévia para desenvolvedores. Seu README alerta:

HAVERÁ MUDANÇAS QUE QUEBRARÃO A COMPATIBILIDADE.

Trate isso como um requisito operacional. Configurações, plug-ins e fluxos automatizados podem exigir ajustes em versões futuras.

Antes de adotar dsh em produção, faça o seguinte:

Versione arquivos de configuração no Git.
Fixe versões de plug-ins quando possível.
Execute o dsh em um ambiente isolado.
Documente como recriar seus perfis.
Mantenha testes de regressão fora do agente.

O Claude Code está em uso desde o início de 2025 e possui um ecossistema mais consolidado:

Memória de projeto via CLAUDE.md.
Memória automática.
Habilidades reutilizáveis.
Hooks para executar comandos shell.
Subagentes.
SDK de Agente.
Integração com GitHub Actions e GitLab CI/CD.
Rotinas agendadas.

A comparação com outro concorrente maduro em Claude Code vs Codex CLI também mostra como a maturidade do ecossistema influencia a escolha.

Extensibilidade: kernel de plug-ins vs. pontos de extensão

No dsh, plug-ins não são um recurso adicional: são a base da arquitetura.

O projeto usa o Cordis, um kernel de plug-ins descrito no artigo “A Programming Paradigm for Spatiotemporal Composability”. Componentes como adaptadores de modelo, ferramentas, logs de sessão e o loop do agente podem ser substituídos.

Isso permite alterar profundamente o comportamento do agente, por exemplo:

Substituir o adaptador de modelo.
Adicionar ferramentas internas.
Criar um roteador de contexto.
Personalizar a estratégia de repetição de chamadas de ferramentas.
Alterar o loop de execução do agente.

Projetos da comunidade podem ser encontrados pelo tópico:

dsh-plugin

No Claude Code, a extensão ocorre por interfaces definidas:

Plug-ins.
Habilidades.
Hooks.
Servidores MCP.
Subagentes.

Você pode customizar o comportamento sem modificar o loop central da Anthropic.

Decisão prática

Use dsh se você precisa modificar o motor do agente.

Use Claude Code se precisa de extensões estáveis em pontos conhecidos, com menor risco de quebra após atualizações.

Permissões

Agentes capazes de editar arquivos e executar comandos precisam de controles claros.

No dsh, a interface web solicita aprovação para operações que exigem autorização segundo a política de permissões ativa. A documentação pública ainda não detalha completamente os níveis de política e suas semânticas.

No Claude Code, o sistema de permissões define seis modos:

default
acceptEdits
plan
auto
dontAsk
bypassPermissions

Além disso, ele oferece:

Regras granulares de permissão e negação.
Restrições por diretório de trabalho.
Políticas gerenciadas para organizações.
Controle por ferramenta e comando.

Exemplos práticos:

Use plan quando quiser que o agente explore e proponha mudanças sem editar arquivos.
Use acceptEdits para revisar alterações antes de aceitá-las.
Use auto quando quiser reduzir prompts usando classificação em segundo plano.
Reserve bypassPermissions para ambientes em sandbox, como contêineres isolados.

Para bases de código reguladas, equipes grandes ou CI autônomo, o Claude Code tem controles mais documentados atualmente.

MCP: nativo vs. plug-in da comunidade

O Model Context Protocol (MCP) permite que agentes acessem sistemas externos, como:

Bancos de dados.
Rastreadores de tickets.
Documentação interna.
Especificações de API.
Ferramentas de teste.

O Claude Code suporta MCP nativamente. As ferramentas MCP participam das mesmas regras de permissão usadas pelo restante do agente.

No dsh, MCP não faz parte do núcleo atualmente. O suporte vem do plug-in comunitário:

dsh-mcp-manager

Esse plug-in adiciona suporte para:

Servidores MCP HTTP remotos.
Servidores MCP locais via stdio.
OAuth.
Tokens estáticos.
Configuração por projeto.
Ferramentas registradas no formato:

mcp__<name>__*

Ele funciona, mas não é um componente oficial do núcleo do dsh e pode ser afetado pela instabilidade da prévia.

Como usar Apidog com os dois agentes

Para desenvolvimento de APIs, o ponto mais importante é garantir que o agente trabalhe contra o contrato real da API.

O Apidog MCP Server pode expor a especificação da sua API para o agente. Assim, ele pode gerar clientes, handlers e testes com base nos endpoints e schemas reais, em vez de inventar nomes de campos.

Fluxo recomendado:

Mantenha a especificação OpenAPI atualizada no Apidog.
Conecte o Apidog MCP Server ao Claude Code ou ao dsh.
Peça ao agente para consultar a especificação antes de gerar código.
Execute testes de regressão com Apidog CLI no CI.
Bloqueie merges quando os testes de contrato falharem.

No Claude Code, a conexão MCP é nativa.

No dsh, ela passa pelo dsh-mcp-manager.

Você pode baixar o Apidog e executar seu servidor MCP no mesmo projeto em que os agentes trabalham.

Qual você deve escolher?

Não existe um vencedor absoluto. A decisão depende do seu nível de tolerância a mudanças, da necessidade de controle e do ambiente em que o agente será usado.

Escolha o DeepSeek Harness se:

Você precisa inspecionar, auditar ou fazer fork do código.
A licença MIT é um requisito.
Você quer usar modelos DeepSeek, modelos locais ou outros provedores compatíveis.
Você quer alterar o loop ou a arquitetura do agente.
Você aceita mudanças incompatíveis e manutenção adicional.

Para começar:

npx @deepseek-ai/dsh web

Escolha o Claude Code se:

Você precisa de um produto mais consolidado.
Seu fluxo exige terminal, IDE, CI, desktop, web e mobile.
Você precisa de controles de permissão detalhados.
MCP nativo é importante.
Sua equipe prefere custos previsíveis por assinatura.
Você já decidiu trabalhar com modelos Claude.

Estratégia pragmática

Você não precisa escolher imediatamente.

Teste o dsh em projetos experimentais e use Claude Code em fluxos críticos. Em ambos os casos, mantenha a camada de API protegida com o Apidog: uma especificação testada, disponível via MCP e validada por execuções de regressão com CLI após mudanças geradas pelo agente.

FAQ

O DeepSeek Harness é realmente open source, ao contrário do Claude Code?

Sim. O dsh usa licença MIT e disponibiliza o código-fonte no GitHub, incluindo o loop do agente e o kernel de plug-ins. O repositório público do Claude Code usa aviso de todos os direitos reservados sob os Termos Comerciais da Anthropic e não fornece código-fonte para fork.

O DeepSeek Harness pode usar modelos Claude?

Sim. O dsh oferece provedores de catálogo para Anthropic, OpenAI, Bedrock, Vertex e Azure, além de endpoints compatíveis com OpenAI configurados em settings.yaml.

O inverso não é verdadeiro: Claude Code executa apenas modelos Claude, diretamente ou por Bedrock, Vertex e Foundry.

O DeepSeek Harness é estável para trabalho diário?

Ele é uma prévia para desenvolvedores, e o README alerta sobre mudanças que quebram compatibilidade. É utilizável para trabalho real, mas espere mudanças em configurações e plug-ins.

Para fluxos que não podem ser reconstruídos com frequência, Claude Code é a alternativa mais segura atualmente.

Ambos os agentes funcionam com Apidog?

Sim. O servidor MCP do Apidog expõe sua especificação de API para agentes compatíveis com MCP:

Nativamente no Claude Code.
No dsh via dsh-mcp-manager.

O Apidog CLI também pode executar testes de regressão em pipelines usados pelos dois agentes. Veja a configuração em usando o Apidog CLI no DeepSeek Harness.

O Que É DeepSeek Harness (dsh)? O Concorrente de Código Aberto do Claude, Explicado

Lucas — Thu, 20 Aug 2026 04:32:36 +0000

DeepSeek lançou algo incomum em 13 de agosto de 2026: não um modelo, mas a máquina que o executa. O DeepSeek Harness (dsh) é o orquestrador oficial de código aberto da empresa para agentes de codificação. Ele fornece loop de sessão, execução de ferramentas, aprovações de permissão e uma interface web local. Foi lançado no mesmo dia que o DeepSeek V4-Pro na API, e a VentureBeat o enquadrou como um rival open source do Claude Code.

Experimente o Apidog hoje

A comunidade reagiu rapidamente. Em 20 de agosto, o repositório deepseek-harness tinha aproximadamente 169.000 estrelas e 18.100 forks, uma semana após o lançamento. Esses números mostram o interesse em orquestradores que desenvolvedores possam inspecionar, modificar e conectar a diferentes modelos.

O que é o DeepSeek Harness

Um orquestrador é a camada ao redor do modelo.

Enquanto o modelo prevê tokens, o orquestrador define:

qual contexto o modelo recebe;
quais ferramentas ele pode chamar;
como comandos de shell e alterações de arquivos são aprovados;
como sessões com múltiplas etapas são mantidas;
como ferramentas, permissões e histórico são registrados.

Claude Code, Codex CLI e Gemini CLI também são orquestradores. Para comparar Claude Code e Codex CLI, consulte Claude Code vs Codex CLI.

O DeepSeek Harness entra nessa categoria com três características importantes:

É oficial: é um projeto da DeepSeek AI, não um wrapper comunitário da API.
É open source: usa licença MIT e documenta dependências de terceiros no arquivo THIRD_PARTY_NOTICES.
É uma prévia para desenvolvedores: o README avisa que haverá mudanças que quebrarão compatibilidade. Trate versões e plugins como componentes experimentais.

O dsh foi lançado junto com o DeepSeek V4-Pro. Se você também estiver avaliando o modelo, veja o guia da API DeepSeek V4-Pro, com endpoints, IDs de modelo e exemplos de requisição.

Arquitetura: tudo é plugin

A principal diferença do dsh é sua arquitetura baseada em plugins.

Em muitos agentes de código, o loop do agente, o cliente do modelo, as ferramentas e o armazenamento de sessão fazem parte de uma única aplicação. Você pode ajustar configurações, mas normalmente não substitui componentes centrais.

No DeepSeek Harness, esses componentes são módulos substituíveis, construídos sobre o framework Cordis. Na prática, isso permite trocar partes importantes do agente:

Adaptador de modelo: define como o dsh conversa com uma API de LLM.
Registro de ferramentas: define ferramentas como edição de arquivos, shell e busca.
Log de sessão: controla como sessões são registradas e reproduzidas.
Loop do agente: o ciclo de decidir, agir e observar também pode ser substituído.

Isso é útil quando sua equipe precisa experimentar:

diferentes modelos para tarefas específicas;
políticas de aprovação mais restritivas;
ferramentas exclusivas por repositório;
estratégias de contexto e memória;
endpoints locais ou gateways internos.

A contrapartida é clara: quanto mais componentes trocáveis, maior a superfície para incompatibilidades. Como o projeto ainda é uma prévia, atualizações podem quebrar plugins e configurações existentes.

Início rápido: execute o primeiro agente

Para iniciar a interface web local:

npx @deepseek-ai/dsh web

O comando inicia a UI em:

http://127.0.0.1:3080

Por padrão, o navegador é aberto automaticamente. Para impedir isso:

npx @deepseek-ai/dsh web --no-open

Se preferir executar a partir do código-fonte:

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

Configure a primeira sessão

Depois de abrir a UI, siga este fluxo:

Configure a chave da API DeepSeek

Adicione a chave nas configurações. As credenciais são armazenadas em:

   $DSH_HOME/.credentials.yaml

O arquivo principal de configuração mantém apenas referências às credenciais.

Selecione um espaço de trabalho

Clique em “Escolher espaço de trabalho” e selecione o diretório do projeto.

Essa etapa é obrigatória: o compositor de sessão permanece indisponível até que exista um workspace selecionado. O dsh exige uma definição explícita dos arquivos que poderá analisar e modificar.

Execute uma tarefa e revise as aprovações

Operações sujeitas à política de permissão ativa, como escrita em arquivos e comandos de shell, aparecem como solicitações de aprovação.

Um exemplo de tarefa inicial:

Analise este repositório, identifique os testes que falham e proponha uma correção mínima. Não altere arquivos sem pedir aprovação.

Use perfis e modo headless

A UI web é apenas um perfil do dsh.

Este comando:

dsh web

é equivalente a:

dsh --profile web

Os perfis ficam em:

$DSH_HOME/profiles/<nome>

Para automações, scripts ou CI, use o modo headless:

dsh --profile headless "Analise os testes falhos e descreva a causa"

Esse modo inicia uma sessão, imprime o resultado e encerra o processo.

Outros comandos úteis:

# Gerencia plugins do perfil atual
dsh plugin

# Exibe a configuração final composta
dsh --dump-config

# Exibe a configuração padrão
dsh --dump-default-config

Consulte a lista completa no README do CLI.

Quais modelos o `dsh` pode executar?

Os modelos DeepSeek são o padrão, e o V4-Pro é o principal emparelhamento inicial.

A DeepSeek tornou permanente seu desconto fora de pico, o que pode afetar o custo de agentes que consomem tokens continuamente. Veja os detalhes no post sobre o corte de preço permanente do DeepSeek V4-Pro e na documentação oficial em api-docs.deepseek.com.

Como o adaptador de modelo é um plugin, você também pode usar outros provedores.

Provedores de catálogo

O dsh inclui configurações para:

Anthropic;
OpenAI;
Amazon Bedrock;
Google Vertex;
Azure.

Cada provedor possui tratamento próprio de credenciais.

Provedores personalizados

Você pode registrar endpoints compatíveis com OpenAI em:

$DSH_HOME/settings.yaml

A configuração inclui:

URL base;
variável de ambiente da chave;
lista de modelos disponíveis.

Isso cobre APIs em nuvem, gateways internos e runtimes locais compatíveis.

Cada sessão registra o modelo usado no início. Portanto, trocar o modelo padrão não altera o histórico das sessões anteriores.

Veja o formato de configuração no guia de provedores. Para um passo a passo completo com YAML para endpoints personalizados, consulte como executar qualquer modelo no DeepSeek Harness.

Ecossistema de plugins

Os plugins são descobertos pelo tópico dsh-plugin no GitHub. A comunidade também se organiza via GitHub Discussions e Discord.

Uma semana após o lançamento, já havia alguns tipos de extensão:

Wrappers desktop: projetos como deepseek-harness-desktop com Tauri e dsh_desktop para Windows empacotam a UI web em aplicativos nativos.
Plugins de capacidade: projetos como dsh-context e dsh-vision-router ampliam o contexto ou o roteamento de sessões.
Integração com MCP: o core do dsh não oferece suporte nativo ao Model Context Protocol até o momento, mas o plugin comunitário dsh-mcp-manager adiciona suporte.

Ao usar plugins comunitários, aplique o mesmo cuidado que aplicaria a qualquer dependência de terceiros, especialmente se ela acessar chaves de API, arquivos locais ou comandos de shell.

Como funciona o MCP via plugin

O dsh-mcp-manager permite configurar:

servidores MCP HTTP remotos;
servidores MCP locais via stdio;
OAuth ou token estático;
ferramentas com nomes no formato:

mcp__<nome>__*

configurações por projeto no diretório:

.dsh

do workspace.

A distinção é importante: o DeepSeek Harness não possui MCP nativo no core neste momento. O suporte atual é fornecido pela comunidade via plugin.

Onde seu fluxo de trabalho de API se encaixa

Um agente de código depende de duas categorias de API:

a API do modelo que ele chama;
as APIs do projeto que ele precisa implementar, testar ou integrar.

Se a especificação da sua API estiver desatualizada, o agente pode gerar código contra um contrato incorreto. O problema só aparece em runtime, quando o endpoint, payload ou resposta real diverge da implementação.

Antes de pedir alterações ao agente, valide a superfície da API:

importe ou defina a especificação OpenAPI;
teste os endpoints reais contra a especificação;
crie mocks para respostas estáveis;
use essa especificação como fonte de verdade para o desenvolvimento.

O Apidog ajuda nessa camada: você pode importar especificações OpenAPI, testar endpoints e criar servidores mock. Isso reduz o risco de o agente implementar integrações com base em código ou documentação obsoletos.

Também existe um caminho via MCP. O Apidog MCP Server expõe especificações de API a ferramentas de IA por meio do Model Context Protocol.

No dsh, o fluxo depende do plugin comunitário dsh-mcp-manager:

instale o plugin;
registre o Apidog MCP Server;
permita que a sessão consulte a especificação real;
use a especificação para implementar e validar integrações.

Para combinar testes de API baseados em CLI com o agente, veja usando Apidog CLI no DeepSeek Harness. Se quiser preparar a API antes de experimentar, baixe o Apidog e importe sua especificação.

Devo testar agora ou esperar?

A resposta depende do seu caso de uso.

Teste agora se você:

quer estudar como orquestradores de agentes funcionam internamente;
precisa alternar modelos ou usar modelos auto-hospedados;
quer construir plugins para ferramentas, contexto ou permissões;
já usa a API DeepSeek e quer testar a experiência de agente oficial com o V4-Pro.

Espere se você:

precisa de uma ferramenta diária estável;
depende de compatibilidade entre versões;
trabalha em uma organização que exige ferramentas oficialmente suportadas;
não quer revisar plugins comunitários que podem lidar com credenciais;
precisa do polimento de orquestradores mais maduros.

Uma abordagem pragmática é manter seu agente atual em fluxos de produção e testar o dsh em um projeto paralelo. Para uma comparação direta, consulte DeepSeek Harness vs Claude Code.

FAQ

DeepSeek Harness é gratuito?

O orquestrador é gratuito e open source sob licença MIT.

O custo depende do modelo configurado. Se você usar a API da DeepSeek ou outro provedor em nuvem, o consumo será cobrado por esse provedor. Como o adaptador é plugável, você também pode configurar um modelo hospedado localmente e evitar custos por token. Veja executar qualquer modelo no DeepSeek Harness.

O `dsh` só funciona com modelos DeepSeek?

Não.

Os modelos DeepSeek são o padrão, mas o adaptador de modelo é um plugin. O dsh oferece provedores para Anthropic, OpenAI, Bedrock, Vertex e Azure, além de endpoints compatíveis com OpenAI configurados em:

$DSH_HOME/settings.yaml

É seguro executar o DeepSeek Harness na minha base de código?

A segurança depende da política de permissões e da sua revisão das operações aprovadas.

A UI exige a seleção de um workspace antes de iniciar sessões e solicita aprovação para operações que exigem permissão. Ainda assim, o projeto é uma prévia para desenvolvedores, e plugins comunitários podem acessar chaves de API ou recursos locais.

Revise os plugins instalados e evite usar a prévia em repositórios onde uma alteração incorreta possa causar impacto significativo.

Qual é a diferença entre um orquestrador e um modelo?

O modelo é o mecanismo de raciocínio que gera tokens.

O orquestrador é a camada que permite que esse modelo execute tarefas:

gerenciamento de sessão;
montagem de contexto;
acesso a arquivos;
chamadas de ferramentas;
execução de comandos;
solicitações de permissão;
registro de histórico.

Dois agentes podem usar o mesmo modelo e produzir resultados diferentes porque seus orquestradores usam ferramentas, permissões e contexto de formas diferentes.

Hospedagem própria do GLM-5.3: Prepare-se para a liberação dos pesos abertos

Lucas — Sun, 16 Aug 2026 15:39:47 +0000

A Zhipu AI lançou o GLM-5.3 em 14 de agosto de 2026. Para equipes de infraestrutura, a informação mais útil é o cronograma dos pesos abertos: a previsão é que cheguem cerca de duas semanas depois, por volta de 28 de agosto, na organização zai-org no Hugging Face. Use essa janela para preparar hardware, validar sua pilha de serving e criar uma linha de base com a API hospedada antes de baixar os safetensors.

Experimente o Apidog hoje

A preparação vale o esforço. Segundo relatórios de lançamento, a Zhipu posiciona o GLM-5.3 com ganho de 50% em coding sobre o GLM-5.2, aumento no Terminal-Bench 3.0 de 4.6 para 28.3 e desempenho de agente “aproximando-se do Claude Fable 5”. Veja os detalhes e limitações dos benchmarks no explicador do GLM-5.3.

Este guia responde a uma pergunta prática: o que deixar pronto para servir o GLM-5.3 localmente no dia em que os pesos forem publicados?

Os pesos ainda não estão disponíveis para download. As etapas abaixo são um plano de preparação baseado nas informações públicas e no padrão de releases anteriores da Zhipu.

TL;DR

A API do GLM-5.3 foi lançada em 14 de agosto de 2026. Os pesos abertos são esperados por volta de 28 de agosto em huggingface.co/zai-org.
A família GLM-5 usa Mixture of Experts (MoE): 744B de parâmetros totais, aproximadamente 40B ativos por token e contexto de 200K, conforme a documentação da Z.ai.
Em BF16, os pesos ocupam aproximadamente 1.5 TB. Em FP8, aproximadamente 744–745 GB, sem incluir cache KV.
O padrão esperado é um repositório BF16 e outro FP8, como GLM-5.3 e GLM-5.3-FP8.
Para o primeiro dia, priorize vLLM ou SGLang, ambos com endpoints compatíveis com OpenAI.
Capture respostas da API hospedada agora e execute a mesma coleção contra seu endpoint local depois. Faça isso com o Apidog: uma coleção, dois ambientes e asserções reproduzíveis.

O que será lançado e quando

A Zhipu, conhecida internacionalmente como Z.ai, associou o lançamento da API do GLM-5.3 à promessa de pesos abertos cerca de duas semanas depois. O destino esperado é a página zai-org no Hugging Face.

A empresa afirma que aplicou sua revisão de risco mais abrangente até agora. Isso é relevante considerando a pontuação de 84.5% no CyberGym, citada como ligeiramente acima de Claude Mythos 5 e GPT-5.6 Sol. O Seeking Alpha descreve o release como parte da disputa da Zhipu com a DeepSeek pela liderança em modelos abertos.

Para self-hosting, dois pontos importam:

A arquitetura base não mudou.

O GLM-5.3 usa a base do GLM-5 com pós-treinamento escalonado. Portanto, a infraestrutura que já atende GLM-5 ou GLM-5.2 deve ser o ponto de partida.
O formato de release já tem precedente.

A Zhipu publicou GLM-5, GLM-5.1 e GLM-5.2 com variantes BF16 e FP8. É razoável esperar o mesmo padrão para o GLM-5.3.

Antes de usar o modelo em produção ou em um produto comercial, leia a licença no card do modelo assim que o repositório for publicado.

Planeje o hardware: 744B totais não significa 40B de memória

A família GLM-5 é uma arquitetura MoE com:

744B de parâmetros totais;
aproximadamente 40B de parâmetros ativos por passagem;
contexto de até 200K;
números documentados pela Z.ai.

A implicação prática é simples:

Compute: se comporta mais próximo de um modelo denso de 40B, porque apenas parte dos especialistas é ativada por token.
Memória: se comporta como um modelo de 744B, porque todos os especialistas precisam estar disponíveis.

Estimativa apenas para os pesos:

Precisão	Tamanho estimado dos pesos	Ambiente realista
BF16	~1.5 TB	Cluster multi-nó ou servidor com muitas GPUs de alta capacidade
FP8 oficial	~745 GB	Servidor multi-GPU de ponta, possivelmente em nó único
INT4 da comunidade	~370–400 GB	Rig multi-GPU menor, sujeito a validação de qualidade

Esses valores não incluem o cache KV. Com contexto longo e múltiplas requisições simultâneas, o cache KV pode se tornar um custo relevante.

Decisão recomendada antes do lançamento

Defina um limite de contexto por ambiente. Por exemplo:

desenvolvimento: 32K
staging:        64K
produção:       64K ou 128K, após medir consumo de VRAM

Não exponha automaticamente os 200K de contexto apenas porque o modelo suporta esse limite. Primeiro meça:

VRAM disponível após carregar os pesos;
throughput com concorrência;
latência p50 e p95;
impacto do cache KV no maior contexto permitido.

Se você só tem uma GPU de consumidor, os pesos completos não são um alvo viável. Nesse cenário:

mantenha GLM-5.3 na API hospedada;
alugue GPUs para testes pontuais;
aguarde quantizações da comunidade;
use modelos menores localmente.

Veja alternativas no guia de melhores LLMs locais em 2026.

Escolha sua pilha de serving antes dos pesos chegarem

Evite descobrir incompatibilidades de CUDA, drivers ou paralelismo no dia do release. Instale e valide sua pilha agora.

Opção 1: vLLM

O vLLM é a escolha mais conservadora para o primeiro dia:

suporte já estabelecido para a família GLM-5;
paralelismo adequado para MoE;
API compatível com OpenAI;
integração simples com SDKs existentes.

Um comando inicial pode se parecer com este:

vllm serve zai-org/GLM-5.3-FP8 \
  --tensor-parallel-size 8 \
  --max-model-len 65536 \
  --served-model-name glm-5.3

Trate esse comando como modelo, não como configuração final:

--tensor-parallel-size depende da quantidade e da memória das GPUs;
--max-model-len deve respeitar seu orçamento de cache KV;
o nome do repositório precisa ser confirmado quando os pesos forem publicados.

Opção 2: SGLang

O SGLang é especialmente interessante se suas cargas de trabalho reutilizam prompts longos, como agentes com instruções, ferramentas e contexto compartilhado.

Pontos fortes:

bom suporte para serving de MoE;
cache de prefixo em árvore radix;
endpoint compatível com OpenAI.

Se você alternar entre vLLM e SGLang, seu cliente pode continuar igual se ambos expuserem o mesmo contrato OpenAI-compatible.

Opção 3: llama.cpp, Ollama e LM Studio

A família llama.cpp depende de conversões para GGUF. Em geral, essas conversões aparecem dias ou semanas depois do release oficial de safetensors.

Use esse caminho apenas quando:

existirem quantizações confiáveis;
você tiver validado a qualidade contra sua linha de base;
o perfil de hardware justificar a perda potencial de qualidade ou throughput.

Crie uma linha de base com a API hospedada

Antes de servir o modelo localmente, registre como a implementação hospedada responde aos prompts importantes para seu produto.

A API hospedada deve ser sua referência para responder perguntas como:

a quantização reduziu a qualidade?
o servidor local está aplicando o template de chat corretamente?
o problema está na configuração do framework?
a diferença é apenas variância de geração?

A API é compatível com OpenAI:

Internacional:
https://api.z.ai/api/paas/v4/chat/completions

China continental:
https://open.bigmodel.cn/api/paas/v4/chat/completions

Use autenticação Bearer:

Authorization: Bearer <key>

A documentação da Z.ai lista glm-5 atualmente. Confirme o identificador exato de glm-5.3 na documentação oficial antes de automatizar suas requisições.

Para um passo a passo completo de configuração, consulte o guia rápido da API GLM-5.3.

Capture respostas determinísticas o máximo possível

Use temperatura 0 e prompts fixos:

curl https://api.z.ai/api/paas/v4/chat/completions \
  -H "Authorization: Bearer $GLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "temperature": 0,
    "messages": [
      {
        "role": "user",
        "content": "Write a Python function that parses RFC 3339 timestamps and returns UTC datetimes. Include error handling for invalid input."
      }
    ]
  }' > baseline-rfc3339.json

Crie entre 20 e 50 casos cobrindo seus fluxos reais:

geração e revisão de código;
chamadas de ferramenta;
extração estruturada;
respostas JSON;
sumarização de contexto longo;
fluxos de agente;
prompts multilíngues, se aplicável.

Temperatura 0 não elimina completamente a variância, mas reduz a dispersão o suficiente para detectar regressões relevantes.

Monte um harness de regressão no Apidog

Scripts curl funcionam para um teste manual, mas não escalam para múltiplos endpoints, quantizações e membros da equipe. Estruture a comparação como um teste de API.

O Apidog permite organizar essa validação em uma coleção reutilizável. Para fundamentos de testes de API, veja também o guia para engenheiros de QA.

Configuração recomendada

Crie uma coleção de baseline.

Cada prompt deve ser uma requisição para chat/completions.
Crie dois ambientes: hosted e local.

Exemplo de variáveis:

   hosted
   base_url=https://api.z.ai/api/paas/v4
   api_key=<sua-chave-Z.ai>

   local
   base_url=http://localhost:8000/v1
   api_key=local-serving

Use variáveis em todas as requisições.

   POST {{base_url}}/chat/completions
   Authorization: Bearer {{api_key}}
   Content-Type: application/json

Adicione asserções estruturais.

Comece validando contrato, não texto exato:

status HTTP 200;
choices[0].message.content não vazio;
objeto usage presente;
resposta JSON válida;
presença de tool calls quando o prompt exige ferramentas.

Adicione verificações semânticas simples para código.

Exemplo de critérios robustos:

   resposta contém "def "
   resposta contém "datetime"
   resposta contém "try"

Evite comparar uma resposta inteira byte a byte. Mesmo com temperatura zero, isso pode gerar falsos negativos.

Salve as respostas hospedadas como exemplos.

Elas serão seus fixtures de referência.
Execute a coleção pela CLI.

Assim, a validação pode entrar em scripts, pipelines de CI e testes de cada mudança de quantização ou configuração de serving.

O resultado desejado é simples: um comando que responda, por caso de teste, se a implantação local continua dentro do comportamento esperado.

Mantenha o código cliente igual

Como a API hospedada e os servidores locais usam a convenção OpenAI-compatible, a aplicação não precisa ser reescrita. Troque apenas a base_url.

import os
from openai import OpenAI

# Hospedado:
# GLM_BASE_URL=https://api.z.ai/api/paas/v4

# Local:
# GLM_BASE_URL=http://localhost:8000/v1

client = OpenAI(
    base_url=os.environ["GLM_BASE_URL"],
    api_key=os.environ.get("GLM_API_KEY", "local-serving"),
)

response = client.chat.completions.create(
    model="glm-5.3",
    temperature=0,
    messages=[
        {
            "role": "user",
            "content": "Refactor this function to remove the nested loops: ..."
        }
    ],
)

print(response.choices[0].message.content)

Ao iniciar vLLM ou SGLang, mantenha o nome servido consistente:

--served-model-name glm-5.3

Isso evita condicionais no código da aplicação.

Teste separadamente:

streaming;
chamadas de ferramentas;
JSON mode;
respostas estruturadas;
mensagens longas;
concorrência.

Esses são os pontos onde uma pilha local pode divergir mais da API hospedada.

Compare custo de API e GPUs próprias

A Zhipu não havia publicado um preço específico para a API 5.3 no lançamento. Consulte a página oficial de preços antes de fazer projeções.

A comparação é estrutural:

Cenário	Tendência
Baixa utilização ou uso irregular	API hospedada tende a ser mais econômica
Avaliação e experimentação	Aluguel de GPU tende a ser melhor que compra
Alto volume sustentado	Self-hosting pode fazer sentido
Requisitos de residência de dados	Self-hosting pode ser necessário
Controle rígido de latência e disponibilidade	Self-hosting pode ser justificável

Self-hosting de um MoE de 744B significa pagar por capacidade de GPU mesmo quando não há tokens sendo processados. Isso só compensa quando você tem utilização sustentada, requisitos de governança ou necessidades operacionais que a API compartilhada não atende.

Também existe um benefício estratégico: pesos abertos reduzem dependência de preço. Mudanças de tarifa podem afetar a economia unitária de uma aplicação, como discutido na análise sobre o aumento de preços da API DeepSeek.

Checklist para o dia do lançamento

Faça os itens 1 a 6 antes de 28 de agosto.

Defina sua precisão alvo: BF16, FP8 ou quantização futura.
Verifique se seu hardware suporta os pesos e o cache KV esperado.
Instale vLLM ou SGLang.
Faça um teste seco com GLM-5.2 ou outro MoE público.
Crie uma chave da Z.ai e confirme o ID do modelo na documentação ativa.
Capture 20 a 50 respostas da API hospedada com temperatura 0.
Crie uma coleção no Apidog com os ambientes hosted e local.
Defina o contexto máximo por ambiente.
No lançamento, monitore huggingface.co/zai-org pelos repositórios GLM-5.3 e GLM-5.3-FP8.
Leia a licença no card do modelo antes de uso comercial.
Baixe os pesos e inicie seu servidor local.
Aponte o ambiente local para o endpoint vLLM ou SGLang.
Execute a coleção de regressão.
Investigue falhas de conteúdo antes de liberar tráfego.
Só depois ajuste quantização, paralelismo, cache de prefixo e limite de contexto.

FAQ

Posso baixar os pesos do GLM-5.3 agora?

Não. Em 14 de agosto de 2026, apenas a API hospedada está ativa. A previsão é que os pesos abertos sejam publicados cerca de duas semanas depois, por volta de 28 de agosto, na página zai-org do Hugging Face.

O GLM-5.3 roda em uma única GPU de consumidor?

Não com os pesos completos. Os 744B de parâmetros da família correspondem a aproximadamente 744 GB em FP8 antes do cache KV. Mesmo quantizações INT4 permanecem no território multi-GPU.

Para uma única GPU, prefira modelos menores locais e mantenha GLM-5.3 na API hospedada. Consulte o resumo de LLMs locais para opções compatíveis com esse perfil.

Qual framework devo usar?

Comece com vLLM se quiser o caminho mais previsível para o primeiro dia. Use SGLang se sua carga reutiliza prefixos longos, como em loops de agentes. Aguarde conversões GGUF para usar llama.cpp, Ollama ou LM Studio.

Meu código com o SDK OpenAI funcionará?

Sim, desde que seu servidor local exponha uma API compatível com OpenAI. Troque a base_url para o endpoint do vLLM ou SGLang e preserve o formato da requisição.

Teste explicitamente streaming e chamadas de ferramenta.

Por que criar uma baseline hospedada se vou usar self-hosting?

Porque ela é sua implementação de referência. Sem fixtures hospedados, você não saberá se uma resposta local ruim foi causada por:

quantização agressiva;
configuração incorreta;
bug no framework;
diferença de template;
comportamento normal do modelo.

Capture as respostas agora usando a configuração do guia rápido da API GLM-5.3.

Conclusão

O GLM-5.3 pode ser um dos lançamentos de pesos abertos mais relevantes do ano para coding e agentes. O diferencial na primeira semana não será apenas ter mais GPUs: será ter um processo de validação pronto.

Prepare agora:

uma pilha de serving testada;
uma decisão de precisão;
limites de contexto;
fixtures da API hospedada;
uma coleção de regressão com ambientes hosted e local.

Comece pela checklist e use o Apidog para manter a comparação reproduzível: uma coleção, dois ambientes e asserções que transformam “parece funcionar” em um relatório de aprovação ou reprovação.

O que é GLM-5.3? Entenda o Modelo Open-Weight de Programação da Zhipu

Lucas — Sun, 16 Aug 2026 15:34:52 +0000

GLM-5.3 é um grande modelo de linguagem lançado em 14 de agosto de 2026 pela Zhipu AI, laboratório chinês que opera internacionalmente como Z.ai. É uma atualização pós-treinamento do GLM-5 voltada para codificação e fluxos agênticos. A Zhipu planeja publicar os pesos abertos no Hugging Face cerca de duas semanas após o lançamento. Segundo avaliações internas da empresa, a capacidade de codificação melhorou 50% em relação ao GLM-5.2.

Experimente o Apidog hoje

O lançamento chama atenção porque a Zhipu — descrita pelo Seeking Alpha como uma “desafiante chinesa da OpenAI” — afirma que o modelo está “se aproximando do Claude Fable 5” em codificação e agentes, com pesos abertos previstos em seguida. Ele chegou um dia após o lançamento mais recente da DeepSeek, abordado no nosso guia da API DeepSeek V4 Pro.

Neste artigo, você verá o que muda no GLM-5.3, como interpretar os benchmarks, o plano de pesos abertos e como fazer sua primeira chamada à API. Você também pode testar a requisição no Apidog sem escrever código.

Resumo

GLM-5.3 foi lançado em 14 de agosto de 2026 pela Zhipu AI (Z.ai). Ele usa o mesmo modelo base GLM-5; os ganhos vêm do pós-treinamento escalonado.
No Terminal-Bench 3.0, a pontuação subiu de 4,6 para 28,3: um salto de 6,2x e primeiro lugar entre modelos de código aberto.
O modelo também ocupa o primeiro lugar entre modelos abertos no Agents’ Last Exam.
No CyberGym, alcançou 84,5%, ligeiramente acima de Claude Mythos 5 e GPT-5.6 Sol. No ExploitBench, marcou 54,4% e ainda ficou atrás dos modelos de ponta.
Os pesos abertos devem chegar ao Hugging Face por volta de 28 de agosto de 2026, após a revisão de risco da Zhipu.
A família GLM-5 usa arquitetura Mixture of Experts (MoE), com 744B de parâmetros totais, aproximadamente 40B ativos por passagem e janela de contexto de 200K tokens.
A API é compatível com OpenAI em https://api.z.ai/api/paas/v4/chat/completions. Nenhum preço específico da versão 5.3 foi publicado no lançamento.

O que é o GLM-5.3

GLM-5.3 é a terceira atualização pontual da família GLM-5 e a mais direcionada para desenvolvimento. A Zhipu não retreinou o modelo base. Segundo a documentação oficial, o GLM-5 mantém:

Arquitetura Mixture of Experts;
744B de parâmetros totais;
Cerca de 40B de parâmetros ativos por passagem;
Janela de contexto de 200K tokens.

As melhorias vêm do pós-treinamento escalonado aplicado aos mesmos pesos base. Na prática, isso indica que o principal avanço está no pipeline de alinhamento e treinamento posterior, não em uma nova arquitetura.

As cargas de trabalho alvo são específicas:

agentes orientados por terminal;
engenharia de software de longa duração;
tarefas de segurança;
automação de fluxos de desenvolvimento.

Se você precisa avaliar modelos para agentes de código, GLM-5.3 é uma opção a comparar com APIs fechadas e modelos abertos auto-hospedados assim que os pesos forem liberados.

Benchmarks do GLM-5.3: números e fontes

A cobertura de lançamento da BigGo Finance e da Pandaily relatou os resultados abaixo.

Atenção à fonte de cada métrica: alguns dados vêm de relatórios de lançamento e outros de avaliações internas da Zhipu. Resultados internos ainda precisam de reprodução independente.

Benchmark	Resultado GLM-5.3	Contexto	Fonte
Terminal-Bench 3.0	28,3, acima de 4,6	Salto de 6,2x; primeiro entre modelos de código aberto	Relatório de lançamento
Agents’ Last Exam	Primeiro entre modelos de código aberto	Pontuação não divulgada	Relatório de lançamento
CyberGym	84,5%	Ligeiramente acima de Claude Mythos 5 e GPT-5.6 Sol	Relatório de lançamento
ExploitBench	54,4%	Ainda atrás de modelos de ponta	Relatório de lançamento
SWE-Marathon	Aproximadamente 2x GLM-5.2	Engenharia de software de longo prazo	Interno da Zhipu
Capacidade de codificação agregada	+50% vs. GLM-5.2	Reivindicação principal da Zhipu	Interno da Zhipu

Como interpretar esses números

O salto no Terminal-Bench 3.0 é relevante. Esse tipo de benchmark avalia se o modelo consegue:

Executar comandos shell em sequência;
Ler e interpretar saídas;
Corrigir erros;
Continuar tarefas de várias etapas.

Sair de 4,6 para 28,3 muda o potencial do modelo para pipelines de agentes, CI e automação baseada em terminal.

Por outro lado, as alegações de ganho de 50% em codificação e de aproximadamente 2x no SWE-Marathon são avaliações internas. Elas não devem ser tratadas como resultados reproduzíveis até que os pesos sejam publicados e a comunidade execute as mesmas suítes.

O que “aproximando-se do Claude Fable 5” significa na prática

A Zhipu afirma que o GLM-5.3 está “se aproximando do Claude Fable 5” em codificação e comportamento agêntico. Essa formulação não significa equivalência geral.

O que os números sugerem:

Em tarefas de terminal e agentes, o GLM-5.3 parece competitivo.
O primeiro lugar entre modelos abertos no Terminal-Bench 3.0 e no Agents’ Last Exam é relevante para agentes de codificação.
No CyberGym, os 84,5% superam ligeiramente Claude Mythos 5 e GPT-5.6 Sol, embora pequenas diferenças possam variar entre execuções.
No ExploitBench, os 54,4% indicam que o modelo ainda fica atrás da fronteira em raciocínio mais profundo e desenvolvimento de exploits.

Para sua pilha, isso sugere um plano simples:

Teste o GLM-5.3 em agentes de terminal, automação de CI e tarefas de repositório.
Mantenha modelos fechados de ponta na comparação para tarefas de raciocínio difícil.
Use uma suíte própria antes de mover tráfego de produção.

Para comparar os modelos de ponta nesses eixos, consulte a comparação entre Grok 4.6, GPT-5.6 e Claude Fable 5.

Plano de pesos abertos: Hugging Face por volta de 28 de agosto

A Zhipu se comprometeu a publicar os pesos abertos do GLM-5.3 cerca de duas semanas após o lançamento. A previsão é por volta de 28 de agosto de 2026, na organização zai-org no Hugging Face.

O intervalo de duas semanas faz parte da revisão de risco anunciada pela empresa. Isso é especialmente relevante porque o resultado de 84,5% no CyberGym indica capacidade significativa em segurança ofensiva. Publicar pesos abertos é diferente de disponibilizar o modelo por uma API monitorada.

Planeje a execução local com realismo

A família GLM-5 tem 744B de parâmetros totais, mesmo que apenas cerca de 40B estejam ativos por token. Portanto:

Inferência em precisão total exige hardware de servidor e múltiplas GPUs.
A maioria das equipes provavelmente dependerá de variantes quantizadas da comunidade.
Vale construir uma linha de base contra a API hospedada antes de testar a implantação local.

Para se preparar, veja o guia de auto-hospedagem do GLM-5.3.

Como o GLM-5.3 se encaixa no cenário de modelos abertos

A comparação mais direta é com DeepSeek. Os dois laboratórios:

São chineses;
Publicam pesos abertos;
Oferecem APIs com preços competitivos;
Tiveram lançamentos separados por aproximadamente 24 horas.

A diferença está no foco. A linha V4 Pro da DeepSeek é apresentada como generalista, enquanto o GLM-5.3 é uma aposta especializada em agentes de codificação.

Se seu tráfego envolve principalmente desenvolvimento agêntico, comece a avaliação pelo GLM-5.3. Se você precisa de um modelo generalista, compare os dois com prompts e métricas representativos da sua aplicação.

A economia também importa. O aumento de preço da DeepSeek, discutido no guia de otimização de custos da API DeepSeek, mostra que preços de APIs podem mudar rapidamente. Pesos abertos oferecem uma alternativa de auto-hospedagem para equipes que precisam reduzir dependência de provedores.

No lançamento, a Zhipu não havia publicado preço específico para o GLM-5.3. Como referência, a página oficial de preços listava o GLM-5.2 a US$ 1,4 por 1M de tokens de entrada e US$ 4,4 por 1M de tokens de saída.

Quando variantes quantizadas estiverem disponíveis, o GLM-5.3 poderá entrar no conjunto de modelos executáveis sem dependência de API. Veja também a lista dos melhores LLMs locais em 2026.

Cotas do Plano de Codificação GLM foram redefinidas

Em 14 de agosto, a Zhipu redefiniu as cotas do Plano de Codificação GLM para todos os usuários. Se você assina o plano pelo Z.ai, seu limite foi renovado no dia do lançamento.

O Plano de Codificação é diferente do acesso à API por token:

O plano é uma oferta de tarifa fixa para ferramentas de codificação;
A redefinição se aplica ao plano, não à cobrança da API;
Usuários da China Continental acessam o ecossistema pelo open.bigmodel.cn, com planos e faturamento próprios.

Experimente a API em cinco minutos

A API do Z.ai é compatível com OpenAI. Se você já usa uma API de LLM, o formato será familiar.

Endpoint internacional:

https://api.z.ai/api/paas/v4/chat/completions

Endpoint para China Continental:

https://open.bigmodel.cn/api/paas/v4/chat/completions

A autenticação usa Bearer Token. No lançamento, a documentação ainda listava glm-5 como ID documentado. O exemplo abaixo usa glm-5.3 seguindo a convenção da família, mas confirme o ID na documentação do modelo antes de implantar.

export GLM_API_KEY="your-key-from-z.ai"

curl https://api.z.ai/api/paas/v4/chat/completions \
  -H "Authorization: Bearer $GLM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "messages": [
      {
        "role": "user",
        "content": "Escreva um script bash que encontre os cinco maiores arquivos em um repositório git, excluindo o diretório .git."
      }
    ],
    "temperature": 0.6,
    "max_tokens": 1024
  }'

A resposta segue o esquema da OpenAI:

choices: array com a resposta do modelo;
choices[0].message.content: conteúdo gerado;
usage: contagem de tokens de entrada e saída.

Organize testes no Apidog

Em vez de editar comandos cURL manualmente, importe a requisição para o Apidog e configure:

Uma variável de ambiente chamada GLM_API_KEY;
Um ambiente para api.z.ai;
Um ambiente para open.bigmodel.cn;
Variáveis para IDs de modelo;
Respostas salvas como linha de base para testes de regressão.

Assim, você pode trocar região, endpoint ou modelo por um menu, sem alterar a requisição manualmente.

Para exemplos em Python e Node.js, streaming e tratamento de erros, consulte o guia de início rápido completo da API GLM-5.3.

FAQ

O GLM-5.3 é de código aberto?

Ainda não, mas terá pesos abertos. A Zhipu planeja liberar os pesos no Hugging Face por volta de 28 de agosto de 2026, após uma revisão de risco que a empresa descreve como a mais extensa até o momento. Até lá, o acesso é feito pela API hospedada.

Como o GLM-5.3 é diferente do GLM-5.2?

O modelo base é o mesmo. As melhorias vêm do pós-treinamento escalonado. A Zhipu relata:

+50% em capacidade de codificação em avaliações internas;
Terminal-Bench 3.0 de 4,6 para 28,3;
Aproximadamente o dobro da pontuação no SWE-Marathon.

Arquitetura, janela de contexto e contagem de parâmetros permanecem inalteradas.

Qual é o custo do GLM-5.3?

A Zhipu não publicou um preço específico para a versão 5.3 no lançamento. A melhor referência disponível era o GLM-5.2, listado a US$ 1,4 por 1M de tokens de entrada e US$ 4,4 por 1M de tokens de saída.

Antes de definir orçamento, confira a página de preços atualizada. Para reduzir custo por token, veja o guia de otimização de custos após o aumento de preço da API DeepSeek.

Posso executar o GLM-5.3 no meu próprio hardware?

Depois da liberação dos pesos, sim, com ressalvas. A família GLM-5 usa 744B de parâmetros totais e cerca de 40B ativos por passagem. A execução em precisão total exige hardware de servidor multi-GPU.

Variantes quantizadas da comunidade devem reduzir os requisitos. Veja o guia de preparação para auto-hospedagem para dimensionamento mais realista.

O GLM-5.3 é melhor que Claude ou GPT para codificação?

Nos benchmarks de agentes e terminal relatados, ele é competitivo. Ficou em primeiro entre modelos abertos no Terminal-Bench 3.0 e superou Claude Mythos 5 e GPT-5.6 Sol no CyberGym.

No ExploitBench, porém, marcou 54,4% e ficou atrás dos modelos de ponta. A decisão depende da sua carga de trabalho. Execute uma suíte própria antes de mover tráfego de produção, como faria ao testar qualquer API antes da adoção.

Onde o GLM-5.3 se encaixa na sua pilha

GLM-5.3 é um lançamento especializado para agentes de codificação: desempenho forte em tarefas de terminal, pesos abertos previstos em duas semanas e uma API compatível com OpenAI que você pode testar imediatamente.

A leitura prática é:

Use a API para criar uma linha de base hoje;
Monte uma pequena suíte de prompts baseada nas suas tarefas reais;
Compare resultados com seus modelos atuais;
Reavalie quando os pesos abertos e variantes quantizadas estiverem disponíveis;
Só então considere mover tráfego de produção.

Comece enviando a requisição cURL deste artigo e salve o resultado. Você pode baixar o Apidog para organizar a suíte, manter os endpoints do Z.ai e do bigmodel.cn em ambientes alternáveis e transformar testes exploratórios em uma base de regressão para comparar a API hospedada com sua futura implantação local.

Gemini 3.7 Flash: Preços Explicados – Garanta Suas Taxas Antes Que Dobrem

Lucas — Fri, 14 Aug 2026 07:59:26 +0000

O Google lançou o Gemini 3.7 Flash em 13 de agosto de 2026, três semanas após o 3.6 Flash, e o descreve como “nosso modelo mais inteligente para tarefas pesadas”. Para planejar custos de API, o dado decisivo não está nos benchmarks: a taxa introdutória de US$ 0,75 por 1 milhão de tokens de entrada e US$ 3,75 por 1 milhão de tokens de saída expira em 31 de dezembro de 2026. Em 1º de janeiro de 2027, ambas dobram.

Experimente o Apidog hoje

Isso cria um aumento programado de 2x para qualquer carga de trabalho construída com o modelo. Um chatbot que custa US$ 790 por mês agora passa a custar aproximadamente US$ 1.575 por mês em janeiro, sem mudanças no código, tráfego ou prompts.

Este guia mostra como calcular os dois níveis de custo, estimar três cargas reais e reduzir gastos antes do reajuste. Se você ainda não fez a primeira chamada, consulte o guia de início rápido da API Gemini 3.7 Flash. Depois de começar a enviar requisições, o Apidog permite inspecionar os contadores de usageMetadata retornados pela API para validar estimativas com tráfego real.

TL;DR

Até 31 de dezembro de 2026: US$ 0,75 por 1M de tokens de entrada e US$ 3,75 por 1M de tokens de saída.
A partir de 1º de janeiro de 2027: US$ 1,50 para entrada e US$ 7,50 para saída — exatamente 2x.
O preço introdutório é metade do custo de lançamento do Gemini 3.6 Flash.
O modelo aceita texto, imagem, vídeo, áudio e PDF, com janela de contexto de 1 milhão de tokens e saída máxima de 64 mil tokens.
Um chatbot com 10.000 requisições diárias custa cerca de US$ 26,25/dia agora e US$ 52,50/dia após o reajuste.
As principais alavancas de economia são: limitar saída, usar cache de contexto, processar jobs em lote e rotear tarefas simples para modelos menores.

Os dois níveis de preço

O Gemini 3.7 Flash foi lançado com desconto temporário, não com preço permanente.

Nível	Período	Entrada por 1M de tokens	Saída por 1M de tokens
Introdutório	13 de agosto de 2026 a 31 de dezembro de 2026	US$ 0,75	US$ 3,75
Padrão	A partir de 1º de janeiro de 2027	US$ 1,50	US$ 7,50

Duas observações importam para implementação:

O custo dobra em janeiro. Projete orçamento e alertas usando os dois valores, não apenas a taxa atual.
Tokens de saída custam 5x mais que tokens de entrada. Limitar respostas longas geralmente economiza mais do que reduzir pequenos trechos do prompt.

As taxas acima se aplicam à API Gemini faturada com chave do AI Studio. O Vertex AI usa faturamento do Google Cloud, SKUs próprios e itens separados para recursos como cache de contexto e processamento em lote. Antes de fechar um orçamento, confirme os valores na página oficial de preços.

Como calcular o custo por endpoint

Use esta fórmula para estimar o custo de uma requisição:

custo =
  (tokens_entrada / 1_000_000 × preco_entrada) +
  (tokens_saida / 1_000_000 × preco_saida)

Para estimar o custo diário:

custo_diario = custo_por_requisicao × requisicoes_por_dia

E para projetar o mês:

custo_mensal = custo_diario × 30

Calcule sempre com a taxa introdutória e com a taxa padrão.

Carga de trabalho 1: chatbot de suporte

Considere:

10.000 solicitações por dia
2.000 tokens de entrada por solicitação
300 tokens de saída por solicitação

Item	Tokens diários	Custo introdutório/dia	Custo padrão/dia
Entrada	20M	US$ 15,00	US$ 30,00
Saída	3M	US$ 11,25	US$ 22,50
Total	23M	US$ 26,25	US$ 52,50

Em 30 dias:

Taxa introdutória: aproximadamente US$ 788/mês
Taxa padrão: aproximadamente US$ 1.575/mês

Ação recomendada

Defina um teto de saída específico para respostas de suporte:

{
  "generationConfig": {
    "maxOutputTokens": 500
  }
}

Uma resposta de atendimento raramente precisa de milhares de tokens. Como a saída é 5x mais cara, esse limite reduz o risco de uma geração longa aumentar a conta.

Carga de trabalho 2: pipeline de documentos PDF

O Gemini 3.7 Flash lê PDFs nativamente. O benchmark GDP.pdf passou de 22,0% no 3.6 Flash para 34,0% no 3.7 Flash, tornando extração e sumarização de documentos uma carga de trabalho relevante.

Considere:

500 documentos por dia
40.000 tokens de entrada por documento
1.000 tokens de saída por resumo estruturado

Item	Tokens diários	Custo introdutório/dia	Custo padrão/dia
Entrada	20M	US$ 15,00	US$ 30,00
Saída	0,5M	US$ 1,88	US$ 3,75
Total	20,5M	US$ 16,88	US$ 33,75

Em 30 dias:

Taxa introdutória: cerca de US$ 506/mês
Taxa padrão: cerca de US$ 1.013/mês

Nesse perfil, a entrada domina o custo porque os documentos são longos e os resumos são curtos.

Ação recomendada

Para processamento que não exige resposta imediata:

agrupe documentos em jobs;
execute lotes em horários de menor demanda;
avalie processamento em lote;
use cache de contexto quando houver instruções ou documentos estáticos repetidos.

Carga de trabalho 3: loop de agente

Agentes multiplicam chamadas e acumulam contexto. Considere:

200 tarefas por dia;
12 chamadas de modelo por tarefa;
8.000 tokens de entrada por chamada;
400 tokens de saída por chamada.

Item	Tokens diários	Custo introdutório/dia	Custo padrão/dia
Entrada	19,2M	US$ 14,40	US$ 28,80
Saída	0,96M	US$ 3,60	US$ 7,20
Total	20,16M	US$ 18,00	US$ 36,00

Em 30 dias:

Taxa introdutória: US$ 540/mês
Taxa padrão: US$ 1.080/mês

O risco aqui é o crescimento do contexto. Se uma tarefa passa de 12 para 20 chamadas, o custo aumenta 67%, mesmo que o preço por token não mude.

O limite máximo de saída de 64 mil tokens define um teto teórico por chamada de aproximadamente:

US$ 0,24 na taxa introdutória;
US$ 0,48 na taxa padrão.

Esse teto evita custo ilimitado por requisição, mas loops de repetição com saídas máximas ainda ficam caros rapidamente.

Como o Gemini 3.7 Flash se compara

Comparações diretas de preço entre provedores envelhecem rapidamente. Use o posicionamento como referência, não como tabela permanente.

O Gemini 3.7 Flash se posiciona como modelo para tarefas pesadas com custo menor que modelos de ponta, incluindo a linha Gemini Pro, modelos maiores da Claude e o nível principal da OpenAI. Ao mesmo tempo, apresenta benchmarks como 65,3% no DeepSWE v1.1 e Elo de 1588 no WebDev Arena.

Para migrar do 3.6 Flash, use o guia de migração do Gemini 3.6 para o 3.7 Flash. O desconto introdutório, por si só, pode justificar o teste de regressão.

Mudanças de preço não são exclusivas do Gemini. A DeepSeek também reajustou sua API, levando equipes a rever seus orçamentos de tokens. Veja o guia de aumento de preços e otimização de custos da DeepSeek.

A implicação prática é simples:

um protótipo de US$ 3 vira US$ 6;
um pipeline de US$ 10.000/mês vira US$ 20.000/mês.

Meça antes de o reajuste entrar em vigor.

Cinco formas de reduzir gastos com tokens

1. Limite tokens de saída por endpoint

Defina maxOutputTokens de acordo com o objetivo da rota:

{
  "generationConfig": {
    "maxOutputTokens": 500
  }
}

Exemplos de limites práticos:

Endpoint	Limite inicial sugerido
Classificação	50–100 tokens
Resposta de suporte	Até 500 tokens
Resumo estruturado	500–1.500 tokens
Planejamento de agente	Conforme a complexidade da tarefa

Ajuste com base em respostas reais. O objetivo não é truncar conteúdo útil, mas impedir saídas descontroladas.

2. Armazene contexto estático em cache

Se cada requisição envia o mesmo prompt de sistema de 3.000 tokens, políticas e instruções, você paga repetidamente por conteúdo idêntico.

Use cache de contexto para conteúdo estático e verifique as regras e taxas atuais na documentação da API Gemini.

Para o chatbot do exemplo, armazenar em cache um prefixo estático de 1.500 tokens pode reduzir mais da metade do custo de entrada desse trecho repetido.

3. Use processamento em lote para jobs não interativos

Pipelines de documentos, classificações noturnas e tarefas de enriquecimento geralmente não precisam de resposta imediata.

A estratégia é:

enfileirar os jobs;
agrupar payloads;
executar processamento em lote;
aceitar maior latência em troca de custo reduzido.

4. Roteie cada tarefa para o modelo adequado

Nem toda requisição precisa do Gemini 3.7 Flash.

Use modelos menores para:

classificação;
roteamento;
extração curta;
normalização;
validação simples de formatos.

Reserve o 3.7 Flash para tarefas que usam sua capacidade: planejamento em múltiplas etapas, depuração, fluxos com ferramentas e contexto mais complexo.

5. Prototipe no nível gratuito

Use a cota gratuita do AI Studio para validar:

prompts;
schemas de saída;
limites de tokens;
comportamento em payloads representativos.

O guia de acesso gratuito à API Gemini explica até onde vai o caminho gratuito e onde estão seus limites.

Rastreie custo por endpoint com o Apidog

Estimativas definem o orçamento; medições por requisição evitam surpresas. As respostas do Gemini incluem usageMetadata, com contagens de tokens de entrada e saída.

Um exemplo de resposta pode conter campos como:

{
  "usageMetadata": {
    "promptTokenCount": 2000,
    "candidatesTokenCount": 300
  }
}

No Apidog, configure esse fluxo:

Salve uma requisição para cada endpoint de produção, como chat, resumo de documento e etapa de agente.
Armazene a chave em uma variável de ambiente:

   GEMINI_API_KEY

Execute cenários com payloads realistas.
Extraia:
- usageMetadata.promptTokenCount
- usageMetadata.candidatesTokenCount
Adicione asserções para impedir regressões de token.

Por exemplo, se seu endpoint de chat não deveria ultrapassar 2.500 tokens de entrada, trate isso como uma regra de teste. Uma mudança no prompt que ultrapasse o limite deve falhar antes do deploy.

O princípio é o mesmo de monitorar latência: tokens também sofrem regressão, mas a consequência aparece na fatura.

Multiplique as contagens medidas pelos dois níveis de preço deste artigo para obter custo por endpoint baseado em respostas reais. Para estruturar cenários de teste, consulte o guia de teste de API para engenheiros de QA.

FAQ

Quando o preço do Gemini 3.7 Flash dobra?

Em 1º de janeiro de 2027. A taxa introdutória de US$ 0,75 por 1 milhão de tokens de entrada e US$ 3,75 por 1 milhão de tokens de saída vale até 31 de dezembro de 2026. Depois, passa para US$ 1,50 e US$ 7,50.

O Gemini 3.7 Flash é mais barato que o Gemini 3.6 Flash?

No lançamento, sim. O preço introdutório do 3.7 Flash é metade do preço de lançamento do 3.6 Flash, enquanto o DeepSWE v1.1 passou de 49,0% para 65,3%. Para detalhes, consulte o guia de referência rápida do Gemini 3.7 Flash.

O preço introdutório se aplica ao Vertex AI?

As taxas deste artigo são da API Gemini faturada por chave do AI Studio. O Vertex AI usa faturamento do Google Cloud, SKUs próprios e termos empresariais. Confirme os valores no console de faturamento do GCP e na página oficial de preços.

O que conta como token de entrada?

Tudo o que você envia: texto, imagens, vídeo, áudio e páginas de PDF convertidos em tokens. Documentos longos e requisições com mídia são fontes comuns de surpresa no custo de entrada.

Após cada chamada, consulte usageMetadata para obter a contagem real.

Como estimar tokens antes de enviar a requisição?

Use o endpoint countTokens para medir o payload sem gerar uma resposta. Como alternativa, envie amostras representativas e leia usageMetadata.

Evite estimar apenas por intuição: tokenizadores variam entre famílias de modelos.

Onde o 3.7 Flash se encaixa na sua pilha

O Gemini 3.7 Flash combina capacidade de modelo para tarefas pesadas com uma janela de desconto cujo fim já está definido. A abordagem prática é:

mover para o 3.7 Flash as cargas que realmente precisam dessa capacidade;
medir tokens por endpoint durante o período introdutório;
projetar o custo com a taxa padrão;
limitar saída e contexto;
migrar rotas simples para modelos menores;
usar os dados coletados para planejar janeiro antes de a fatura chegar.

Baixe o Apidog para manter requisições Gemini, ambientes, asserções de token e verificações de custo no mesmo espaço de trabalho.

Novidades do Gemini 3.7 Flash: Recursos, Benchmarks e Acesso à API

Lucas — Fri, 14 Aug 2026 07:58:07 +0000

Gemini 3.7 Flash é o mais novo modelo de IA robusto do Google, lançado em 13 de agosto de 2026, três semanas após o Gemini 3.6 Flash. Ele mantém a janela de contexto de 1M de tokens e a entrada multimodal do predecessor, mas traz ganhos relevantes em benchmarks de codificação e agentes, com preço introdutório de API de US$ 0,75 por 1M de tokens de entrada. O Google o descreve como seu modelo de IA robusto mais inteligente.

Experimente o Apidog hoje

A cadência de lançamento é o ponto mais relevante: o Google entregou o 3.7 Flash apenas três semanas depois do 3.6 Flash, enquanto o Gemini 3.5 Pro permanece atrasado. Na prática, isso coloca as novidades de engenharia primeiro no modelo intermediário. Os benchmarks publicados indicam esse avanço: DeepSWE sobe 16 pontos, AutomationBench quase dobra e o preço introdutório é metade da taxa de lançamento do 3.6 Flash.

Este guia reúne as mudanças, benchmarks, períodos de preço, opções de acesso e uma chamada cURL para testar o modelo. Para aprofundar a implementação, consulte o guia rápido da API Gemini 3.7 Flash. Você também pode usar o Apidog para executar seus prompts atuais contra os dois modelos antes de migrar.

Resumo

Lançado em 13 de agosto de 2026, três semanas após o 3.6 Flash.
ID do modelo: gemini-3.7-flash.
Benchmarks de código e agentes melhoraram:
- DeepSWE v1.1: de 49,0% para 65,3%.
- AutomationBench: de 17,0% para 30,4%.
- WebDev Arena: de 1538 para 1588 Elo.
Preço introdutório: US$ 0,75 por 1M de tokens de entrada e US$ 3,75 por 1M de tokens de saída.
Preço padrão a partir de 1º de janeiro de 2027: US$ 1,50 de entrada e US$ 7,50 de saída por 1M de tokens.
Contexto de entrada de 1M de tokens, saída de até 64k tokens e entrada multimodal.
Disponível na API Gemini, AI Studio, aplicativo Gemini, Gemini Spark, Google Antigravity, Android Studio e Gemini Enterprise, em mais de 160 países.

O que é o Gemini 3.7 Flash

Flash é o nível intermediário da linha Gemini: mais barato e rápido que o Pro, mais capaz que o Flash-Lite e voltado a cargas de trabalho de alto volume em produção. O Gemini 3.7 Flash é o terceiro lançamento Flash da linha 3.x.

O anúncio oficial do Google posiciona o modelo principalmente para codificação e fluxos agênticos, não apenas para chat.

As especificações permanecem iguais às do 3.6 Flash:

Contexto: 1M de tokens de entrada e até 64k tokens de saída.
Entrada multimodal: texto, imagem, vídeo, áudio e PDF.
Saída: texto.
Ferramentas: chamada de função, pesquisa como ferramenta e uso de computador.
Segurança: salvaguardas CBRN e cibernéticas atualizadas.

A mudança principal está no comportamento. O Google afirma que o 3.7 Flash depura melhor, gera código implementável com mais frequência, lida melhor com obstáculos, pede esclarecimentos em solicitações ambíguas e segue instruções com maior fidelidade.

Melhorias nos benchmarks: 3.6 vs. 3.7

Benchmark	Gemini 3.6 Flash	Gemini 3.7 Flash	Mudança
DeepSWE v1.1 (codificação agêntica)	49,0%	65,3%	+16,3 pts
FrontierCode 1.1 Main	34,4%	43,6%	+9,2 pts
WebDev Arena (Elo)	1538	1588	+50 Elo
GDP.pdf (raciocínio de documentos)	22,0%	34,0%	+12,0 pts
AutomationBench (tarefas de agente)	17,0%	30,4%	+13,4 pts

Outras métricas divulgadas:

90,7% no Harvey LAB-AA, benchmark de raciocínio jurídico.
97,0% na recuperação de contexto longo com 128k agulhas.

Os maiores ganhos aparecem em tarefas de várias etapas. Para workloads com ferramentas, repositórios, documentos extensos ou fluxos que exigem planejamento, o salto no AutomationBench e no DeepSWE é mais relevante do que uma melhoria isolada em respostas de chat.

A cobertura do lançamento destacou o resultado do DeepSWE. Para comparar como diferenças de benchmark afetam tarefas reais entre modelos concorrentes, consulte a comparação entre Grok 4.6, GPT 5.6 e Claude.

O que testar em codificação e agentes

Em vez de migrar diretamente, valide os pontos que o Google destaca com um conjunto de regressão próprio.

1. Depuração em múltiplos arquivos

Use bugs reais ou reproduções mínimas do seu repositório. Avalie se o modelo encontra a causa raiz, não apenas um workaround.

Você está analisando um bug em um serviço Python.

Arquivos relevantes:
- api/routes/users.py
- services/user_service.py
- repositories/user_repository.py

Sintoma:
POST /users retorna 500 apenas quando o e-mail já existe.

Identifique a causa raiz, indique o arquivo e a linha provável,
e proponha um patch mínimo com testes.

O ganho no DeepSWE é a métrica mais próxima para esse tipo de tarefa.

2. Código executável na primeira resposta

Peça uma implementação com contrato explícito: linguagem, dependências permitidas, formato de saída e testes.

Implemente uma função TypeScript `groupByStatus`.

Restrições:
- Não usar bibliotecas externas.
- Não mutar o array de entrada.
- Retornar Record<string, Item[]>.
- Inclua testes com Vitest.
- Responda somente com dois blocos de código:
  1. implementação
  2. testes

Depois, execute o resultado automaticamente no CI ou em um sandbox. O objetivo é medir quantas respostas passam sem edição manual.

3. Recuperação após falhas de ferramenta

Em fluxos com function calling, simule falhas de API, arquivos ausentes e respostas incompletas. Verifique se o agente adapta o plano ou repete a mesma chamada.

A ferramenta `get_customer` retornou 404 para o ID informado.
Não tente novamente com o mesmo ID.
Explique a próxima ação necessária e peça apenas o dado que falta.

O AutomationBench é especialmente relevante para esse comportamento.

4. Solicitações ambíguas

Teste se o modelo pergunta antes de assumir requisitos críticos.

Crie uma API de pagamentos para meu aplicativo.

Antes de propor a implementação, faça perguntas sobre:
- provedor de pagamento;
- moeda;
- recorrência;
- requisitos de conformidade;
- ambiente de deploy.

5. Fidelidade de formato

Inclua restrições estruturais em prompts longos:

Responda em JSON válido com este formato:

{
  "risks": [{"severity": "low|medium|high", "description": "string"}],
  "recommendation": "string"
}

Não inclua Markdown, comentários, campos extras ou texto fora do JSON.

Preços: metade do preço até 31 de dezembro de 2026

A API Gemini possui duas faixas de preço para o Gemini 3.7 Flash:

Período	Entrada por 1M de tokens	Saída por 1M de tokens
Até 31 de dezembro de 2026	US$ 0,75	US$ 3,75
A partir de 1º de janeiro de 2027	US$ 1,50	US$ 7,50

A taxa introdutória é metade do custo de lançamento do Gemini 3.6 Flash. Porém, o preço dobra em 1º de janeiro de 2027.

Para evitar surpresas:

Confira a página oficial de preços antes de colocar o modelo em produção.
Faça seu orçamento de longo prazo com a tarifa padrão de 2027.
Registre usageMetadata em todas as chamadas.
Separe custos de entrada, saída e chamadas de ferramentas no seu dashboard.

Para exemplos de cálculo em chatbots, processamento de documentos e loops de agentes, consulte a análise de preços do Gemini 3.7 Flash.

Onde usar o modelo

O Google disponibilizou o 3.7 Flash em mais de 160 países:

API Gemini: acesso direto ao modelo gemini-3.7-flash.
Google AI Studio: playground para testar prompts.
Aplicativo Gemini: interface de chat para consumidores.
Gemini Spark: para assinantes AI Pro e Ultra.
Google Antigravity: ambiente de desenvolvimento agêntico.
Android Studio: assistência de código no IDE.
Gemini Enterprise: oferta gerenciada para organizações.

Para workloads corporativos, também existe o caminho via Vertex AI em aiplatform.googleapis.com, com OAuth, IAM e registro de auditoria.

Por que o Flash chegou antes do Gemini 3.5 Pro

A ordem é incomum: normalmente o modelo carro-chefe chega antes das variantes intermediárias. Neste caso, o Google lançou o 3.6 Flash no fim de julho, o 3.7 Flash três semanas depois e o Gemini 3.5 Pro continua sem data.

Segundo a Axios, o Google está lançando atualizações do Flash antes do próximo carro-chefe enquanto o Pro permanece atrasado.

Para desenvolvedores, o efeito prático é simples: não trate mais o Flash como uma opção secundária. Se sua carga prioriza custo, latência e escala, é provável que o Flash seja o primeiro modelo a receber capacidades novas de agente.

Se você já usa o 3.6, consulte o guia de migração do Gemini 3.6 para o 3.7 Flash. Para muitas bases de código, a alteração começa pela troca do ID do modelo, seguida de uma rodada de regressão.

Como testar a API em cinco minutos

Primeiro, crie uma chave de API no Google AI Studio.

Depois, exporte a chave e faça uma requisição:

export GEMINI_API_KEY="AIza..."

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [{
        "text": "Review this function for bugs: def dedupe(items): return list(set(items))"
      }]
    }],
    "generationConfig": {
      "temperature": 0.4,
      "maxOutputTokens": 1024
    }
  }'

A resposta inclui:

candidates: respostas geradas pelo modelo.
content.parts: texto da resposta.
usageMetadata: contagem de tokens de entrada e saída.

Monitore usageMetadata desde o primeiro dia. Esse campo é a base para acompanhar custo por requisição, usuário, fluxo ou ambiente.

Habilitar streaming

Para receber tokens progressivamente via Server-Sent Events, substitua o endpoint:

:generateContent

por:

:streamGenerateContent?alt=sse

Exemplo:

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:streamGenerateContent?alt=sse" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "parts": [{ "text": "Explique recursão em uma frase." }]
    }]
  }'

Comparar 3.6 e 3.7 de forma prática

Depois que a primeira chamada funcionar, compare os dois modelos com as mesmas entradas:

Salve prompts reais do seu produto.
Execute cada prompt contra gemini-3.6-flash.
Repita contra gemini-3.7-flash.
Registre resposta, latência, tokens de entrada, tokens de saída e resultado da validação.
Defina critérios objetivos de aprovação, como testes passando, JSON válido ou nota humana.

No Apidog, importe a especificação da Generative Language API, associe GEMINI_API_KEY ao cabeçalho x-goog-api-key como variável de ambiente e defina o ID do modelo como variável de caminho.

Assim, você pode alternar entre gemini-3.6-flash e gemini-3.7-flash sem duplicar requisições, acompanhar respostas SSE e salvar exemplos para regressões futuras.

Perguntas frequentes

O Gemini 3.7 Flash é gratuito?

A API Gemini possui um nível gratuito no AI Studio com cota diária, adequado para prototipagem. O uso pago começa em US$ 0,75 por 1M de tokens de entrada até 31 de dezembro de 2026.

Para entender os limites, consulte o guia de acesso gratuito à API Gemini.

Qual é a diferença entre Gemini 3.6 Flash e 3.7 Flash?

As especificações principais permanecem iguais: janela de contexto, limite de saída, modalidades e suporte a ferramentas.

Os ganhos estão em codificação e agentes:

DeepSWE: +16,3 pontos.
AutomationBench: +13,4 pontos.
WebDev Arena: +50 Elo.

O Google também afirma melhorias em depuração, seguimento de instruções e planejamento em várias etapas.

O Gemini 3.7 Flash substitui o Gemini 3.5 Pro?

Não. O Pro continua sendo a categoria carro-chefe para tarefas de raciocínio mais difíceis, enquanto o Gemini 3.5 Pro ainda está em desenvolvimento.

O 3.7 Flash é voltado a cargas de produção de alto volume, em que custo e latência importam junto com qualidade.

O que muda no preço em 1º de janeiro de 2027?

A tarifa introdutória termina. O preço passa para:

US$ 1,50 por 1M de tokens de entrada.
US$ 7,50 por 1M de tokens de saída.

Para workloads que continuarão em 2027, projete os custos com a tarifa padrão.

O Gemini 3.7 Flash processa imagens e PDFs?

Sim. Ele aceita texto, imagens, vídeos, áudio e PDFs no array contents. A saída continua sendo somente texto.

O benchmark GDP.pdf passou de 22,0% para 34,0%, o que indica uma melhoria divulgada pelo Google para compreensão de documentos.

Onde o 3.7 Flash se encaixa na sua pilha

O Gemini 3.7 Flash combina benchmarks melhores para agentes, compatibilidade com as especificações do 3.6 e uma janela de preço introdutório. Isso reduz o custo de testá-lo agora, mas não elimina a necessidade de avaliação com dados reais.

A sequência recomendada é:

Reutilize seu conjunto de prompts atual.
Execute-o contra gemini-3.6-flash e gemini-3.7-flash.
Compare qualidade, latência e usageMetadata.
Valide resultados com testes automatizados ou revisão humana.
Faça o orçamento com o preço padrão de 2027.
Migre apenas os fluxos em que o 3.7 demonstrar ganho mensurável.

Use o Apidog para centralizar essa comparação: salve respostas do 3.6 como exemplos, reproduza as mesmas requisições no 3.7 e confirme se os ganhos de benchmark aparecem na sua carga de trabalho.

Como usar a Gemini 3.7 Flash API?

Lucas — Fri, 14 Aug 2026 07:57:13 +0000

O Google lançou o Gemini 3.7 Flash em 13 de agosto de 2026, três semanas após o 3.6 Flash, descrevendo-o como “nosso modelo de trabalho mais inteligente”. Para desenvolvedores, a atualização é direta: os benchmarks de codificação agêntica melhoraram significativamente — DeepSWE v1.1 passou de 49,0% para 65,3% —, o preço de lançamento é metade do valor inicial do 3.6 Flash e a superfície da API não mudou. Se você já usa Gemini, a migração começa trocando o ID do modelo.

Experimente o Apidog hoje

Este guia mostra como obter uma chave de API, testar uma chamada com cURL, portar a integração para Python e Node.js, usar streaming, ajustar generationConfig e validar prompts no Apidog. Segundo o anúncio oficial, o modelo oferece contexto de 1M de tokens, saída de até 64k tokens, entrada multimodal, chamada de função, pesquisa como ferramenta e uso de computador.

Se você já desenvolveu com a geração anterior, o formato da requisição continua igual ao do guia da API Preview do Gemini 3 Flash. Aqui, o foco é no fluxo de trabalho do 3.7.

TL;DR

Modelo: gemini-3.7-flash
Endpoint síncrono: POST https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent
Autenticação: cabeçalho x-goog-api-key: <KEY>
Preço de lançamento: US$ 0,75 por 1M de tokens de entrada e US$ 3,75 por 1M de tokens de saída até 31 de dezembro de 2026. A partir de 1º de janeiro de 2027, os valores passam para US$ 1,50 e US$ 7,50.
Limites: 1M de tokens de contexto e 64k tokens de saída.
Entrada: texto, imagem, vídeo, áudio e PDF.
Streaming: use :streamGenerateContent?alt=sse.
Migração do 3.6: troque o ID do modelo e execute testes de regressão nos prompts.
Teste antes de codificar: valide o endpoint no Apidog, armazene a chave como variável de ambiente e acompanhe eventos SSE ao vivo.

Quando usar o Gemini 3.7 Flash

Os modelos Flash priorizam velocidade e custo, mas o 3.7 reduziu bastante a diferença em capacidade. Em comparação com o Gemini 3.6 Flash:

DeepSWE v1.1: 49,0% → 65,3%
FrontierCode 1.1 Main: 34,4% → 43,6%
AutomationBench: 17,0% → 30,4%
WebDev Arena Elo: 1538 → 1588

Use o 3.7 Flash especialmente quando:

Você executa loops de agentes: o ganho no AutomationBench indica melhor planejamento em múltiplas etapas e chamadas de ferramentas.
Você gera ou revisa código: os resultados em DeepSWE e FrontierCode favorecem tarefas de depuração, revisão e geração de código.
Você processa documentos: o GDP.pdf passou de 22,0% para 34,0%, e PDFs são aceitos como entrada de primeira classe.
Você precisa de multimodalidade com orçamento controlado: texto, imagens, vídeos, áudios e PDFs usam o mesmo array contents.

Para mais contexto sobre recursos, benchmark Harvey LAB-AA e salvaguardas atualizadas, consulte as novidades do Gemini 3.7 Flash. A Axios relata que o Google está entregando atualizações Flash antes do próximo modelo principal.

Obtenha uma chave de API

Há dois caminhos principais.

AI Studio: prototipagem rápida

Abra aistudio.google.com/apikey.
Clique em Obter chave de API.
Selecione um projeto do Google Cloud.
Copie a chave gerada.

A chave funciona com generativelanguage.googleapis.com. O AI Studio oferece um nível gratuito para prototipagem, e o Gemini 3.7 Flash está disponível em mais de 160 países.

Vertex AI: uso em produção no GCP

Use Vertex AI se sua infraestrutura já está no Google Cloud. Nesse caso:

a autenticação usa OAuth, contas de serviço ou tokens de curta duração;
as chamadas usam aiplatform.googleapis.com;
você obtém IAM, logs de auditoria e endpoints regionais.

O ID do modelo e o corpo da requisição permanecem iguais; mudam a URL e a autenticação.

Exporte a chave localmente:

export GEMINI_API_KEY="AIza..."

Nunca inclua a chave diretamente no código ou como ?key= em URLs de produção. Strings de consulta podem aparecer em logs de servidor.

Endpoint e autenticação

Para uma chamada síncrona:

POST https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent

Para streaming com Server-Sent Events:

POST https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:streamGenerateContent?alt=sse

Envie a chave no cabeçalho:

x-goog-api-key: $GEMINI_API_KEY

Faça sua primeira chamada com cURL

Crie uma requisição mínima para confirmar credenciais, endpoint e formato de resposta:

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.7-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "contents": [{
      "role": "user",
      "parts": [{
        "text": "Review this SQL for injection risk: SELECT * FROM orders WHERE id = ${orderId}"
      }]
    }],
    "generationConfig": {
      "temperature": 0.3,
      "maxOutputTokens": 1024
    }
  }'

A resposta inclui:

candidates: candidatos gerados;
candidates[].content.parts: texto ou chamadas de função;
candidates[].finishReason: motivo de término;
usageMetadata: contagem de tokens.

Observe que a API do Google usa contents, role e parts, e não o formato messages de provedores compatíveis com OpenAI.

Início rápido em Python

Instale ou atualize o SDK:

pip install --upgrade google-generativeai

Faça uma chamada com instrução de sistema e configuração de geração:

import os
import google.generativeai as genai

genai.configure(api_key=os.environ["GEMINI_API_KEY"])

model = genai.GenerativeModel(
    model_name="gemini-3.7-flash",
    system_instruction=(
        "You are a code reviewer. "
        "Flag issues as blocking or non-blocking."
    ),
    generation_config={
        "temperature": 0.3,
        "max_output_tokens": 2048,
    },
)

response = model.generate_content(
    "Review this Flask route for security issues:\n\n"
    "@app.route('/user/<id>')\n"
    "def get_user(id):\n"
    "    return db.execute(f'SELECT * FROM users WHERE id = {id}')"
)

print(response.text)
print("input tokens:", response.usage_metadata.prompt_token_count)
print("output tokens:", response.usage_metadata.candidates_token_count)

Envie um PDF

A entrada multimodal usa o mesmo fluxo. Faça upload do arquivo e passe a referência como parte do conteúdo:

invoice = genai.upload_file("q3-invoice.pdf")

response = model.generate_content([
    invoice,
    "Extract the invoice number, total, and due date as JSON.",
])

print(response.text)

Esse é um caso alinhado ao ganho do modelo no benchmark GDP.pdf: extração estruturada a partir de documentos reais.

Início rápido em Node.js

Instale o SDK:

npm install @google/generative-ai

Use responseMimeType e responseSchema para obter JSON estruturado:

import { GoogleGenerativeAI } from "@google/generative-ai";

const genAI = new GoogleGenerativeAI(process.env.GEMINI_API_KEY);

const model = genAI.getGenerativeModel({
  model: "gemini-3.7-flash",
  generationConfig: {
    temperature: 0.3,
    maxOutputTokens: 2048,
    responseMimeType: "application/json",
    responseSchema: {
      type: "object",
      properties: {
        severity: {
          type: "string",
          enum: ["blocking", "non-blocking"],
        },
        issues: {
          type: "array",
          items: { type: "string" },
        },
      },
      required: ["severity", "issues"],
    },
  },
});

const result = await model.generateContent(
  "Review this Express handler: app.get('/search', (req, res) => res.send(eval(req.query.q)))"
);

console.log(JSON.parse(result.response.text()));

responseSchema só deve ser usado junto com:

responseMimeType: "application/json"

Assim, o código downstream recebe uma estrutura analisável em vez de texto livre.

Use streaming para respostas progressivas

Para interfaces de chat e recursos voltados ao usuário, use streaming.

Em Python:

stream = model.generate_content(
    "Explain the N+1 query problem with a concrete ORM example.",
    stream=True,
)

for chunk in stream:
    if chunk.text:
        print(chunk.text, end="", flush=True)

Em HTTP puro, use o endpoint:

:streamGenerateContent?alt=sse

Cada linha data: contém um payload parcial com candidates. O bloco final inclui usageMetadata, portanto a contagem completa de tokens só está disponível quando o stream termina.

Ajuste `generationConfig`

Estes são os parâmetros mais úteis no dia a dia:

Parâmetro	Tipo	Uso prático
`maxOutputTokens`	integer	Limita a saída, até 64k tokens. É a principal alavanca de custo.
`temperature`	number	Vai de 0 a 2. Use 0,2–0,4 para código e extração; 0,7+ para conteúdo criativo.
`responseMimeType`	string	Use `application/json` para saída JSON.
`responseSchema`	object	Define uma estrutura rígida quando combinado com JSON.
`topP`	number	Controla a amostragem nucleus. Mantenha o padrão salvo se estiver ajustando intencionalmente.
`stopSequences`	array	Interrompe a geração em delimitadores específicos.

Os tokens de saída custam US$ 3,75 por milhão durante a taxa de lançamento e US$ 7,50 a partir de janeiro de 2027. Defina maxOutputTokens com base no tamanho realmente necessário para a resposta. Veja exemplos de cálculo em nossa análise de preços do Gemini 3.7 Flash.

Além de generationConfig, a requisição aceita tools e toolConfig para declarações de funções, pesquisa como ferramenta e uso de computador. Para implementar esse fluxo, consulte o tutorial de chamada de função do Gemini 3.7 Flash.

Teste o endpoint no Apidog antes de integrar ao app

Iterar prompts apenas em scripts pode ser lento e caro: editar, executar, inspecionar e repetir consome tokens a cada ciclo. Primeiro, fixe o contrato da requisição em um cliente de API; depois, leve a versão validada para o SDK.

No Apidog, siga este fluxo:

Crie um projeto e importe a especificação OpenAPI da Generative Language API a partir da documentação da API Gemini.
Crie a variável de ambiente GEMINI_API_KEY.
Vincule a variável ao cabeçalho x-goog-api-key.
Crie uma variável para o modelo, como GEMINI_MODEL=gemini-3.7-flash.
Monte o array contents no editor JSON e valide o corpo antes do envio.
Teste o endpoint SSE para acompanhar blocos de streaming em tempo real.
Salve respostas válidas como exemplos para usar fixtures em testes posteriores, sem chamar a API real.

Depois, transforme os casos salvos em cenários de teste com asserções para:

finishReason;
formato da resposta;
campos obrigatórios;
contagens em usageMetadata.

Esse padrão permite executar regressões sempre que um prompt for alterado. Para expandir a estratégia, veja o guia de testes de API para engenheiros de QA.

Tratamento de erros e limites de taxa

A API retorna um objeto error de nível superior com code, status e message.

Código	Status	Causa comum	Ação recomendada
400	`INVALID_ARGUMENT`	Corpo malformado, papel incorreto ou `contents` vazio.	Valide o JSON antes de enviar.
401	`UNAUTHENTICATED`	Chave ausente ou revogada.	Reexporte `GEMINI_API_KEY` e valide a chave no AI Studio.
403	`PERMISSION_DENIED`	Projeto sem acesso ou faturamento.	Verifique o projeto e o status de faturamento.
429	`RESOURCE_EXHAUSTED`	Limite de taxa ou cota diária atingida.	Use espera com jitter, agrupe chamadas ou altere o plano.
500	`INTERNAL`	Falha temporária do servidor.	Tente novamente com backoff exponencial.
503	`UNAVAILABLE`	Serviço sobrecarregado.	Tente novamente após alguns segundos; no Vertex, tente outra região.

Implemente retentativas para 429 e erros 5xx:

import random
import time

RETRYABLE_STATUS_CODES = {429, 500, 503}

def retry_with_backoff(call, max_attempts=5):
    for attempt in range(max_attempts):
        try:
            return call()
        except Exception:
            if attempt == max_attempts - 1:
                raise

            delay = min(2 ** attempt, 30) + random.uniform(0, 1)
            time.sleep(delay)

Também vale seguir três práticas:

monitore o consumo e alerte ao atingir 80% da cota;
consulte os valores atuais na página de preços e limites da API Gemini, sem fixar números no código;
mantenha o ID do modelo em variável de ambiente para permitir rollback rápido.

Exemplo:

export GEMINI_MODEL="gemini-3.7-flash"

FAQ

O Gemini 3.7 Flash é gratuito?

O AI Studio oferece um nível gratuito com cota diária para prototipagem. A tarifa de lançamento é de US$ 0,75 por 1M de tokens de entrada até 31 de dezembro de 2026. Para entender os níveis disponíveis, consulte o guia de acesso gratuito à API Gemini.

Qual é a diferença entre AI Studio e Vertex AI?

O modelo e o corpo da requisição são os mesmos. A diferença está na infraestrutura:

AI Studio: chave de API e generativelanguage.googleapis.com;
Vertex AI: OAuth, aiplatform.googleapis.com, IAM, logs de auditoria e endpoints regionais.

Comece no AI Studio para prototipar e migre para Vertex AI antes de direcionar tráfego de produção.

Posso enviar imagens, áudio e PDFs?

Sim. Texto, imagem, vídeo, áudio e PDF podem ser enviados no array contents, inline como base64 ou por referência com a API Files. A saída é texto.

Qual é o limite de contexto e saída?

O modelo aceita até 1M de tokens de entrada e gera até 64k tokens de saída. Mesmo com uma janela longa, dividir entradas grandes pode reduzir custo, pois tokens de entrada também são cobrados.

Devo migrar do Gemini 3.6 Flash?

Para cargas de trabalho de agentes e código, os ganhos de benchmark justificam testar a migração. A alteração inicial é apenas:

gemini-3.6-flash → gemini-3.7-flash

Antes de enviar tráfego de produção, execute testes de regressão nos prompts. Consulte o guia de migração do Gemini 3.6 para o 3.7 Flash.

Onde o Gemini 3.7 Flash se encaixa na sua stack

O Gemini 3.7 Flash combina custo menor com ganhos relevantes em agentes, código e processamento de documentos. O padrão de adoção mais seguro é:

comece pela chamada cURL;
valide a estrutura de contents e a resposta;
teste prompts e streaming em um cliente de API;
mova a integração validada para Python ou Node.js;
mantenha o modelo configurável por variável de ambiente para rollback.

Para importar a especificação do Gemini, armazenar a chave uma única vez e testar requisições síncronas, streaming e ferramentas no mesmo workspace, baixe o Apidog.

ChatCompletions vs Anthropic Messages vs Responses API: Análise e Comparativo dos Formatos de API do DeepSeek V4 Pro

Lucas — Thu, 13 Aug 2026 09:03:06 +0000

DeepSeek V4 Pro: como testar ChatCompletions, Messages e Responses API

DeepSeek-V4-Pro-0813 atingiu disponibilidade geral em 12 de agosto de 2026 e é servido pelo ID de modelo perene deepseek-v4-pro em https://api.deepseek.com. A plataforma também oferece o modelo mais econômico deepseek-v4-flash (Unite.AI cobriu o anúncio de GA). As especificações incluem janela de contexto de 1M de tokens, saída máxima de 384K tokens, chamada de ferramenta, saídas estruturadas e três modos de pensamento que expõem o raciocínio em reasoning_content.

Experimente o Apidog hoje

A particularidade não está apenas nas especificações: o mesmo modelo aceita três dialetos de API:

OpenAI ChatCompletions
Anthropic Messages
DeepSeek Responses API

Na prática, você pode apontar um cliente OpenAI existente, um agente construído para Claude ou um loop de agente no estilo Codex para os mesmos pesos do modelo. O endpoint e o payload mudam; o modelo continua sendo o mesmo.

Este guia mostra uma requisição funcional para cada formato, explica as diferenças que afetam a implementação e apresenta uma forma de testar os três em um único projeto Apidog, usando variáveis de ambiente compartilhadas. Para configurar a conta e fazer a primeira chamada, consulte como usar a API DeepSeek V4.

TL;DR

deepseek-v4-pro está em GA em https://api.deepseek.com; deepseek-v4-flash compartilha as mesmas interfaces por um preço menor.
O V4 Pro aceita os formatos OpenAI ChatCompletions, Anthropic Messages e DeepSeek Responses API.
Especificações: 1M de contexto, até 384K de saída, tool calling, saídas estruturadas e reasoning_content.
Preço: $0.435/M tokens de entrada em cache miss, $0.003625/M em cache hit e $0.87/M tokens de saída.
Os formatos diferem no prompt de sistema, em max_tokens, nos esquemas de ferramentas e nos eventos de streaming.
Use um projeto Apidog com {{DEEPSEEK_API_KEY}} e URLs-base por formato para enviar o mesmo prompt e comparar respostas.

Por que um modelo fala três dialetos?

Cada formato oferece compatibilidade com uma base de ferramentas já existente:

ChatCompletions é a opção de menor atrito para SDKs, frameworks e integrações compatíveis com OpenAI.
Anthropic Messages permite reutilizar agentes, harnesses de avaliação e ferramentas construídas para Claude, incluindo Claude Code.
Responses API atende fluxos de agentes com múltiplas etapas, saída tipada e estado de conversação no servidor.

O V4 Pro também aparece em agregadores, como na página do OpenRouter para deepseek-v4-pro-0813. Este artigo, porém, foca na API proprietária da DeepSeek. Para uma visão geral da família, veja como usar o DeepSeek V4.

Formato 1: OpenAI ChatCompletions

Use este formato se sua aplicação já envia um array messages para APIs compatíveis com OpenAI.

Implementação com SDK Python

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_DEEPSEEK_API_KEY",
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "system", "content": "You are a precise technical writer."},
        {"role": "user", "content": "Explain idempotency keys in two sentences."}
    ],
)

print(response.choices[0].message.content)

O que manter na migração

A estrutura é a conhecida:

O prompt de sistema entra como a primeira mensagem com role: "system".
Ferramentas usam o objeto aninhado function.
Streaming retorna deltas chat.completion.chunk.
O stream termina com data: [DONE].

Ao usar um modo de pensamento, trate reasoning_content como um campo adicional ao lado de content. Não assuma que a resposta terá apenas o texto final.

Quando usar

Escolha ChatCompletions quando você já usa:

SDK openai;
LangChain ou frameworks semelhantes;
wrappers internos compatíveis com OpenAI;
coleções e testes construídos para Chat Completions.

A anatomia da requisição é a mesma mostrada em como testar a API ChatGPT com Apidog, trocando apenas host, chave e modelo.

Formato 2: Anthropic Messages

O formato Messages parece semelhante ao ChatCompletions, mas possui diferenças que impedem uma tradução mecânica do payload.

Diferenças importantes

O prompt de sistema fica no campo de topo system, fora do array messages.
max_tokens é obrigatório.
As ferramentas usam name, description e input_schema diretamente, sem o wrapper function.
Chamadas de ferramenta retornam como blocos tool_use.
Os resultados devem voltar como blocos tool_result em uma mensagem de usuário.

Implementação com SDK Python

import os
import anthropic

client = anthropic.Anthropic(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com/anthropic",  # Confirme o caminho atual na documentação da DeepSeek
)

message = client.messages.create(
    model="deepseek-v4-pro",
    max_tokens=8192,
    system="You are a precise technical writer.",
    messages=[
        {
            "role": "user",
            "content": "Explain idempotency keys in two sentences."
        }
    ],
)

print(message.content[0].text)

Configuração por variáveis de ambiente

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic
export ANTHROPIC_AUTH_TOKEN=$DEEPSEEK_API_KEY
export ANTHROPIC_MODEL=deepseek-v4-pro

Como tratar a resposta e o streaming

Ao contrário de ChatCompletions, o conteúdo é retornado como uma lista de blocos:

for block in message.content:
    print(block)

No streaming, espere eventos SSE tipados, como:

message_start
content_block_delta
message_stop

A autenticação segue as convenções de cabeçalho da especificação Anthropic, não o padrão bearer token de ChatCompletions. Consulte a documentação da API DeepSeek para os detalhes atuais da interface compatível.

Quando usar

Escolha Messages quando sua stack já é nativa de Claude:

agentes compatíveis com Anthropic;
Claude Code;
harnesses de avaliação para Claude;
clientes que já manipulam blocos de conteúdo e eventos SSE tipados.

O formato corresponde à anatomia explicada no guia da API Claude Opus 5, permitindo testar DeepSeek e Claude com corpos de requisição equivalentes.

Formato 3: DeepSeek Responses API

A Responses API é a interface voltada a agentes. Em vez de enviar um único array messages, você combina:

instructions para instruções de alto nível;
input como string ou lista de itens tipados;
opcionalmente, referências a respostas anteriores para manter estado no servidor.

Requisição básica com cURL

curl https://api.deepseek.com/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-v4-pro",
    "instructions": "You are an API review agent. Be terse.",
    "input": "Review this OpenAPI diff and list any breaking changes: [diff here]",
    "stream": false
  }'

O que muda em relação aos outros formatos

1. Estado no lado do servidor

Em vez de reenviar todo o histórico, uma requisição posterior pode apontar para uma resposta anterior usando previous_response_id, conforme a especificação Responses.

Isso reduz a complexidade de loops de agentes com várias etapas.

2. Saída tipada

A resposta não é uma única mensagem. Ela pode conter itens distintos para:

raciocínio;
texto;
chamadas de ferramenta;
resultados de ferramentas.

Seu orquestrador pode processar cada item conforme seu tipo, em vez de inferir tudo a partir de uma string.

3. Streaming semântico

Em vez de deltas genéricos, espere eventos de ciclo de vida como:

response.output_text.delta
response.completed

Isso é útil quando o agente precisa reagir a eventos específicos sem interpretar manualmente chunks SSE.

Tool calling na Responses API

As ferramentas e seus resultados usam itens compatíveis com a especificação Responses, incluindo:

function_call
function_call_output

Antes de implantar, valide o formato exato suportado pela DeepSeek em api-docs.deepseek.com.

Quando usar

Escolha a Responses API para:

agentes no estilo Codex;
fluxos de trabalho longos e multi-etapas;
orquestradores que se beneficiam de itens de saída tipados;
aplicações que querem delegar o estado da conversa ao servidor.

Para uma conclusão simples de chat, ChatCompletions normalmente exige menos código.

Os três formatos lado a lado

	OpenAI ChatCompletions	Anthropic Messages	DeepSeek Responses API
Endpoint	`POST /chat/completions` em `api.deepseek.com`	`POST /v1/messages` na base compatível com Anthropic (`/anthropic`)	`POST /responses` em `api.deepseek.com`
Formato da requisição	Array `messages`; sistema como primeira mensagem	`system` no topo + mensagens alternadas	`instructions` no topo + `input` como string ou lista
Limite de saída	Opcional	`max_tokens` obrigatório	Opcional conforme a especificação Responses
Definições de ferramenta	Objeto `function` aninhado com `parameters`	`input_schema` plano por ferramenta	Entradas planas no formato Responses
Resultado de ferramenta	Mensagem com `role: "tool"`	Bloco `tool_result`	Item `function_call_output`
Streaming	Deltas `chat.completion.chunk`, finalizados por `[DONE]`	Eventos `message_start`, `content_block_delta` e `message_stop`	Eventos semânticos, como `response.output_text.delta`
Estado da conversa	Cliente reenvia o histórico	Cliente reenvia o histórico	Referência opcional a resposta anterior
Melhor para	Ferramentas OpenAI existentes	Ferramentas e agentes nativos de Claude	Agentes com estado e fluxos estilo Codex

Mesmo modelo, mesmo preço, três contratos de comunicação. Por isso, valide o comportamento com requisições reais em vez de depender apenas da compatibilidade declarada.

Teste os três em um único projeto Apidog

Use uma coleção única no Apidog para comparar os formatos de forma repetível.

1. Crie três pastas

Organize as requisições por formato:

deepseek-v4/
├── chat-completions/
│   ├── simple-completion
│   ├── tool-calling
│   └── streaming
├── anthropic-messages/
│   ├── simple-completion
│   ├── tool-calling
│   └── streaming
└── responses/
    ├── simple-completion
    ├── tool-calling
    └── streaming

2. Defina variáveis compartilhadas

Crie variáveis de ambiente:

DEEPSEEK_API_KEY
BASE_URL=https://api.deepseek.com
ANTHROPIC_BASE=https://api.deepseek.com/anthropic
MODEL=deepseek-v4-pro

Assim, alternar entre deepseek-v4-pro e deepseek-v4-flash exige mudar apenas uma variável.

3. Envie o mesmo prompt

Use o mesmo prompt em cada formato e compare a resposta bruta:

ChatCompletions: choices[0].message.content
Messages: lista content
Responses: itens de saída tipados

Essa comparação mostra onde sua camada de parsing precisa mudar.

4. Compare os streams

Ative stream: true em cada requisição e observe os eventos SSE:

ChatCompletions: chunks que terminam em [DONE];
Messages: eventos nomeados por bloco;
Responses: eventos de ciclo de vida.

Se você ainda não depurou SSE, consulte como fazer streaming de respostas da API com SSE.

5. Adicione asserções de regressão

Valide os campos que sua integração realmente consome:

caminho do texto final;
ID da chamada de ferramenta;
motivo de finalização;
presença de reasoning_content;
formato dos eventos de streaming.

Execute a coleção novamente sempre que a DeepSeek publicar uma atualização de snapshot.

Essa estrutura de três pastas também se torna documentação viva: quando surgir uma dúvida sobre input_schema, tool_result ou eventos de stream, consulte uma requisição salva com uma resposta real.

Notas de migração

De OpenAI para DeepSeek V4 Pro

Altere apenas:

base_url para https://api.deepseek.com;
a chave da API;
o modelo para deepseek-v4-pro.

Mantenha mensagens, definições de ferramenta e handlers de streaming. Antes de implantar:

execute os parâmetros não essenciais na sua coleção de testes;
faça seu parser aceitar reasoning_content ao lado de content.

De Anthropic para DeepSeek V4 Pro

Altere:

a URL-base para o endpoint compatível com Anthropic;
a chave de autenticação;
o modelo.

Como o formato Messages é preservado, clientes que seguem a especificação devem manter:

max_tokens obrigatório;
blocos de conteúdo;
ferramentas com input_schema;
eventos SSE tipados.

Para ferramentas configuradas por ambiente, a migração pode ser apenas as três linhas export mostradas anteriormente.

Para a Responses API

A migração para Responses não é uma troca de configuração. Você precisa adaptar a camada de requisição e parsing, pois ela não se traduz mecanicamente de ChatCompletions ou Messages.

Adote-a quando precisar especificamente de:

estado de conversação gerenciado pelo servidor;
itens de saída tipados;
eventos de streaming orientados ao ciclo de vida;
orquestração de agentes multi-etapas.

Em qualquer direção, migre a configuração e execute a coleção de regressão antes de confiar no tráfego de produção.

FAQ

Qual formato um projeto novo deve escolher?

Use ChatCompletions por padrão, devido ao suporte amplo de ferramentas. Escolha Messages se sua stack já for nativa de Claude. Escolha a Responses API para agentes multi-etapas que se beneficiem de estado no servidor.

Posso apontar o Claude Code para o DeepSeek V4 Pro?

Sim. Defina ANTHROPIC_BASE_URL para o endpoint compatível com Anthropic da DeepSeek, use a chave DeepSeek como token de autenticação e configure:

export ANTHROPIC_MODEL=deepseek-v4-pro

Esse é o benefício prático da compatibilidade com o formato Messages.

Tool calling e saídas estruturadas funcionam nos três formatos?

O modelo suporta ambos. Cada formato expõe ferramentas segundo sua própria especificação:

funções aninhadas em ChatCompletions;
ferramentas com input_schema em Messages;
itens de função no estilo Responses.

Teste seus esquemas em cada interface antes de implantar. Diferenças nos formatos de schema são um dos pontos mais comuns de divergência entre APIs compatíveis.

Aumento de Preço da DeepSeek API: Manual de Otimização de Custos para Desenvolvedores

Lucas — Thu, 13 Aug 2026 08:33:48 +0000

DeepSeek construiu sua base de desenvolvedores com uma troca simples: modelos quase de ponta a preços que tornavam o custo irrelevante. Em 6 de agosto de 2026, a empresa alertou que essa troca está prestes a mudar. Em um anúncio primeiramente coberto por Dataconomy, a DeepSeek disse que os preços da API aumentarão “em breve” e que o aumento deverá ser “significativo”. Sem números, sem data efetiva e sem detalhamento por modelo ou nível de preço.

Experimente o Apidog hoje

O contexto torna o aviso crível. A DeepSeek cita aumento dos custos de computação, gargalos de capacidade e tráfego massivo em V4-Flash e V4-Pro. Esta é a segunda mudança de preço em menos de um mês: tarifas de pico e fora de pico chegaram em meados de julho, e o V4-Pro 0813 atingiu disponibilidade geral em 12 de agosto. A eWeek enquadra a mudança como um teste da vantagem de baixo custo que tornou a DeepSeek uma escolha econômica para equipes na APAC e além.

Você não controla as novas taxas. Mas pode controlar quantos tokens compra, qual modelo usa, em que horário envia as requisições e qual provedor atende cada rota.

Este guia mostra como agir antes do reajuste, incluindo cenários de 1,5x, 2x e 3x para uma carga de trabalho de exemplo.

TL;DR

A DeepSeek anunciou um aumento “significativo” no preço da API em 6 de agosto de 2026, sem informar valor, data ou impacto por modelo.
Sua maior alavanca é o cache automático de prefixo de prompt: entradas em cache custam menos de 1% da taxa de cache-miss. Estabilize os prefixos agora.
Roteie por tarefa: use V4-Flash para chamadas simples e de alto volume; reserve V4-Pro para raciocínio profundo.
Limite o esforço de pensamento por rota para não pagar tokens de raciocínio em tarefas mecânicas.
Execute cargas em lote nas janelas fora de pico introduzidas pela DeepSeek em julho.
Mantenha um segundo provedor pronto. A OpenRouter precifica modelos DeepSeek de forma independente, e uma suíte de testes no Apidog pode validar o failover.
Mesmo em um cenário especulativo de 3x, a saída do V4-Pro custaria $2,61 por milhão de tokens, abaixo dos $25–30 por milhão atribuídos por comparações públicas a concorrentes de ponta.

O que a DeepSeek anunciou — e o que não anunciou

A divulgação é limitada:

Os preços da API aumentarão “em breve”.
O aumento será “significativo”.
As causas são custos de computação, gargalos de capacidade e tráfego intenso nos endpoints V4-Flash e V4-Pro.

Em 13 de agosto, as taxas atuais ainda se aplicavam.

O que continua desconhecido:

O percentual do aumento.
A data efetiva.
Se V4-Flash e V4-Pro subirão pelo mesmo fator.
Se cache-hit e cache-miss escalarão igualmente.
Se cargas de trabalho de raciocínio terão tratamento diferente.

Discussões no Hacker News especulam aumentos entre 2x e 3x, mas não há confirmação oficial. Planeje para uma faixa de cenários, não para um único número.

Estas são as tarifas que os cenários multiplicariam:

Modelo	Entrada (cache miss)	Entrada (cache hit)	Saída
DeepSeek V4-Pro	$0,435 / M tokens	$0,003625 / M tokens	$0,87 / M tokens
DeepSeek V4-Flash	$0,14 / M tokens	—	$0,28 / M tokens

Ambos os modelos têm janela de contexto de 1M tokens. Consulte o guia de preços da API DeepSeek V4 para o detalhamento e acompanhe o cartão de tarifas atualizado na documentação da API DeepSeek.

Duas proporções orientam as decisões deste artigo:

A entrada com cache custa menos de 1% da entrada sem cache.
O V4-Pro custa aproximadamente 3x o V4-Flash em entrada e saída.

Passo 1: meça sua exposição antes do aumento

Um aumento de preço é apenas um multiplicador sobre o seu consumo atual. Antes de alterar prompts, modelos ou rotas, instrumente as chamadas para saber exatamente onde estão os tokens.

Registre, no mínimo:

Funcionalidade ou endpoint que disparou a chamada.
Modelo utilizado.
Tokens de entrada.
Tokens de saída.
Tokens atendidos pelo cache.

usage = response.usage

log.info("llm_call", extra={
    "feature": "ticket-summarizer",
    "model": "deepseek-v4-flash",
    "input_tokens": usage.prompt_tokens,
    "output_tokens": usage.completion_tokens,
    "cache_hit_tokens": usage.prompt_cache_hit_tokens,
})

O padrão de atribuição por funcionalidade, painéis e economia unitária está em como rastrear o gasto da API OpenAI por funcionalidade e pode ser aplicado à DeepSeek sem mudanças estruturais.

Com uma semana de dados, responda:

Quais funcionalidades consomem a maior parte do orçamento?
Qual porcentagem dos tokens de entrada atinge o cache?
Quais rotas usam V4-Pro para trabalho que V4-Flash poderia executar?
Em qual multiplicador de preço cada funcionalidade deixa de ser economicamente viável?

Esse quarto item é seu limite de decisão para trocar ou dividir tráfego entre provedores.

Passo 2: maximize os hits de cache

A DeepSeek armazena prefixos de prompt automaticamente. Quando os tokens iniciais de uma requisição correspondem aos de uma requisição recente, o prefixo repetido é cobrado como cache-hit.

No V4-Pro:

Cache miss: $0,435 por milhão de tokens de entrada.
Cache hit: $0,003625 por milhão de tokens de entrada.

Não há flags de controle de cache ou TTL para gerenciar. O desconto depende de a estrutura do prompt ser repetível. Para revisar a mecânica, consulte o que é cache de prompt e como funciona.

Estruture prompts como estático primeiro, dinâmico por último

O cache corresponde a prefixos exatos de tokens. Organize os prompts nesta ordem:

[Prompt do sistema estável]
[Políticas estáveis]
[Definições de ferramentas em ordem determinística]
[Exemplos few-shot estáveis]
[Contexto de sessão ou documentos recuperados]
[Mensagem atual do usuário]

Aplique estas regras:

Coloque primeiro o conteúdo que nunca muda: instruções do sistema, políticas, ferramentas e exemplos.
Mantenha os mesmos bytes e a mesma ordem em todas as chamadas.
Empurre dados variáveis para o final: mensagens do usuário, documentos recuperados, IDs e contexto de sessão.
Remova timestamps, IDs de requisição e saudações personalizadas do início do prompt.
Garanta que listas de ferramentas e objetos JSON sejam serializados em ordem determinística.

Um timestamp no prompt do sistema pode invalidar todo o prefixo. O mesmo vale para um array de ferramentas cuja ordem muda entre requisições.

Isso é especialmente relevante em loops de agentes. Se o agente reenvia a conversa inteira a cada turno, todo o conteúdo anterior à mensagem mais recente pode ser atendido pelo cache — desde que o prefixo permaneça estável.

Calcule a taxa de acerto por resposta

A DeepSeek expõe dados de cache no objeto usage, conforme a documentação da API DeepSeek:

u = response.usage

hit_rate = u.prompt_cache_hit_tokens / (
    u.prompt_cache_hit_tokens + u.prompt_cache_miss_tokens
)

Envie essa métrica para seu painel por funcionalidade:

metrics.gauge(
    "llm.cache_hit_rate",
    hit_rate,
    tags={
        "feature": "ticket-summarizer",
        "model": "deepseek-v4-pro",
    },
)

Se uma rota repetitiva tiver taxa baixa de cache-hit, revise o prefixo antes de aceitar o custo como inevitável.

Passo 3: roteie por tarefa, não por hábito

O V4-Pro custa aproximadamente 3x o V4-Flash. Esse custo pode ser justificável para raciocínio profundo, mas não para reformatação de JSON ou classificação simples.

Audite os dados coletados no Passo 1 e defina rotas explícitas:

Forma da carga de trabalho	Modelo recomendado
Classificação, extração, formatação e roteamento de intenção	V4-Flash, pensamento mínimo
Resumos, respostas RAG e geração de rascunhos	V4-Flash primeiro; promover para Pro somente quando avaliações falharem
Loops de agente, depuração difícil e análise de arquitetura	V4-Pro, com orçamento de pensamento

Evite deixar a escolha de modelo implícita no código. Centralize-a em uma função ou camada de roteamento:

def select_model(task_type: str) -> str:
    flash_tasks = {
        "classification",
        "extraction",
        "formatting",
        "intent-routing",
        "summarization",
    }

    if task_type in flash_tasks:
        return "deepseek-v4-flash"

    return "deepseek-v4-pro"

Limite o esforço de pensamento por rota

Rastros de raciocínio são cobrados como tokens de saída. No V4-Pro, saída custa $0,87 por milhão de tokens.

Defina uma política simples:

Tarefas mecânicas: sem pensamento ou pensamento mínimo.
Tarefas com avaliação intermediária: esforço moderado.
Agentes e análise complexa: pensamento profundo apenas quando a qualidade mensurável justificar.

Não reduza qualidade por intuição. Faça a alteração, rode suas avaliações e compare os resultados:

1. Mova uma rota do V4-Pro para o V4-Flash.
2. Execute o conjunto de avaliações.
3. Compare taxa de aprovação, precisão e latência.
4. Mantenha a mudança se os critérios continuarem atendidos.
5. Promova novamente para Pro apenas as entradas que falharem.

Passo 4: mova trabalhos em lote para horários fora de pico

A DeepSeek introduziu precificação de pico e fora de pico em meados de julho. As janelas e descontos atuais estão no cartão de tarifas da documentação da API DeepSeek.

Priorize cargas sem usuário aguardando resposta:

Execuções noturnas de avaliação.
Preenchimento de embeddings.
Rotulagem de datasets.
Suítes de regressão de prompts no CI.
Geração de relatórios.
Processamento de filas internas.

Em vez de disparar essas tarefas sob demanda, use uma fila com horário de liberação:

job = {
    "type": "nightly-evaluation",
    "release_at": "off_peak_window",
    "payload": evaluation_batch,
}

queue.enqueue(job)

Essa otimização não exige nova validação de qualidade: os tokens e o modelo são os mesmos; apenas o horário muda.

A ressalva é que a DeepSeek não informou se a diferença entre pico e fora de pico sobreviverá ao próximo reajuste. Aproveite as tarifas atuais e revise a configuração quando a tabela de preços for atualizada.

Sua conta em cenários de 1,5x, 2x e 3x

Os valores abaixo são cenários ilustrativos, não previsões. A DeepSeek não anunciou multiplicadores, e não há garantia de que todos os níveis de preço escalarão uniformemente.

Carga mensal de exemplo:

V4-Pro: 400M tokens de entrada, 60% de cache-hit e 60M tokens de saída.
- Cache miss: $69,60
- Cache hit: $0,87
- Saída: $52,20
- Total Pro: $122,67
V4-Flash: 600M tokens de entrada e 120M tokens de saída.
- Entrada: $84,00
- Saída: $33,60
- Total Flash: $117,60

Fatura base: $240,27.

A coluna otimizada aplica os Passos 2 e 3:

Taxa de cache-hit do Pro sobe de 60% para 85%.
Saída do Pro cai de 60M para 45M tokens por meio de orçamentos de pensamento.
V4-Flash permanece inalterado.

Cenário de taxa	Conta não otimizada	Otimizada (Passos 2–3)
Taxas atuais	$240	$184
Aumento de 1,5x	$360	$276
Aumento de 2x	$481	$368
Aumento de 3x	$721	$552

A leitura prática é simples: uma carga otimizada com aumento de 2x ($368) custa aproximadamente o mesmo que uma carga não otimizada com aumento de 1,5x ($360).

As economias estruturais acompanham qualquer multiplicador. Uma redução de 23% vale cerca de $56 hoje e $168 em um cenário de 3x.

O desconto fora de pico não está incluído na tabela porque depende da programação vigente. Portanto, a coluna otimizada é conservadora.

Quando trocar modelos supera a otimização

Mesmo no cenário especulativo de 3x, a saída do V4-Pro chegaria a $2,61 por milhão de tokens. Comparações públicas colocam a saída de concorrentes de ponta entre $25 e $30 por milhão.

A vantagem de custo diminui, mas não desaparece automaticamente.

Otimize e permaneça quando

DeepSeek passa nas suas avaliações de qualidade.
Seu tráfego possui prompts cacheáveis.
As rotas podem ser encaminhadas entre Flash e Pro.
Você tem capacidade de engenharia para implementar as mudanças antes do reajuste.

Troque ou divida o tráfego quando

Sua taxa de cache-hit é estruturalmente baixa porque cada requisição carrega documentos longos e únicos.
Você paga por V4-Pro em tarefas que um modelo menor de outro provedor aprova nas suas avaliações.
O multiplicador anunciado ultrapassa o limite econômico calculado no Passo 1.
Você precisa reduzir risco operacional de depender de um único provedor.

Para a maioria das equipes, a resposta será híbrida:

Mantenha DeepSeek nas rotas em que vence em custo por avaliação aprovada.
Mova rotas em que outro modelo entrega melhor custo ou qualidade.
Execute testes de paridade continuamente entre provedores.

Conclusão

A DeepSeek informou que os preços vão subir, mas ainda não detalhou quanto, quando ou como cada modelo será afetado.

Use esse período para executar ações mensuráveis:

Instrumente gasto e tokens por funcionalidade.
Estabilize os prefixos de prompt para aumentar cache-hit.
Roteie tarefas simples para V4-Flash.
Limite pensamento em rotas que não exigem raciocínio profundo.
Programe workloads em lote para janelas fora de pico.
Valide um segundo provedor antes de precisar dele.

Para testar o failover, baixe o Apidog gratuitamente. Crie a suíte uma vez, execute-a contra api.deepseek.com e contra seu fallback usando ambientes separados por provedor, e agende execuções para garantir que ambos continuem compatíveis.

Como Usar Function Calling com a API DeepSeek V4 Pro

Lucas — Thu, 13 Aug 2026 08:33:02 +0000

DeepSeek tirou o V4 Pro da prévia em 12 de agosto de 2026, e a cobertura de lançamento destaca fluxos de trabalho de agente: codificação, uso de ferramentas e tarefas de longo prazo que encadeiam dezenas de etapas sem perder o contexto. Nesse cenário, a chamada de função (function calling) é o recurso central da API. Este guia mostra como definir ferramentas, executar o loop completo de um agente com o SDK Python openai e validar o fluxo no Apidog.

Experimente o Apidog hoje

Se você ainda não tem uma chave de API DeepSeek, configure uma com nosso guia sobre como usar a API DeepSeek V4 e retorne a este tutorial.

TL;DR

deepseek-v4-pro (compilação GA DeepSeek-V4-Pro-0813) suporta chamadas de função no estilo OpenAI: envie um array tools, receba tool_calls e retorne resultados como mensagens tool. O SDK openai padrão funciona com https://api.deepseek.com.
O loop completo do agente tem cerca de 30 linhas de Python: chame o modelo, execute ferramentas, adicione os resultados ao histórico e repita até receber uma resposta final.
Chamadas paralelas e saídas estruturadas são suportadas. O modo de raciocínio adiciona reasoning_content.
O cache de prefixo automático precifica tokens de entrada com acerto de cache em US$ 0,003625 por milhão de tokens, 120x menos que uma falha de cache.
A qualidade da chamada de ferramenta depende das descrições e dos esquemas. Teste suas ferramentas reais com o modelo ao vivo.

Por que a chamada de ferramenta é o principal caso de uso do V4 Pro

A DeepSeek construiu o V4 Pro para agentes, e as especificações refletem requisitos comuns de runtimes de agentes:

Especificação	DeepSeek V4 Pro
Arquitetura	MoE esparsa: 1,6T parâmetros totais, 49B ativos por token
Janela de contexto	1M tokens
Saída máxima	384K tokens
Preço de entrada	US$ 0,435/M tokens (falha de cache), US$ 0,003625/M (acerto de cache)
Preço de saída	US$ 0,87/M tokens
Chamada de função	Array `tools` compatível com OpenAI e respostas `tool_calls`
Outras interfaces	Formato Anthropic Messages, API DeepSeek Responses

A janela de 1M de tokens permite carregar o histórico e os resultados de ferramentas em tarefas longas. O cache de prefixo reduz o custo de reenviar esse histórico a cada rodada. O modelo também está listado no OpenRouter como deepseek-v4-pro-0813 para comparações entre provedores.

Há uma ressalva importante: na discussão de lançamento no Hacker News, desenvolvedores relataram que o desempenho de chamadas de ferramenta varia com o ambiente de teste, o scaffolding do prompt e o estilo do esquema. Benchmarks não substituem testes com seus endpoints, parâmetros e regras de negócio.

Como funciona a chamada de função da DeepSeek

O modelo não executa funções diretamente. Ele retorna uma solicitação estruturada, por exemplo: “chame get_order com {"order_id": "ORD-10442"}”.

Seu aplicativo executa a função, devolve o resultado ao modelo e continua o fluxo.

O ciclo é:

Envie messages e o array tools, com cada ferramenta descrita em JSON Schema.
O modelo retorna tool_calls e finish_reason: "tool_calls" quando precisa de uma ferramenta.
Analise os argumentos e execute a função no seu backend.
Adicione o resultado como uma mensagem com role: "tool", vinculada ao ID da chamada.
Repita até o modelo retornar uma resposta final sem tool_calls.

Se você já usou chamada de função da OpenAI, o formato é o mesmo. Em muitos casos, basta alterar a URL base e o nome do modelo. Os documentos oficiais da DeepSeek também descrevem um endpoint de Mensagens compatível com Anthropic e uma API de Respostas, mas este artigo usa a interface compatível com OpenAI.

Passo 1: configure o cliente

Instale o SDK e defina sua chave:

pip install openai
export DEEPSEEK_API_KEY="sk-..."

Configure o cliente apontando para a API da DeepSeek:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

Os exemplos usam model="deepseek-v4-pro", que se refere à compilação GA DeepSeek-V4-Pro-0813.

Passo 2: defina um esquema de ferramenta

Vamos criar um agente de suporte para uma loja online. A primeira ferramenta consulta pedidos.

Uma definição de ferramenta contém:

Um nome estável para a função.
Uma descrição clara de quando ela deve ser usada.
Um JSON Schema para validar os parâmetros.

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_order",
            "description": (
                "Busca um pedido de cliente pelo ID. Retorna status, "
                "transportadora, código de rastreio e previsão de entrega. "
                "Use esta ferramenta quando o usuário perguntar onde está "
                "um pedido ou qual é seu status."
            ),
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {
                        "type": "string",
                        "description": "ID do pedido no formato 'ORD-10442'.",
                    }
                },
                "required": ["order_id"],
            },
        },
    }
]

A descrição influencia diretamente a decisão do modelo. Se ela for vaga, o modelo pode ignorar a ferramenta ou selecionar uma função incorreta.

Agora implemente a função local. Neste exemplo, ela usa dados simulados; em produção, substitua-a pela chamada ao seu serviço de pedidos.

def get_order(order_id: str) -> dict:
    """Substitua pelo seu serviço real de pedidos."""
    fake_db = {
        "ORD-10442": {
            "status": "shipped",
            "carrier": "DHL",
            "tracking_number": "4281337005",
            "estimated_delivery": "2026-08-15",
        },
        "ORD-10587": {
            "status": "processing",
            "estimated_ship_date": "2026-08-14",
        },
    }

    return fake_db.get(
        order_id,
        {"error": f"ID de pedido desconhecido: {order_id}"},
    )

Passo 3: faça sua primeira chamada de ferramenta

Envie uma pergunta que exige consulta ao sistema de pedidos:

messages = [
    {
        "role": "system",
        "content": "Você é um agente de suporte de uma loja online.",
    },
    {
        "role": "user",
        "content": "Onde está meu pedido ORD-10442?",
    },
]

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=messages,
    tools=tools,
)

message = response.choices[0].message

print(message.tool_calls[0].function.name)
# get_order

print(message.tool_calls[0].function.arguments)
# {"order_id": "ORD-10442"}

Em vez de inventar uma resposta, o modelo solicita que seu código execute get_order.

Um payload de resposta típico é:

{
  "id": "chatcmpl-8f3a1c",
  "object": "chat.completion",
  "model": "deepseek-v4-pro",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "",
        "tool_calls": [
          {
            "id": "call_0_f1c29a44",
            "type": "function",
            "function": {
              "name": "get_order",
              "arguments": "{\"order_id\": \"ORD-10442\"}"
            }
          }
        ]
      },
      "finish_reason": "tool_calls"
    }
  ],
  "usage": {
    "prompt_tokens": 312,
    "completion_tokens": 24,
    "total_tokens": 336,
    "prompt_cache_hit_tokens": 0,
    "prompt_cache_miss_tokens": 312
  }
}

Três detalhes são essenciais:

finish_reason igual a "tool_calls" indica que você deve executar ferramentas.
Cada chamada tem um id exclusivo, que precisa ser retornado em tool_call_id.
arguments é uma string JSON. Faça o parsing e valide o conteúdo antes de executar qualquer operação.

Passo 4: execute a função e retorne o resultado

Adicione ao histórico a mensagem do assistente que contém tool_calls. Em seguida, adicione uma mensagem tool com o resultado da execução.

import json

tool_call = message.tool_calls[0]
args = json.loads(tool_call.function.arguments)

result = get_order(**args)

messages.append(message)

messages.append({
    "role": "tool",
    "tool_call_id": tool_call.id,
    "content": json.dumps(result),
})

final = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=messages,
    tools=tools,
)

print(final.choices[0].message.content)
# Seu pedido ORD-10442 foi enviado pela DHL e deve chegar
# em 15 de agosto de 2026. Código de rastreio: 4281337005.

O vínculo pelo tool_call_id é obrigatório: para cada item em tool_calls, envie uma mensagem tool correspondente antes da próxima chamada ao modelo.

Passo 5: implemente o ciclo completo do agente

Agentes reais encadeiam chamadas: consultar um pedido, buscar uma política de reembolso, verificar estoque e redigir uma resposta. O padrão é sempre o mesmo: chamar o modelo, executar as ferramentas solicitadas e repetir até obter uma resposta normal.

import json

TOOLS_BY_NAME = {
    "get_order": get_order,
}

def run_agent(client, messages, tools, max_rounds=10):
    """Executa o agente até obter uma resposta final ou atingir o limite."""
    for _ in range(max_rounds):
        response = client.chat.completions.create(
            model="deepseek-v4-pro",
            messages=messages,
            tools=tools,
        )

        message = response.choices[0].message
        messages.append(message)

        if not message.tool_calls:
            return message.content

        for tool_call in message.tool_calls:
            try:
                fn = TOOLS_BY_NAME.get(tool_call.function.name)

                if fn is None:
                    raise ValueError(
                        f"Ferramenta desconhecida: {tool_call.function.name}"
                    )

                args = json.loads(tool_call.function.arguments)
                result = fn(**args)

            except Exception as exc:
                result = {"error": str(exc)}

            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": json.dumps(result),
            })

    raise RuntimeError(
        f"O agente não terminou após {max_rounds} rodadas"
    )

O limite max_rounds é uma proteção operacional. Ele evita que um modelo preso em chamadas repetidas gere custos e execuções indefinidas.

Chamadas de ferramenta paralelas

Para uma pergunta como “compare o status de ORD-10442 e ORD-10587”, o V4 Pro pode retornar várias chamadas em uma única resposta:

"tool_calls": [
  {
    "id": "call_0_a7d1",
    "type": "function",
    "function": {
      "name": "get_order",
      "arguments": "{\"order_id\": \"ORD-10442\"}"
    }
  },
  {
    "id": "call_1_b3e9",
    "type": "function",
    "function": {
      "name": "get_order",
      "arguments": "{\"order_id\": \"ORD-10587\"}"
    }
  }
]

O loop anterior já suporta esse caso: ele cria uma mensagem tool para cada tool_call. Se suas ferramentas forem independentes, você pode executar o lote concorrentemente com asyncio, um pool de threads ou sua fila de jobs.

Isso difere da chamada de ferramenta programática do GPT-5.6, em que o modelo escreve código de orquestração em um sandbox. No modelo da DeepSeek, a execução continua sob controle do seu runtime.

Modo de raciocínio (thinking mode) e ferramentas

O V4 Pro oferece três modos de raciocínio. Você pode usar mais esforço de raciocínio em rodadas de planejamento e ignorá-lo em consultas rotineiras. Consulte os documentos oficiais para os nomes e padrões dos modos.

Com o raciocínio ativado, a API retorna reasoning_content junto com tool_calls:

response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=messages,
    tools=tools,
    extra_body={"thinking": {"type": "enabled"}},
)

message = response.choices[0].message

print(message.reasoning_content)
print(message.tool_calls)

O rastreamento pode ajudar a identificar por que o modelo escolheu uma ferramenta ou interpretou um parâmetro de forma incorreta.

Antes de adicionar a mensagem do assistente ao histórico, remova reasoning_content quando não precisar preservá-lo. Reserve o raciocínio para etapas de planejamento, pois ele é cobrado como saída a US$ 0,87/M tokens.

Tratamento de erros: quando o modelo erra uma chamada

Chamadas malformadas são raras, mas precisam ser tratadas. Não interrompa o agente por causa de um JSON inválido ou de parâmetros fora das regras de negócio. Retorne o erro como resultado da ferramenta para que o modelo possa corrigir a chamada na próxima rodada.

import json
from jsonschema import ValidationError, validate

schema = tools[0]["function"]["parameters"]

try:
    args = json.loads(tool_call.function.arguments)
    validate(instance=args, schema=schema)

    result = get_order(**args)

except (json.JSONDecodeError, ValidationError) as exc:
    result = {
        "error": f"Argumentos inválidos: {exc}",
        "hint": (
            "Chame get_order novamente usando um order_id no formato "
            "'ORD-10442'."
        ),
    }

O campo hint torna a correção explícita e costuma ser suficiente para o modelo tentar novamente com argumentos válidos.

Trate erros de ferramenta também como eventos de segurança. Um modelo induzido a chamar delete_order com argumentos maliciosos é tão perigoso quanto as credenciais disponíveis para essa ferramenta. Use chaves de API com o menor privilégio para agentes de IA e limite o escopo de cada integração.

Teste e depure chamadas de ferramenta com Apidog antes de lançar

Cada ferramenta é um invólucro em torno de uma API, e o modelo passa a ser um consumidor dessa API. Se o endpoint for ambíguo, inconsistente ou retornar erros difíceis de interpretar, o agente herdará esse problema.

Use o Apidog para validar o fluxo antes de conectar o agente à produção:

Projete a API de suporte primeiro. Defina GET /orders/{order_id} no designer visual do Apidog. Mantenha o JSON Schema da ferramenta alinhado à especificação da API para evitar divergências.
Simule antes de o backend existir. O mock inteligente do Apidog pode gerar respostas realistas a partir do esquema, permitindo testar get_order enquanto o serviço real ainda está em desenvolvimento.
Inspecione payloads brutos. Envie o mesmo corpo com messages e tools para https://api.deepseek.com pelo Apidog. Inspecione o JSON de tool_calls para identificar propriedades aninhadas incorretamente e argumentos serializados duas vezes.
Transforme conversas em cenários de teste. Valide finish_reason, nomes de ferramentas e formatos de argumentos. Execute a suíte a cada alteração de esquema. Como o comportamento depende do formato das ferramentas, uma regressão baseada nos seus cenários reais é mais útil que benchmarks genéricos.

Veja também como conectar um agente de IA a uma estrutura de teste Apidog para um padrão mais aprofundado.

Baixe o Apidog gratuitamente para acompanhar. O servidor de mock e os cenários de teste estão incluídos na camada gratuita.

Quanto custam os ciclos de agente — e por que o cache decide isso

Um agente relê o histórico inteiro a cada rodada. Na décima rodada, o prompt de sistema, as definições de ferramentas e os resultados anteriores voltam a fazer parte da entrada.

O cache de prefixo automático do V4 Pro reduz esse custo porque a entrada de cada rodada tende a ser igual à rodada anterior, acrescida de novas mensagens. Assim, a maior parte do prefixo pode ser cobrada a US$ 0,003625/M tokens, em vez de US$ 0,435/M tokens.

Reler uma conversa de 100K tokens custa aproximadamente:

Sem cache: US$ 0,0435
Com cache: US$ 0,0004

Monitore prompt_cache_hit_tokens e prompt_cache_miss_tokens no bloco usage para observar a taxa de acerto real.

Para manter o cache eficiente:

Não altere mensagens já enviadas.
Mantenha o array tools estável entre as rodadas.
Evite reordenar ferramentas ou mudar descrições durante uma conversa.
Serialize os schemas de forma consistente.

Nosso guia sobre o que é cache de prompt cobre a mecânica em mais detalhes.

Embora deepseek-v4-flash a US$ 0,14/US$ 0,28 possa parecer atraente para roteamento de ferramenta de uso único, ele regride em ciclos com mais de 10 chamadas encadeadas. Para agentes com múltiplas etapas, o Pro é a opção mais segura.

FAQ

As definições de ferramentas custam tokens?

Sim. O array tools faz parte da entrada de cada solicitação. Mantenha-o estável para que ele entre no prefixo em cache após a primeira rodada e seja cobrado pela taxa de acerto de cache.

Posso combinar chamada de função com saídas estruturadas?

Sim. Um padrão comum é:

Ferramentas buscam dados intermediários.
O modelo processa esses dados.
Um esquema de saída estruturado formata a resposta final.

Assim, seu código downstream recebe JSON previsível sem precisar analisar texto livre.

Conclusão

A chamada de função no DeepSeek V4 Pro é simples de implementar: defina schemas compatíveis com OpenAI, processe tool_calls e devolva resultados em mensagens tool vinculadas pelo ID.

O loop do Passo 5 é a base da arquitetura. O ponto crítico não é apenas o código: são os schemas, a validação, os limites de execução, as permissões das credenciais e os testes de regressão.

Projete as APIs de suporte de forma deliberada, simule endpoints cedo e mantenha cenários de teste para as chamadas reais do seu agente no Apidog. Isso reduz o risco de uma alteração de esquema quebrar silenciosamente o fluxo em produção.

Grok 4.6 vs GPT-5.6 vs Claude Fable 5: Qual Modelo Escolher para Desenvolvedores API

Lucas — Thu, 13 Aug 2026 08:31:45 +0000

O Grok 4.6 foi lançado em 12 de agosto com uma proposta que muda a comparação entre modelos de fronteira: ele empata com o GPT-5.6 Sol no Índice de Inteligência Artificial, mas custa US$ 6 por milhão de tokens de saída, contra US$ 30. Muitos comparativos ainda usam o Grok 4.5, que estava distante da fronteira em capacidade. Com o 4.6, o preço passou a ser um fator relevante na decisão.

Experimente o Apidog hoje

A resposta curta é: o GPT-5.6 Sol continua sendo a escolha mais forte para agentes de codificação em escala de repositório; o Claude Fable 5 lidera, por pouco, em trabalho autônomo de longa duração; e o Grok 4.6 se tornou a opção de melhor custo-benefício, próxima o suficiente em capacidade para exigir uma justificativa clara para os preços dos concorrentes. A escolha depende da sua carga de trabalho. Abaixo estão os benchmarks, as diferenças de API e um método reproduzível para testar os três modelos na sua própria stack. Para executar esse teste, o Apidog permite acessar as três APIs lado a lado em um único workspace.

TL;DR

Índice de Inteligência: Claude Fable 5 lidera com 62; Grok 4.6 e GPT-5.6 Sol empatam com 61.
Preço de saída por 1M de tokens: Grok 4.6 custa US$ 6; Claude Opus 4.8, US$ 25; GPT-5.6 Sol, US$ 30.
Janela de contexto: GPT-5.6 Sol tem 1,05M de tokens; Claude Fable 5, 1M; Grok 4.6, 500K.
Codificação: Sol Max lidera o DeepSWE (73,0% vs. 65,9% do Grok); Fable 5 Max lidera o FrontierCode (63,6% vs. 61,3%).
Agentes: Fable 5 Max lidera o APEX-Agents com 59,2%; Grok 4.6 (57,5%) supera Sol Max (56,7%).
Custo por tarefa concluída: a Artificial Analysis mediu US$ 0,84 para o Grok 4.6, o menor valor entre os modelos de fronteira.
Decisão prática: não escolha apenas por benchmark. Execute um teste com 20 prompts reais da sua aplicação.

Especificações e preços lado a lado

	Grok 4.6	GPT-5.6 Sol	Claude Fable 5
Desenvolvedor	xAI	OpenAI	Anthropic
Índice de Inteligência	61	61	62
Janela de contexto	500K	1,05M	1M
Preço de entrada / 1M	US$ 2	US$ 12	US$ 10
Preço de saída / 1M	US$ 6	US$ 30	US$ 25*
Variante rápida/premium	2x o preço	Nível Sol Max	Nível Fable 5 Max
Estilo de API	Compatível com OpenAI	Nativo OpenAI	Anthropic Messages
Corte de conhecimento	Fev. de 2026

* Os preços do Claude exibidos são do Opus 4.8. Os preços do nível Fable 5 variam conforme a configuração de esforço. Consulte o guia de preços do GPT-5.6 e a análise de redução de custos do Claude para ver as matrizes completas.

A diferença de preço é o ponto principal:

Na entrada, o Grok cobra um sexto do preço do OpenAI.
Na saída, cobra um quinto.
Em agentes, onde uma tarefa pode executar dezenas de chamadas e gerar transcrições longas de ferramentas, essa diferença pode separar um agente de US$ 50/dia de um agente de US$ 250/dia.

Benchmarks de codificação: Sol para profundidade, Grok para valor

Benchmark	Grok 4.6	GPT-5.6 Sol Max	Claude Fable 5 Max
DeepSWE v1.1 — correções em escala de repositório	65,9%	73,0%
FrontierCode v1.1 Estendido	61,3%	60,6%	63,6%
CursorBench v3.2	69,9%
APEX-Agents	57,5%	56,7%	59,2%
Terminal-Bench v2.1	88,4%

Use esses números como um critério inicial de roteamento:

GPT-5.6 Sol Max para tarefas de maior impacto em repositórios. A vantagem de 7 pontos no DeepSWE importa em correções complexas e navegação em grandes bases de código. Se o seu agente altera projetos existentes com pouca supervisão, o Sol é a escolha mais segura. Veja a comparação entre GPT-5.6 Sol e Claude Fable 5 para mais detalhes.
Claude Fable 5 para execução autônoma longa e consistente. Ele lidera o índice composto, o FrontierCode e o APEX-Agents. Esse perfil é útil quando um erro no meio do fluxo pode invalidar uma hora de progresso.
Grok 4.6 como modelo padrão sensível a custo. Ele lidera CursorBench e Terminal-Bench, permanece próximo nos demais benchmarks e custa uma fração dos concorrentes. Use-o para a maior parte do tráfego e escale apenas os casos difíceis.

Esses são números de lançamento amplamente reportados pelos fornecedores. Os benchmarks de lançamento do Grok 4.5 exigiram leitura cuidadosa, e a mesma cautela vale para todos os modelos desta comparação.

Meça custo por tarefa, não apenas custo por token

Preço por token não basta quando os modelos têm níveis diferentes de verbosidade, repetição e sucesso no uso de ferramentas.

Um modelo barato que falha em uma execução de terminal pode gerar custos maiores de revisão, rerun e reparo do que a economia inicial de tokens. A métrica mais útil é:

custo por tarefa concluída = custo total das execuções / tarefas concluídas com sucesso

Na avaliação independente da Artificial Analysis, o Grok 4.6 teve média de US$ 0,84 por tarefa de agente, o menor valor entre os modelos de fronteira. Isso foi influenciado não apenas pelo preço, mas também por um uso de tokens relativamente disciplinado.

Exemplo de custo por tarefa

Considere um agente de codificação que usa, em média:

500K tokens de entrada por tarefa;
100K tokens de saída por tarefa.

Modelo	Custo de entrada	Custo de saída	Custo por tarefa
Grok 4.6	US$ 1,00	US$ 0,60	US$ 1,60
Claude Opus 4.8	US$ 5,00	US$ 2,50	US$ 7,50
GPT-5.6 Sol	US$ 6,00	US$ 3,00	US$ 9,00

Em 1.000 tarefas mensais, o Grok pode economizar aproximadamente US$ 6.000 a US$ 7.400 em relação às alternativas, desde que a taxa de sucesso se mantenha na sua carga de trabalho.

A condição é essencial: valide a qualidade antes de migrar o tráfego.

Ergonomia da API: avalie o custo de integração

Além de benchmark e preço, considere quanto trabalho será necessário para integrar, alternar e observar os modelos.

Grok 4.6

O Grok 4.6 é compatível com o formato da OpenAI. Se o seu cliente já usa uma API no estilo OpenAI, normalmente basta trocar a URL base:

from openai import OpenAI

client = OpenAI(
    api_key="SUA_XAI_API_KEY",
    base_url="https://api.x.ai/v1",
)

Ele também está disponível no OpenRouter, Vercel e Cloudflare para usuários de gateways.

GPT-5.6 Sol

O GPT-5.6 Sol oferece o ecossistema mais amplo:

Responses API;
chamada programática de ferramentas;
SDKs próprios;
integrações de terceiros.

Consulte como usar a API GPT-5.6 para a estrutura de níveis.

Claude Fable 5

O Claude Fable 5 usa a API Messages da Anthropic, com formato de requisição diferente. O modelo oferece boa confiabilidade no uso de ferramentas e um parâmetro de esforço que permite trocar custo por capacidade dentro do mesmo modelo.

Na prática:

A migração entre Grok e OpenAI tende a ter menos atrito.
A migração para ou a partir da Anthropic exige adaptação de payloads.
Se você pretende rotear requisições entre provedores, isole o cliente de LLM atrás de uma interface própria.

Por exemplo:

type ModelProvider = "xai" | "openai" | "anthropic";

interface LLMRequest {
  system: string;
  prompt: string;
  tools?: unknown[];
}

async function runModel(provider: ModelProvider, request: LLMRequest) {
  // Normalize payloads and responses here.
  // Keep provider-specific code out of business logic.
}

Janelas de contexto: quando 500K é suficiente

No papel, a janela de 1,05M de tokens do GPT-5.6 Sol é mais do que o dobro da janela de 500K do Grok 4.6. O Claude Fable 5 fica próximo, com 1M.

Na prática, pergunte:

Sua aplicação realmente precisa manter mais de 500K tokens úteis em uma única requisição?

Uma janela de 500K comporta aproximadamente 350.000 palavras: uma base de código inteira de um serviço médio, um ano de transcrições de suporte ou centenas de páginas de documentos legais.

Casos que realmente podem exigir mais de 500K tokens:

análise de monorepo completo;
transcrições muito longas de agentes em múltiplas sessões sem sumarização;
processamento pontual de grandes conjuntos documentais.

Mesmo nesses cenários, duas regras continuam válidas:

A qualidade degrada quando o contexto enche. Recuperar informação com 80% da janela ocupada tende a ser pior do que com 20%.
Entrada extensa aumenta rapidamente o custo. Preencher a janela inteira do Sol custa cerca de US$ 12,60 por requisição no preço de tabela; preencher a do Grok custa cerca de US$ 1.

Se os seus prompts passam frequentemente de 400K tokens, a solução não é apenas escolher uma janela maior. Você precisa de uma estratégia de recuperação, cache e sumarização.

Corte de conhecimento e maturidade do ecossistema

O Grok 4.6 tem corte de conhecimento em 1º de fevereiro de 2026, o mais recente dos três. Isso pode ajudar agentes de codificação que precisam reconhecer frameworks e bibliotecas em rápida evolução.

Ainda assim, trate o conhecimento paramétrico como complemento. Uma stack de agentes robusta deve usar:

documentação versionada;
busca semântica;
RAG;
ferramentas de consulta ao repositório;
fontes externas controladas.

O ecossistema apresenta o cenário inverso:

OpenAI possui a superfície mais profunda de integrações de terceiros.
Anthropic tem forte presença em frameworks de agentes.
xAI se beneficia da compatibilidade com o formato da OpenAI.

A compatibilidade da xAI reduz o esforço de adoção, especialmente para clientes que já usam chat completions. Porém, recursos como APIs de lote, camadas de cache e controles de uso granular são menos maduros do que os oferecidos pelos provedores incumbentes.

Qual modelo usar para cada tarefa

Cenário	Modelo recomendado	Motivo
Agente de codificação autônomo em escala de repositório	GPT-5.6 Sol	Liderança no DeepSWE e menor risco em tarefas complexas
Trabalho de conhecimento de longa duração	Claude Fable 5	Melhor índice composto e melhor resultado em agentes
Alto volume e sensibilidade a custo	Grok 4.6	Capacidade próxima da fronteira com custo muito menor
Roteador de modelos	Grok 4.6 como padrão; Sol/Fable para escalonamento	Reduz custo sem sacrificar os casos mais difíceis
Codificação interativa em IDE	Grok 4.6	Liderança no CursorBench e variante rápida 2x
Sessões de IDE baseadas em Cursor	Grok 4.6	Foi treinado após treinamento em sessões reais do Cursor

Uma política simples de roteamento pode começar assim:

1. Envie todas as tarefas para Grok 4.6.
2. Avalie risco, tamanho do diff, falhas de ferramenta e confiança.
3. Escale tarefas críticas ou falhas repetidas para GPT-5.6 Sol ou Claude Fable 5.
4. Registre custo, latência, sucesso e necessidade de intervenção humana.

Teste os três modelos na sua stack em uma tarde

Benchmarks medem médias. O que importa é o comportamento nos prompts, ferramentas, esquemas e repositórios que sua equipe usa todos os dias.

Use o Apidog para criar um teste comparativo reproduzível.

1. Crie um projeto com três ambientes

Configure um ambiente para cada provedor:

Ambiente	Base URL
xAI	`https://api.x.ai/v1`
OpenAI	URL da API OpenAI
Anthropic	URL da API Anthropic

Adicione a autenticação de cada provedor como variável de ambiente. Assim, a mesma coleção pode alternar entre fornecedores usando um menu suspenso.

2. Colete 20 prompts reais

Não use perguntas genéricas. Monte um conjunto com tarefas reais do produto:

bugs reportados por usuários;
solicitações reais de pull request;
transformações de dados;
chamadas de ferramenta;
prompts que falharam anteriormente;
pelo menos cinco casos conhecidos por serem difíceis.

Inclua o mesmo prompt de sistema, as mesmas ferramentas e os mesmos documentos de contexto para todos os modelos.

3. Defina critérios de sucesso antes da execução

Crie asserções para os indicadores que realmente importam:

resposta válida;
conformidade com JSON Schema;
presença e estrutura correta da chamada de ferramenta;
uso de tokens no objeto usage;
latência máxima;
conteúdo esperado no resultado.

Para workloads com tool calling, valide explicitamente o JSON retornado:

{
  "name": "create_pull_request",
  "arguments": {
    "title": "Corrigir erro de validação",
    "branch": "fix/validation-error"
  }
}

Modelos falham nesse ponto com mais frequência do que em respostas textuais. Uma resposta bem escrita não é suficiente se a chamada de ferramenta não pode ser analisada pelo seu runtime.

4. Execute cada prompt três vezes por modelo

Saídas de LLM variam. Uma única execução pode esconder instabilidade.

Para cada combinação de prompt e modelo:

20 prompts × 3 execuções × 3 modelos = 180 execuções

Exporte os resultados e registre:

Métrica	Como calcular
Taxa de sucesso	tarefas concluídas / tarefas executadas
Custo médio por execução	custo total / execuções
Custo por sucesso	custo total / tarefas concluídas
Latência p50 e p95	distribuição de tempo de resposta
Taxa de erro de ferramenta	chamadas inválidas / chamadas totais
Intervenção humana	tarefas que exigiram correção manual

A métrica principal deve ser:

custo por sucesso = custo total do modelo / tarefas concluídas com sucesso

5. Preserve o conjunto de avaliação

Mantenha os prompts, critérios e resultados versionados no repositório.

Quando uma nova versão de modelo for lançada:

execute o mesmo conjunto;
compare com o baseline;
valide regressões;
atualize a política de roteamento.

A escolha de modelo passou a ser uma decisão trimestral. Equipes com um framework de avaliação pronto mudam semanas antes de equipes que decidem por demonstrações isoladas.

FAQ

O Grok 4.6 é melhor que o GPT-5.6 Sol?

Eles empatam no índice composto, com 61. O Sol lidera com clareza a codificação em escala de repositório no DeepSWE (73,0% vs. 65,9%). O Grok lidera CursorBench e Terminal-Bench e custa 5x menos na saída. A escolha depende de a sua carga se parecer mais com manutenção de repositório ou com uma sessão de IDE.
O Grok 4.6 é melhor que o Claude Fable 5?

O Fable 5 lidera o índice, o FrontierCode e o APEX-Agents, todos por pequena margem. A vantagem do Grok é o preço. Para trabalho autônomo crítico e orientado à precisão, Fable 5; para volume sensível a custo, Grok.
Qual é o modelo de fronteira mais barato em 2026?

O Grok 4.6, a US$ 2 por milhão de tokens de entrada e US$ 6 por milhão de tokens de saída, além da medição independente de US$ 0,84 por tarefa de agente.
Devo migrar meu agente de produção para o Grok 4.6?

Não apenas com base em benchmarks. Execute o teste comparativo com a sua carga real. A diferença de preço só compensa se a taxa de sucesso se mantiver.
Posso usar os três modelos com um único formato de API?

Em grande parte, sim. O Grok 4.6 é compatível com o formato de chat completions da OpenAI e pode compartilhar código cliente com o GPT-5.6. O Claude requer a API Messages da Anthropic, ou um gateway como OpenRouter para normalizar as interfaces.
A janela de contexto menor do Grok 4.6 importa?

Para a maioria das cargas de trabalho de agentes e chat, não. Os 500K tokens estão muito acima do uso típico, e todos os modelos degradam perto do limite. A diferença importa para monorepos inteiros ou conjuntos documentais muito grandes processados em uma única chamada.

DEV Community: Lucas

Como Usar a CLI do Apidog no DeepSeek Harness

Sobre qual DeepSeek Harness este artigo trata

Passo 1: adicione o Apidog CLI ao AGENTS.md

Passo 2: copie o comando gerado pelo Apidog

Passo 3: faça o agente executar o teste

Passo 4: leia o relatório e corrija a falha

O loop completo: editar, testar, corrigir

Verifique se o dsh realmente executou o cenário

1. Confirme a chamada do comando

2. Confirme o código de saída

3. Confirme os IDs do cenário e do ambiente

Opcional: adicione o servidor Apidog MCP para acessar a especificação

Ressalvas da prévia e próximos passos

FAQ

O DeepSeek Harness lê AGENTS.md nativamente?

Preciso de um plano pago do DeepSeek para usar o Apidog CLI no dsh?

Por que o segundo comando esquece o diretório alterado pelo primeiro?

O dsh pode executar o cenário sem pedir aprovação toda vez?

DeepSeek Harness vs Claude Code: Qual o Agente de Código Ideal para Sua Stack?

Comparação rápida

Código aberto vs. proprietário

Quando isso importa?

Interface: UI web local vs. múltiplos ambientes

Decisão prática

Liberdade de modelo

Decisão prática

Preço: pagamento por token vs. assinatura

Regra prática

Maturidade: prévia vs. produto estabelecido

Extensibilidade: kernel de plug-ins vs. pontos de extensão

Decisão prática

Permissões

MCP: nativo vs. plug-in da comunidade

Como usar Apidog com os dois agentes

Qual você deve escolher?

Escolha o DeepSeek Harness se:

Escolha o Claude Code se:

Estratégia pragmática

FAQ

O DeepSeek Harness é realmente open source, ao contrário do Claude Code?

O DeepSeek Harness pode usar modelos Claude?

O DeepSeek Harness é estável para trabalho diário?

Ambos os agentes funcionam com Apidog?

O Que É DeepSeek Harness (dsh)? O Concorrente de Código Aberto do Claude, Explicado

O que é o DeepSeek Harness

Arquitetura: tudo é plugin

Início rápido: execute o primeiro agente

Configure a primeira sessão

Use perfis e modo headless

Quais modelos o dsh pode executar?

Provedores de catálogo

Provedores personalizados

Ecossistema de plugins

Como funciona o MCP via plugin

Onde seu fluxo de trabalho de API se encaixa

Devo testar agora ou esperar?

Teste agora se você:

Espere se você:

FAQ

DeepSeek Harness é gratuito?

O dsh só funciona com modelos DeepSeek?

É seguro executar o DeepSeek Harness na minha base de código?

Qual é a diferença entre um orquestrador e um modelo?

Hospedagem própria do GLM-5.3: Prepare-se para a liberação dos pesos abertos

TL;DR

O que será lançado e quando

Planeje o hardware: 744B totais não significa 40B de memória

Decisão recomendada antes do lançamento

Escolha sua pilha de serving antes dos pesos chegarem

Opção 1: vLLM

Opção 2: SGLang

Opção 3: llama.cpp, Ollama e LM Studio

Crie uma linha de base com a API hospedada

Capture respostas determinísticas o máximo possível

Monte um harness de regressão no Apidog

Configuração recomendada

Mantenha o código cliente igual

Compare custo de API e GPUs próprias

Checklist para o dia do lançamento

Passo 1: adicione o Apidog CLI ao `AGENTS.md`

Quais modelos o `dsh` pode executar?

O `dsh` só funciona com modelos DeepSeek?