Uma execução de agente com 1 milhão de tokens é um problema de revisão, não um ganho de velocidade

O Gemini 4 Argon está disponível publicamente desde 13 de outubro de 2026 e eleva o limite máximo de saída do Google de 64 mil tokens para cerca de 1 milhão, permitindo que o modelo consiga “gerar centenas de milhares de tokens em uma única trajetória”. O guia para desenvolvedores do Google explica como isso funciona. Por padrão, uma requisição normal ainda é interrompida em 65.536 tokens de saída. Se você definir um valor maior para max_output_tokens na Interactions API com background: true, o servidor continuará gerando em blocos de até 64 mil tokens até atingir o limite de 1.048.576 tokens, subtraídos os seus tokens de entrada. O Google alerta que prompts mais complexos podem levar minutos.

O trecho do artigo de lançamento que realmente merece uma releitura atenta não é o novo teto em si, mas sim o que o Google fez com um volume de saída desse tamanho. A empresa afirma ter utilizado o Argon internamente em migrações de C/C++ para Rust que variam desde “dezenas de milhares de linhas em bibliotecas essenciais como re2 e libgav1 até mais de 800 mil linhas no kernel Fuchsia Zircon”, e que essas reescritas estão “passando por rigorosa auditoria manual e automatizada, testes em emulação e revisão antes de serem disponibilizadas em produção”. Até mesmo o laboratório responsável por treinar o modelo faz revisões antes de lançar o código. Uma equipe cujos agentes agora conseguem entregar resultados sob um teto dezesseis vezes maior precisa de um plano de revisão bem antes de precisar do modelo.

TL;DR

Um limite de saída de um milhão de tokens transfere o gargalo da geração de código para a aprovação dele. Agora que uma única execução pode entregar tanto volume, divida o trabalho em Tarefas que uma pessoa consiga revisar de uma só vez — cada uma com uma definição de pronto documentada e um tempo limite por Tarefa —, exija comprovações em cada Tarefa e calcule primeiro a sua capacidade de revisão. Os agentes pesquisam, executam, testam e relatam. As pessoas definem o direcionamento, concedem autorizações e aprovam o resultado.

O que muda quando uma única execução pode retornar tanto assim

A capacidade de revisão é a quantidade de resultados concluídos por agentes que uma equipe consegue ler, avaliar e aprovar em um dia — e esse ritmo é determinado por pessoas, não pelo modelo. Um limite de saída maior só aumenta o volume que pode chegar de uma só vez.

O teto antigo funcionava como um controle involuntário de escopo: uma resposta só podia ter um certo tamanho, de modo que o trabalho retornava em partes, com pontos de parada entre elas. A justificativa do Google para o novo limite aponta na direção oposta, buscando margem para “resolver problemas difíceis de uma só vez”. Para quem revisa, “de uma só vez” significa um único resultado, uma única decisão e nenhum ponto de checagem intermediário onde alguém poderia dizer: “está na direção errada”.

Esse teto também é compartilhado. A janela de 1.048.576 tokens do Argon engloba entrada, raciocínio e saída conjuntamente; portanto, uma execução que lê 300 mil tokens de código fica com cerca de 748 mil tokens para pensar e escrever. Ainda assim, é muito mais do que qualquer pessoa consegue ler linha por linha em uma única sessão.

Além disso, há a questão da qualidade. No momento do anúncio, a Bloomberg noticiou que funcionários do Google afirmaram, sob anonimato, que o Argon decepciona em algumas tarefas de código e front-end em comparação aos seus benchmarks; o Google declarou que essa alegação é incorreta. A própria tabela do Google mostra o Argon atrás em duas das suas quatro métricas de codificação por agentes (nossa comparação detalha cada uma). Um benchmark é uma alegação sobre uma base de testes. O seu diff é uma afirmação sobre a sua base de código, e ele é aprovado com base em evidências, não importa qual modelo o tenha escrito.

Defina o escopo da Tarefa, não o orçamento de tokens

