Gemini 4 Carbon, Hydrogen ou Argon: qual escolher para sua tarefa?

Para um novo fluxo cotidiano de programação ou de agentes, comece avaliando o Hydrogen. Considere o Carbon quando um problema difícil de raciocínio persistir mesmo com contexto suficiente e configuração correta. Mantenha o Argon quando sua avaliação atual já demonstrar que ele atende aos requisitos. Um nome mais recente, sozinho, não justifica migrar uma aplicação que funciona.

Essa é uma recomendação prática baseada nas especificações do Google verificadas em 13 de novembro de 2026. Não é um benchmark de desempenho entre os três modelos: não os executamos sobre um conjunto comum de testes para este artigo. Os enunciados e cálculos abaixo ajudam a reproduzir sua própria avaliação; não são resultados medidos dos modelos.

O Hydrogen chegou depois do Carbon, acrescentando uma opção à antiga escolha entre o modelo mais forte e o mais barato. O Google posiciona o Hydrogen para execução eficiente, o Argon para trabalho avançado com menos esforço de raciocínio que o Carbon, e o Carbon para problemas que se beneficiam de verificação mais profunda. Essas descrições indicam pontos de partida. A decisão final depende do resultado aprovado, do tempo gasto e da conta completa. As fontes são os guias do Google sobre Hydrogen, Argon e Carbon, em inglês.

Diferenças que mudam a escolha

As sugestões de tarefas são recomendações editoriais. Não afirmam que o Argon sempre supera o Hydrogen nem que o Carbon vence qualquer problema difícil. Nome, tamanho e ordem de lançamento não estabelecem um ranking universal.

Captura feita em 13 de novembro de 2026. Ela mostra o contexto do lançamento, não uma integração com a Ofox nem um teste de modelo. Anúncio original em inglês.

Recursos compartilhados não justificam escolher o Carbon por si só

Os três modelos recebem materiais multimodais e geram texto. As especificações incluem chamadas de função, saída estruturada e Computer Use, entre outros recursos. Receber uma imagem ou um vídeo não significa gerar imagens ou vídeos. Se a entrega precisa ser uma imagem, um vídeo ou áudio falado, escolha o modelo de geração correspondente. Aumentar o nível de raciocínio não libera esses formatos de saída.

Um modelo maior também não fornece o ambiente de execução que falta à aplicação. Uma chamada de ferramenta propõe uma ação; seu programa precisa executá-la, devolver o resultado, tratar erros e aplicar as permissões do usuário. Na automação de interfaces, separe as ações do modelo do cliente que captura a tela e realiza cliques. Nosso artigo sobre o controlador de Computer Use, em inglês explica essa divisão.

Confira a rota de integração nas especificações de Hydrogen, Argon e Carbon, em inglês. Um recurso disponível na API nativa do Google não está automaticamente disponível em todo gateway de terceiros ou SDK.

Um milhão de tokens de contexto não é um milhão de entrada mais um milhão de saída

Entrada, raciocínio e saída compartilham a janela de 1.048.576 tokens. Quanto maior a entrada, menor o espaço para analisar e responder. O orçamento de uma requisição síncrona comum também não equivale à capacidade máxima de geração longa.

O Google documenta um orçamento padrão de 65.536 tokens para raciocínio e saída. Gerações maiores exigem o mecanismo apropriado de continuação ou execução em segundo plano. Os limites de uma resposta HTTP e o comportamento de continuação do SDK são diferentes. Não suponha que toda chamada sem streaming retornará 65K palavras ou tokens visíveis. Para saídas do tamanho de um livro, consulte antes o guia de long decode em inglês.

Em um relatório fundamentado em fontes, primeiro remova entradas irrelevantes e defina a entrega. Trocar para o Carbon não corrige uma requisição que ficou sem orçamento útil para a resposta.

Escolha pelo trabalho que precisa ser aprovado

Implementar uma funcionalidade ou um aplicativo web interativo

Para um fluxo novo, avalie primeiro o Hydrogen. Um pedido útil delimita a mudança, fornece um repositório executável, testes claros e uma definição de conclusão. Assim é possível distinguir uma funcionalidade entregue de um código apenas convincente.

Por exemplo, peça uma tela de upload de CSV que valide o cabeçalho, mostre linhas inválidas e exporte um arquivo corrigido. A aceitação exige que o projeto inicie, rejeite corretamente o arquivo de teste inválido, preserve as colunas esperadas na exportação e funcione em uma tela estreita. Uma captura não basta: uma interface bonita com o botão de exportação desconectado reprova a tarefa.

Mantenha o Argon se esse fluxo já funciona e não existe benefício medido na migração. Considere o Carbon quando a falha envolver uma dependência difícil ou um conflito de projeto. Pacote ausente, navegador indisponível ou comando de teste incorreto pedem correção do ambiente antes de uma troca de modelo.

