O Gemini 4 Carbon e o Hydrogen funcionam melhor em dupla: o Carbon planeja, o Hydrogen constrói. Entregue a Task a um Agente planejador no Carbon, deixe-o criar subtarefas com critérios de aceitação, passe essas etapas para Agentes executores e verificadores no Hydrogen e envie de volta ao planejador qualquer item que falhe duas vezes. Você só paga tarifas de modelos de ponta nos turnos que realmente exigem a capacidade de um modelo de fronteira.
Por que combinar o Gemini 4 Carbon e o Hydrogen?
O Google lançou o Gemini 4 Hydrogen em 12 de novembro de 2026, chamando-o de "o cavalo de batalha do dia a dia para fluxos de trabalho com agentes". Dois dias antes, em 10 de novembro, o changelog da API Gemini anunciou a disponibilidade geral do Gemini 4 Carbon. Com isso, pela primeira vez este mês, é possível colocar o modelo mais poderoso do Google e seu modelo de execução rápida trabalhando na mesma Task.
A própria proposta do Google para o Hydrogen aposta nessa dobradinha. O artigo de lançamento afirma que o Carbon pode atuar como coordenador, enquanto o Hydrogen comanda "agentes executores e verificadores para criar e testar alterações simultaneamente em workspaces isolados". O guia da API Gemini resume de forma ainda mais direta: use o Carbon para planejar interfaces ou resolver bloqueios complexos e, em seguida, delegue edições de código, tarefas paralelas de subagentes e execuções de testes ao Hydrogen.
Esse é um padrão de orquestração, não um recurso do modelo, e você já pode implementá-lo no seu próprio fluxo de trabalho hoje mesmo. Se você prefere que esse fluxo seja gerenciado em um quadro compartilhado em vez de um script rodando em um único computador, o Sharkly é onde as Tasks, os Agentes e as revisões acontecem.
O que o Orchestrator do Google faz, em um parágrafo
O Orchestrator é uma opção de modelo dentro do Google Antigravity que alterna entre um planejador (Carbon ou Argon) e o Hydrogen dentro de uma mesma conversa. De acordo com a documentação do Antigravity, o planejador começa com uma etapa somente leitura, elabora um plano com gatilhos claros de replanejamento e transfere a execução para o Hydrogen. O Hydrogen devolve o controle assim que encontra algum atrito ou obstáculo.
A documentação destaca três sinais de alerta que vale a pena adotar:
- Uma etapa de verificação que falha duas vezes.
- Uma interface que se comporta de maneira diferente do previsto no plano.
- Uma decisão de arquitetura que o plano deixou em aberto.
O Google informa que, no Terminal-Bench, o Orchestrator atingiu uma taxa de sucesso de tarefas próxima à do Carbon, consumindo 24% menos cota e terminando 19% mais rápido em média. Os dois artigos do Google divergem quanto à versão do benchmark (o texto de lançamento cita a 4.0, enquanto o texto do Antigravity fala em 4.1); portanto, mencione apenas como Terminal-Bench até que o Google padronize a informação.
O Orchestrator mantém um único agente na conversa, roda em uma configuração fixa sem controle sobre o nível de raciocínio e, em sua versão com Carbon, está disponível apenas no Google AI Ultra. Já um quadro de equipe divide essa mesma responsabilidade entre múltiplos Agentes, tornando o plano e as passagens de bastão visíveis para todos.
A questão do custo: comparativo de preços entre o Gemini 4 Hydrogen e o Carbon
Preços por token consultados na página de preços da API Gemini em 13 de novembro de 2026:
| Modelo | ID do modelo na API | Entrada / 1M | Saída / 1M | Nível gratuito |
|---|---|---|---|---|
| Gemini 4 Carbon | gemini-4-carbon |
$2,00 até 30 de nov., depois $4,00 | $10,00 até 30 de nov., depois $20,00 | Não |
| Gemini 4 Hydrogen | gemini-4-hydrogen |
$1,50 | $7,50 | Sim, com limite de requisições |
Fique atento às datas antes de planejar seu orçamento com base nisso. Até 30 de novembro, o Hydrogen é apenas 25% mais barato por token do que o Carbon. A partir de 1º de dezembro, ele fica 62,5% mais barato. Ambos os números são cálculos próprios com base nos preços de tabela do Google.
Veja o que isso representa em uma única execução, também segundo nossas contas. Considere um turno de trabalho que lê 200 mil tokens e gera 40 mil (a saída inclui tokens de raciocínio). No Carbon, após 1º de dezembro, isso custará $0,80 + $0,80 = $1,60. No Hydrogen, sai por $0,30 + $0,30 = $0,60. Multiplique isso por 30 vezes ao dia ao longo de uma Sprint e a diferença deixa de ser mero erro de arredondamento.
O preço por token ainda subestima a diferença real. O Google afirma que o Carbon "consome mais tokens de raciocínio por turno para testar hipóteses e verificar casos extremos", e o preço de saída inclui esse raciocínio. Dessa forma, a mesma alteração no Carbon provavelmente consumirá mais tokens de saída, além de aplicar uma taxa mais alta. Como o Google não divulga estimativas de custo por tarefa para a dupla, meça no seu próprio repositório antes de projetar economias.
A velocidade é o outro lado da moeda: o Google relata que o Hydrogen conclui tarefas 2,5 vezes mais rápido do que o Gemini 3.8 Flash em seu nível padrão high.
Dividindo o trabalho na sua equipe de agentes: papéis e modelos
A divisão entre planejador e executor é uma separação formal de trabalho: um Agente assume o plano e as decisões difíceis, Agentes mais econômicos cuidam da execução e um verificador valida o resultado antes da revisão humana. Cada papel recebe o modelo cujo custo e profundidade melhor se adaptam à função.
| Papel | Modelo | Nível de raciocínio | Responsabilidade |
|---|---|---|---|
| Planejador | gemini-4-carbon |
padrão medium, high para Tasks complexas |
Leitura da base de código, criação de subtarefas com critérios de aceitação, replanejamento |
| Executor (1 a n) | gemini-4-hydrogen |
high (padrão) |
Alterações de código, atualização de pacotes, testes, uma subtarefa por vez |
| Verificador | gemini-4-hydrogen |
high, xhigh para diffs arriscados |
Execução de testes e checagens contra os critérios de aceitação do planejador |
| Pessoa | n/a | n/a | Aprovação do plano em Tasks complexas, validação e aceite final do resultado |
Dois detalhes da documentação do Google moldam essa estrutura: o Carbon e o Argon têm como padrão medium e atingem o limite em high, enquanto o Hydrogen adota o padrão high e inclui o nível xhigh. Além disso, o Google alerta que o xhigh eleva a latência e o consumo de tokens, podendo "levar a um excesso de raciocínio em instruções mais simples". Reserve o xhigh para o verificador em diffs críticos que envolvam autenticação, pagamentos ou migrações de dados.
O que o planejador deve documentar?
A saída gerada pelo planejador serve como contrato para todas as etapas seguintes. Um bom plano define uma subtarefa por alteração independente, o escopo de arquivos de cada uma, o comando que comprova seu funcionamento e a condição para devolvê-la ao planejador. Se o executor não souber identificar quando o trabalho está concluído, o plano ainda não está pronto.
Quando o trabalho deve retornar ao planejador?
Adote a lista de gatilhos do Google e torne-a explícita. Um executor devolve a subtarefa quando a verificação falha duas vezes, quando uma interface diverge do planejado ou quando surge uma dúvida de design arquitetural. Ele devolve o item acompanhado do log, do diff gerado até o momento e da pergunta pontual. Ele nunca deve tentar novamente em silêncio usando um modelo mais potente, pois isso mascara o custo do plano econômico na fatura do modelo caro.
Como configurar no Sharkly
No Sharkly, um Agente é um colega de equipe de IA que opera por meio de um Runtime em um Computador conectado, e uma Crew é um grupo de Agentes e Pessoas coordenado por um Agente líder. Isso se encaixa perfeitamente na divisão entre planejador e executor sem necessidade de código adicional. O planejador assume a liderança da Crew, enquanto os executores e o verificador atuam como membros da equipe.
Cada Agente tem seu próprio Runtime e Default model, como exibido no painel acima (que executa o Claude Code). Para essa configuração, forneça a cada Agente um Runtime com acesso à API Gemini, como o Gemini CLI, e defina o modelo de cada um: Carbon para o planejador e Hydrogen para os demais. Se a lista de modelos ainda não exibir os novos identificadores, configure o modelo diretamente nos parâmetros do próprio Runtime. O Gemini CLI também lê a variável de ambiente GEMINI_MODEL, de acordo com sua referência de configuração, e os Agentes aceitam variáveis de ambiente individuais.
Em seguida, escreva as regras de coordenação nas instruções da Crew:
CREW: carbon-plans-hydrogen-builds
Leader: planner (gemini-4-carbon)
1. Read the Task and recent comments. Explore read-only first.
2. Post a plan as a comment: one sub-task per independent change,
file scope, the check command, and the re-plan trigger.
3. If the Task touches more than 3 modules, wait for a person to
approve the plan before mentioning any worker.
4. Mention one worker per sub-task. Mention the verifier last.
Workers: worker-a, worker-b (gemini-4-hydrogen, high)
- Do one sub-task. Run its check. Report the diff and the result.
- If the check fails twice, stop. Report the log and the question
to the leader. Do not widen scope.
Verifier: verifier (gemini-4-hydrogen, high; xhigh for auth/payments)
- Re-run every check from the plan. Pass or fail each one, with output.
A person accepts the result. Nobody merges on an Agent's word.
Atribua a Task à Crew. A execução segue a ordem liderada pelo planejador, conforme a documentação de Crews: o líder lê a Task e as instruções da Crew, menciona os membros para contribuições específicas e os resultados retornam à mesma Task. Use diretórios de trabalho temporários para que cada executor tenha sua própria worktree. Só ative o diretório compartilhado de Tasks da Crew se as subtarefas dependerem diretamente das alterações locais das etapas anteriores.
As tarefas bloqueadas permanecem sempre visíveis: execuções que falharam ou travaram vão para a Inbox, e um Agente aguardando validação humana aparece nos Task Chats da barra lateral. É exatamente aí que termina a seta pontilhada quando o planejador não consegue corrigir o plano por conta própria.
Técnicas avançadas
Aproveite a troca de modelos da API em uma Task extensa. A documentação do Google destaca que é possível direcionar os turnos de planejamento para o gemini-4-carbon e os turnos de execução para o gemini-4-hydrogen dentro de uma mesma sessão multi-turn usando previous_interaction_id, sem alterações de schema. Essa é a mesma estratégia do Orchestrator aplicada ao seu próprio código, muito útil na execução de um único Agente.
Fique atento aos limites por requisição (hop sizes). O Hydrogen retorna até 65.536 tokens por requisição sem streaming, enquanto o Carbon e o Argon retornam 32.768 por chamada REST sem streaming. Mantenha as gerações longas, como suítes de testes e especificações de migração, a cargo do executor.
Abra mão do cache explícito no Hydrogen. O Hydrogen não oferece suporte a cache explícito de contexto. O cache implícito é acionado em prompts com pelo menos 4.096 tokens e oferece 95% de desconto no processamento da entrada em cache; portanto, mantenha o contexto compartilhado do repositório no início do prompt de cada executor.
Alternativas à divisão entre planejador e executor
- Apenas o Hydrogen. Recomendado pela documentação do Google para atualização de pacotes, deduplicação, scaffolding, testes unitários de funções bem definidas e documentação. Dispensa a necessidade de planejador.
- Apenas o Carbon. Indicado para arquitetura de sistemas distribuídos, investigação de race conditions ou migrações entre múltiplos repositórios, onde cada etapa exige profundidade analítica.
- Orchestrator no Antigravity. Uma pessoa, uma conversa, transições automáticas de controle, disponível nos planos compatíveis.
- Roteador estático. Classifica a Task logo no início e a encaminha para um único modelo. O Google argumenta que essa abordagem falha em execuções longas, nas quais o nível de complexidade muda no decorrer do processo. Explicamos a abordagem inicial no artigo sobre como rotear Tasks de agentes com a Gemini Decisions API.
Casos de uso no mundo real
Triagem de issues em larga escala. A demonstração do SDK do Antigravity feita pelo próprio Google combina agentes Hydrogen para triagem e codificação com um agente Carbon encarregado de refatorações, novas funcionalidades e análises de segurança. Em um quadro de tarefas, isso equivale a um Agente Hydrogen na fila de entrada e um líder Carbon para qualquer item classificado como refatoração ou segurança.
Divisão de features em subtarefas paralelas. O planejador desmembra uma alteração de API em atualizações de schema, handlers e clientes; três executores implementam as mudanças em worktrees separadas; por fim, o verificador executa os testes de contrato.
Conclusão
O Carbon planeja, o Hydrogen constrói e uma pessoa valida. A estrutura de preços torna essa divisão vantajosa a partir de 1º de dezembro, os gatilhos de atrito evitam que falhas simples se transformem em repetições caras em modelos de ponta, e o quadro mantém cada passagem de bastão registrada na Task, visível para toda a equipe. Para conhecer o padrão geral com mais detalhes, leia o que é orquestração de agentes de IA e nosso artigo sobre regras de roteamento de modelos para Crews.
Seu próximo passo: conecte um Computador ao Sharkly, crie um Agente planejador no Carbon e um executor no Hydrogen, configure ambos em uma Crew com as instruções acima e atribua a ela uma Task que você normalmente levaria uma tarde para concluir. O Sharkly oferece um plano gratuito, logo o único custo do teste será o consumo de tokens do Gemini.
FAQ
Qual é a diferença entre o Gemini 4 Carbon e o Hydrogen?
O Carbon é o modelo de fronteira mais poderoso do Google, desenvolvido para raciocínio de longo alcance e desafios complexos de arquitetura, depuração e segurança. O Hydrogen é o modelo ágil e eficiente da linha Gemini 4, ideal para codificação rotineira e execução por agentes. O Carbon vem configurado por padrão com raciocínio medium, com limite máximo em high; o Hydrogen adota high como padrão e adiciona a opção xhigh.
O Gemini 4 Hydrogen é mais barato que o Carbon?
Sim. O Hydrogen custa $1,50 por 1M de tokens de entrada e $7,50 por 1M de saída. O Carbon custa $2 e $10 até 30 de novembro de 2026, passando para $4 e $20 a partir de 1º de dezembro. O Hydrogen também conta com um nível gratuito com limite de requisições na API Gemini; o Carbon não.
O verificador deve rodar no Carbon em vez do Hydrogen?
Não necessariamente por padrão. O Google posiciona o Hydrogen tanto para agentes executores quanto para verificadores paralelos. Utilize xhigh no verificador para diffs de alto risco e escale a Task para o planejador no Carbon apenas quando uma checagem falhar duas vezes.
O Sharkly escolhe o modelo para cada Task?
Não. Você define o modelo de cada Agente por meio de seu Runtime, e as instruções da Crew determinam qual Agente assume cada etapa da Task. O Sharkly gerencia a Task, as execuções, as passagens de bastão e o processo de revisão.