A unidade que você controla é a Tarefa, não a contagem de tokens. Se deixar o limite do modelo ditar o tamanho do trabalho, você receberá o maior resultado que ele for capaz de gerar. Se você mesmo definir esse escopo, receberá resultados que uma pessoa consegue aprovar. A própria orientação do Google concorda: mantenha o padrão de 65.536 para tarefas rotineiras e use o modo de segundo plano com 131.072 ou 262.144 tokens para raciocínio complexo e programação, em vez de recorrer ao limite máximo.

A própria descrição do Google já reparte o trabalho por biblioteca e kernel. Divida uma portabilidade da mesma forma: uma Tarefa por módulo que um revisor consiga analisar em uma única sessão. No Sharkly, isso corresponde a uma Tarefa principal com uma subtarefa para cada módulo, além de vínculos de “bloqueia / é bloqueada por” quando um módulo precisa ser integrado antes de outro. Objetivo, escopo e critérios de aceitação ficam registrados na descrição da Tarefa, servindo tanto ao Agente quanto ao revisor:

SH-412  Port the tokenizer module to Rust
Parent: SH-400  Port the parser library to Rust
Blocked by: SH-411  Port the shared buffer types

Done when:
- the Rust module replaces src/tokenizer/ and nothing outside it changes
- the existing test suite passes against the Rust build without edits
- a differential run over the fixture corpus produces identical output
- the report lists every unsafe block and the reason for it
Out of scope: public API changes, performance work

Duas configurações do Agente sustentam essa estratégia. O tempo limite por Tarefa deve se adequar à Tarefa, e não ao modelo: ele deve ser superior à execução razoável mais longa de um módulo, mas inferior ao tempo de uma execução que você se arrependeria de pagar. A simultaneidade máxima (tarefas atribuídas) limita quantos módulos ficam em andamento ao mesmo tempo, já que quarenta subtarefas rodando juntas geram quarenta resultados à espera do mesmo revisor.

O critério de decisão é duplo: confie o trabalho inteiro a uma única execução quando checagens automatizadas conseguirem cobrir todo o resultado — como uma renomeação mecânica garantida pelo compilador e por uma suíte completa de testes. Divida o trabalho quando uma pessoa precisar avaliar qualquer parte dele, o que, em uma migração de linguagem, é quase tudo. Execuções que ultrapassam o seu expediente exigem as mesmas pré-condições: uma condição de parada, um estado de espera e alguém responsável por acompanhar os resultados na manhã seguinte.

Anexe as evidências à Tarefa

Um resultado volumoso sem evidências não é uma revisão. É uma reexecução manual e lenta conduzida por uma pessoa.

O exemplo da libgav1 demonstra como são evidências de qualidade. O Google afirma que o Argon substituiu 32 mil linhas de código SIMD em uma portabilidade existente para Rust, e que o resultado “roda 2,7 vezes mais rápido do que a versão em Rust, com saída de vídeo idêntica”. A segunda metade dessa frase é exatamente o que torna 32 mil linhas revisáveis: as mesmas entradas passaram pelo código antigo e pelo novo, e os resultados foram equivalentes. Isso é teste diferencial, e é o que libera o revisor para focar naquilo que uma comparação automática não alcança: blocos inseguros de código, caminhos de tratamento de erro e se o ganho de desempenho se sustenta em cargas de trabalho reais.

Toda execução deve retornar quatro itens para a Tarefa:

Essa é a estrutura prevista pelo fluxo de trabalho do Sharkly: o Agente executa a checagem de tipos, os testes e o build, anexando em seguida o resumo das alterações, os resultados da validação e as limitações conhecidas; uma pessoa aprova, solicita ajustes ou define as etapas de merge e deploy. A resposta final do Agente fica armazenada na Tarefa e o log de execução permanece na aba Executions, garantindo que as evidências retornem à Tarefa em vez de ficarem perdidas em um terminal. O artigo sobre revisão com evidências em nível de tarefa orienta sobre a ordem de leitura, e os modelos de transição padronizam o formato do relatório.

Passar nas verificações automatizadas não equivale a aceitação, e o mesmo vale para um merge: no Sharkly, mesclar um pull request vinculado não altera o status da Tarefa. As verificações automáticas validam o que lhes cabe, e o artigo sobre agentes de revisão de código com IA mostra onde essa capacidade termina. Cabe a uma pessoa decidir se a alteração cumpre o que a Tarefa solicitava.