Um bug recorrente entre vários componentes

O Carbon é um candidato razoável quando é preciso considerar explicações concorrentes: uma condição de corrida intermitente nas tentativas, estado inconsistente entre serviços ou um patch que corrige um caso e quebra outro. A ênfase documentada em verificação profunda é pertinente, mas o modelo ainda precisa de evidências.

Forneça um teste que falha, uma reprodução mínima, logs relevantes e uma restrição contra reescritas sem relação com o problema. Peça a explicação do mecanismo da falha, um patch focado e o teste de regressão que falharia sem ele. Se o bug não puder ser reproduzido, um experimento de diagnóstico mais específico pode ser a entrega intermediária correta, em vez de uma afirmação confiante de que está resolvido.

Ao escalar para outro modelo, repasse a hipótese atual e as verificações que falharam. Não envie apenas “tente melhor”. Se a primeira tentativa nunca recebeu o arquivo necessário, fornecê-lo pode importar mais que mudar o modelo.

Comparar PDFs, planilhas e fontes conflitantes

Comece com o Hydrogen quando o material e o formato da saída estiverem bem definidos: extrair totais de notas, comparar duas especificações ou montar uma tabela de evidências. Avalie o Carbon quando contradições, definições ambíguas ou raciocínio entre documentos forem a dificuldade principal. O Argon continua válido se seu fluxo consolidado já lida com esses casos de forma confiável.

Defina a aceitação no nível de cada afirmação. Todo número deve ter nome de arquivo e referência de página ou célula. Informações ausentes devem permanecer explicitamente ausentes. Recalcule totais fora da resposta em prosa e mostre valores conflitantes separadamente, sem tirar uma média silenciosamente.

Este enunciado pode ser usado na mesma tarefa documental com diferentes modelos:

Compare os documentos de especificação dos fornecedores em anexo.
Retorne uma tabela com requisito, valor do fornecedor, unidade,
nome do arquivo-fonte, página ou célula e conflito não resolvido.

Não preencha dados ausentes com conhecimento geral.
Mantenha separadas as definições conflitantes.
Depois da tabela, liste as perguntas mínimas necessárias para resolver os conflitos.
Sucesso significa que cada valor pode ser rastreado até os arquivos fornecidos.

É uma sugestão de prompt de avaliação, não um relato de tarefa concluída por algum modelo. Também não garante a correção automática da tabela gerada.

Um fluxo de ferramentas com várias etapas

Avalie separadamente a escolha do modelo e o desenho do fluxo. Uma sequência comum é ler fontes → extrair fatos → chamar ferramenta → validar resultado → salvar arquivo. O Hydrogen é um candidato inicial para o ciclo de execução; o Carbon pode ser avaliado no planejamento ou na revisão mais difíceis.

Divida responsabilidades apenas quando a fronteira for explícita. Um modelo de planejamento entrega especificação e critérios de aceitação, um executor realiza mudanças delimitadas e um verificador inspeciona os arquivos. Mais agentes introduzem tokens de passagem de contexto, informações duplicadas e erros de coordenação. Paralelizar não é necessariamente mais barato.

Não transfira um histórico incompatível sem alterações entre modelos ou provedores. Preserve o estado da tarefa em um artefato explícito e siga os requisitos da API de destino para chamadas de ferramenta e resultados. Se uma requisição falhar após o uso de ferramentas, investigue o tratamento de thought signatures do Gemini, em inglês, antes de atribuir a falha ao raciocínio.

Compare o custo completo da tarefa, não só o preço por token

A tabela apresenta preços Standard da camada paga da Google Gemini API, em dólares americanos por milhão de tokens, verificados em 13 de novembro de 2026. Não são preços da Ofox, assinaturas ou cotações Batch, Flex ou Priority. A tarifa de saída inclui tokens de raciocínio. A fonte de todas as datas e tarifas é a página de preços do Google, em inglês.

A fonte consultada não anuncia para o Hydrogen um aumento equivalente em 1º de dezembro. Isso não garante que o preço nunca mudará.

Carbon e Argon terem a mesma tarifa não significa o mesmo custo por tarefa. O total varia com o comprimento do raciocínio, entradas repetidas entre turnos, tentativas malsucedidas, validação e ferramentas. A API do Google usa cache implícito nesses modelos. Uma requisição antiga de cache explícito não é uma otimização que possa ser reaproveitada sem ajustes.

Para o caso básico sem cache:

Custo do modelo = tokens de entrada sem cache / 1.000.000 × tarifa de entrada
                + tokens de saída faturáveis / 1.000.000 × tarifa de saída

Custo da tarefa = soma dos custos do modelo em todas as tentativas
                + cobranças aplicáveis de ferramentas, execução e outros serviços