Calcule a capacidade de revisão antes da execução

A revisão é uma fila: os resultados chegam, uma pessoa os processa e, se o volume de chegada superar o de liberação, a fila cresce. Um limite maior de saída altera unicamente a taxa de chegada. Veja um exemplo prático com valores hipotéticos:

Avaliando apenas o diff, a migração consome 80 horas de revisão — cerca de 27 dias úteis. Com evidências anexadas a cada Tarefa, esse tempo cai para 20 horas, cerca de sete dias. Seja em uma única execução colossal ou em quarenta execuções menores, a demanda de trabalho do lado do revisor continua a mesma.

O que muda é a tomada de decisão. Quarenta Tarefas chegam a um ritmo que você controla, e cada uma recebe o seu próprio veredito. Já um resultado abrangendo todos os quarenta módulos recebe uma decisão única; logo, uma falha no módulo 31 compromete os outros 39. Com subtarefas, uma observação na que falhou permite iniciar uma execução complementar naquela Tarefa específica enquanto o restante avança.

Em seguida, calcule os custos. Uma execução no teto máximo gera cerca de 1 milhão de tokens de saída: aproximadamente US$ 10 pela tarifa de US$ 10 por milhão até 30 de novembro, e cerca de US$ 20 a partir de 1º de dezembro. Em um projeto de Tier 1, o limite de gastos do Google é de US$ 10 por janela móvel de 10 minutos; assim, uma única execução no limite consome todo o teto de uma janela na tarifa atual e o dobro desse limite a partir de 1º de dezembro. Mantenha a simultaneidade máxima baixa em qualquer Agente autorizado a rodar execuções dessa extensão.

Faça as contas do seu cenário antes da primeira grande execução, e não após a fila se formar. O artigo sobre cálculo de capacidade de revisão explica essa mesma lógica no âmbito da equipe, e o texto sobre a revisão humana como gargalo trata dos status e das etapas de controle que tornam essa fila visível.

Checklist antes da sua primeira execução de um milhão de tokens

• [ ] O trabalho está dividido em Tarefas que um revisor consegue concluir de uma só vez, com subtarefas e vínculos de "bloqueada por".
• [ ] A descrição de cada Tarefa especifica o que significa concluído e o que está fora de escopo.
• [ ] O tempo limite por Tarefa é adequado à Tarefa (requisições longas em segundo plano levam minutos), e não ao teto de saída do modelo.
• [ ] Uma execução no limite máximo se enquadra no limite de gastos do seu nível de API.
• [ ] A simultaneidade máxima do Agente para Tarefas atribuídas corresponde ao que os revisores conseguem liberar, e não ao que o computador é capaz de rodar.
• [ ] Toda execução retorna um resumo das alterações, a saída das checagens, o que foi verificado e as limitações conhecidas.
• [ ] O trabalho de preservação de comportamento traz uma checagem diferencial em relação ao código legado.
• [ ] Cada Tarefa conta com um revisor designado, e a aceitação é formalizada pela alteração de status por essa pessoa, nunca como efeito colateral de um merge.

Nada disso depende exclusivamente do Argon, que já pode ser chamado por qualquer chave de API paga do Gemini. O roteiro do Google serve de referência: saída extensa, seguida de auditoria, testes de emulação e revisão, e só então produção. Não importa qual laboratório apresente o próximo salto no volume de saída, o planejamento precisa residir na Tarefa, e não no modelo. O Sharkly não determina modelos: de acordo com a documentação sobre Agentes, um Agente acompanha o modelo padrão de seu Runtime, configurável por meio de Custom arguments ou nos parâmetros da ferramenta. Quando um modelo maior passa a integrar um Runtime que você opera, esse valor se atualiza, enquanto as Tarefas, as evidências e o controle de revisão permanecem inalterados. Contexto, progresso, bloqueios, resultados e revisão humana continuam transparentes desde a solicitação inicial até o deploy.

Se você já opera vários agentes, o Sharkly oferece uma plataforma centralizada para gerenciar suas tarefas e resultados.