Não conte o raciocínio duas vezes se o campo de uso escolhido já o incluir. Leia as definições de contabilização da API que você realmente chama. A entrada em cache, quando informada, deve ser calculada separadamente pela tarifa correspondente.

Exemplo controlado com uso idêntico

Suponha uma tarefa concluída que consuma 100.000 tokens de entrada sem cache e 10.000 tokens de saída faturáveis, incluindo raciocínio, sem ferramentas pagas. São quantidades hipotéticas, não uma carga de trabalho medida.

• Hydrogen: 0,1 × US$ 1,50 + 0,01 × US$ 7,50 = US$ 0,225.
• Argon ou Carbon até 30 de novembro: 0,1 × US$ 2 + 0,01 × US$ 10 = US$ 0,30.
• Argon ou Carbon a partir de 1º de dezembro: 0,1 × US$ 4 + 0,01 × US$ 20 = US$ 0,60.

O exemplo isola as tarifas. Não informa qual modelo terá sucesso nem quantos tokens serão consumidos de verdade.

Outro exemplo: mais raciocínio e novas tentativas

Mantenha a entrada em 100.000 tokens, mas suponha que uma tentativa do Carbon consuma 30.000 tokens de saída faturáveis. Essa chamada hipotética custa US$ 0,50 nas tarifas introdutórias ou US$ 1,00 nas tarifas anunciadas para dezembro.

Três tentativas do Hydrogen, cada uma com o uso do primeiro exemplo, custam US$ 0,675. Nesse cenário construído, uma tentativa bem-sucedida do Carbon custa menos que três do Hydrogen durante o período introdutório, mas mais nas tarifas de dezembro. Tentativas reais podem reutilizar cache, produzir outros comprimentos ou falhar por motivos alheios ao raciocínio. Portanto, não são economias previstas.

Registre o custo por tarefa aprovada, incluindo tentativas malsucedidas. Um preço baixo por token só é útil junto de uma taxa de conclusão e uma latência aceitáveis.

Faça uma avaliação pequena antes de mudar o padrão

Use o CSV de avaliação para download para registrar seus resultados. Ele contém cabeçalhos em inglês e linhas vazias, sem notas de benchmark. Escolha casos representativos do seu trabalho, incluindo pelo menos um em que o fluxo atual falha.

Registre ID exato, provedor, versão do cliente, nível de raciocínio, limites de tokens, configuração das ferramentas, tempo, uso e resultado. Para uma primeira comparação de uso, adote os padrões documentados. Identifique-a como comparação de configurações padrão: Hydrogen começa em high, Carbon e Argon em medium.

Uma segunda rodada pode usar um nível comum, como medium, mas nomes iguais não significam a mesma computação interna. Não use xhigh no Carbon ou no Argon: ele não aparece entre os níveis documentados dessas opções.

Defina os critérios antes de ler as respostas. Se todos passarem, escolha pela latência e pelo custo total exigidos pela aplicação. Se um falhar, classifique a causa antes de escalar: falta de evidência, requisição inválida, ambiente quebrado e erro de raciocínio exigem correções diferentes. Repita casos suficientes para entender a variação. Uma resposta vencedora não estabelece um ranking geral confiável.

Verifique acesso e integração antes de culpar o modelo

Camada da API do Google, assinatura do aplicativo Gemini, assinatura do Antigravity e saldo em uma API de terceiros são mecanismos distintos. Ver um modelo em um produto para consumidores não prova que o projeto de API atual consegue chamá-lo. A camada gratuita do Hydrogen também não significa requisições ilimitadas ou o mesmo acesso a ferramentas da camada paga.

Para falhas de acesso e requisição, consulte o guia de acesso ao Argon, em inglês, e o diagnóstico de erros da Gemini API como referência inicial. Depois confirme as condições do modelo atual. Esses artigos tratam de versões e datas específicas; os detalhes não devem ser copiados automaticamente para Hydrogen ou Carbon.

Na Ofox, comece pelo modelo e protocolo que aparecem de fato na sua conta. Esta comparação não confirma que os três modelos ou todos os recursos nativos do Google estejam disponíveis pela Ofox. Consulte a documentação Ofox da Gemini API, para a integração nativa, e o guia de tratamento de erros, para validar requisições. Uma resposta textual bem-sucedida não valida streaming, saída estruturada ou um ciclo completo de ferramenta.

Para uma aplicação nova, o próximo passo é uma tarefa delimitada no Hydrogen, com entrada salva e critérios de aceitação. Em uma aplicação Argon existente, preserve a versão funcional como base. Avalie o Carbon nos casos cuja falha foi atribuída à dificuldade de raciocínio e mantenha-o quando o resultado aprovado justificar o tempo e o gasto adicionais.