A Decisions API do Google responde a 1.000 perguntas e não cobra pela saída

A parte mais barata do Gemini Decision 1 é a parte que não existe. O Google colocou o modelo por trás de uma nova Gemini Decisions API em 11 de novembro de 2026, e a página de preços lista o preço de saída como zero — nem barato, nem com desconto, ausente, porque POST /v1beta/decisions não tem prosa a gerar. Você envia um bloco de entrada compartilhada mais até 1.000 perguntas tipadas; recebe de volta uma resposta calibrada por pergunta e nada mais. O número do ranking chamou a atenção no dia do lançamento. A linha de cobrança é a que muda o que você constrói, e vale a pena fazer as contas antes de copiar o diagrama de arquitetura de alguém.

Todas as outras decisões de modelo que você tomou nos últimos dois anos foram moldadas por dois custos puxando em direções opostas: entrada que você quer enviar uma vez e saída que você quer manter curta. Este endpoint elimina totalmente a segunda tensão e a substitui por uma diferente, interna a uma única requisição. Quando você percebe onde a nova tensão está, o restante do design da API — o teto de perguntas, o contexto compartilhado, a ausência de cache — deixa de parecer arbitrário.

O que zero tokens de saída faz com a aritmética

Considere uma tarefa realista de pontuação de documentos: uma política ou um contrato de 40.000 tokens e 1.000 perguntas para as quais você quer respostas. Uma solicitação à Decisions API cobra 40.000 tokens de entrada uma única vez, a US$ 0,10 por milhão, o que equivale a quatro décimos de centavo — US$ 0,004 por todas as mil respostas.

Agora faça as mesmas 1.000 perguntas da forma como as teria feito uma semana antes, como 1.000 chamadas generate-content separadas. Cada chamada precisa carregar o documento, porque um endpoint de chat não tem como mantê-lo entre chamadas. Isso dá 40 milhões de tokens de entrada, ou US$ 4,00 na mesma taxa por token, e a diferença aumenta quando você adiciona os tokens de saída que cada uma dessas chamadas teria produzido. O envelope não é um recurso de conveniência. É uma diferença de custo mil vezes maior para o mesmo trabalho, e vem de uma única escolha de design: as perguntas são avaliadas em relação a um contexto compartilhado em uma única passagem, não uma por ida e volta.

Essa aritmética também indica o formato da carga de trabalho que este modelo deseja. Muitas perguntas sobre um único objeto grande, respondidas em conjunto. Se suas perguntas forem sobre 1.000 objetos diferentes, você terá 1.000 solicitações e nenhuma economia.

O envelope: 262.144 tokens, compartilhados, e limitado a 1.000 perguntas

A janela de contexto cobre a entrada compartilhada e todas as perguntas da solicitação juntas, em 262.144 tokens. Dentro desse orçamento, você pode fazer entre 1 e 1.000 perguntas. O número que importa é o limite superior: 1.000 perguntas em uma única chamada não é território de classificador, é o equivalente a um motor de regras de julgamento comprimido em uma única passada. Um ticket de suporte pode ser verificado em relação a quarenta cláusulas de política; um arquivo de empréstimo pode ser testado em relação a todas as regras de subscrição de uma só vez.

Duas propriedades do formato da solicitação são fáceis de passar despercebidas e caras de descobrir mais tarde. As perguntas são avaliadas independentemente — a resposta de uma pergunta não condiciona a próxima, portanto você não pode encadear raciocínio fazendo uma pergunta de acompanhamento que dependa de uma resposta anterior. E o modelo nunca vê as chaves das suas perguntas, apenas o texto de instrução que você escreve, portanto as chaves servem para seu próprio controle e as instruções precisam ser autossuficientes.

Três formas de pergunta e a armadilha dentro de cada uma

• Sim/não — o tipo noul retorna uma probabilidade entre 0,01 e 0,99, além de uma pontuação de confiança. O limite é fixado em ambas as extremidades, então um limite de roteamento definido em 0,995 nunca será acionado, não importa quão certo o modelo esteja. Escolha limites dentro do intervalo que a API realmente pode retornar.

• Escolha — duas a 255 opções nomeadas, retornando a opção vencedora, uma probabilidade para cada opção que soma um e um nível de confiança. Antes da pontuação, a API classifica as chaves das suas opções em ordem alfabética conforme a ordem de bytes UTF-8, o que significa que a ordem das chaves JSON é irrelevante e um empate exato é resolvido em favor da chave que for classificada primeiro. A recomendação do Google decorre disso: nomeie sua opção genérica como other, porque um nome como none_of_the_above é classificado antes da maioria das categorias reais e vencerá empates que deveria perder.

• Pontuação — de dois a 255 níveis de rubrica ordenados, com dois a dez recomendados. O valor retornado é um nível esperado ponderado por probabilidade e, como o valor esperado calcula a média dos índices do array em vez dos rótulos, uma escala escrita como 1/10/100/1000 produz um número que não está na sua escala. Mantenha a rubrica uniformemente espaçada em termos de índice ou converta o índice esperado de volta para um rótulo você mesmo.

O que a documentação indica como indisponível

As lacunas estão todas na mesma direção: trata-se de um endpoint de disparo único, sem nada em volta. Não há cache de contexto, então um documento de política reutilizado entre requisições é cobrado novamente por inteiro a cada vez. Não há Batch API, o que descarta uma varredura noturna pela metade do preço dos chamados do ano passado. Não há nível Flex nem Priority. O modelo está apenas na Gemini Developer API, na versão v1beta, sem listagem no Vertex AI na documentação fornecida pelo Google — um detalhe que importa para quem tem o processo de compra via contrato de nuvem em vez de chave de API.

A mídia é excepcionalmente ampla e excepcionalmente limitada ao mesmo tempo. Texto, imagem, vídeo, áudio e PDF cabem todos em uma única solicitação. Os limites são 100 MB de base64 inline, 50 MB para um PDF e 15 MB por URL HTTPS externa. Links do YouTube não são aceitos, nem URIs gs://; você passa referências de arquivos enviados, URLs assinadas ou bytes.

Os limites de taxa começam em 200 solicitações e 50.000 tokens por minuto no nível gratuito, passam para 1.500 e um milhão no Nível 1, e chegam a 5.000 solicitações e quatro milhões de tokens por minuto no Nível 2, sem limite diário de solicitações. O nível gratuito é isento de cobrança, mas está documentado como usado para melhorar os produtos do Google, o que o desqualifica para qualquer coisa sob uma cláusula de confidencialidade.

A pontuação, em resumo

No Artificial Analysis Decision Index v2.1, o modelo fica em 66 — 65,98 sem arredondamento — em nono lugar entre os dezoito modelos de decisão classificados pelo painel. É o primeiro isolado em dois dos seis componentes, AA-Omniscience-Decision v1.1 e HLE-MultiChoice v1.1, ambos com peso de 15%, e fica no meio da tabela em AA-Paperclip, com peso de 30%, que é o componente que determina a maior parte do composto. O custo medido é de US$ 345 por milhão de tarefas e a latência é de 211 milissegundos por tarefa, contra uma mediana do segmento de 209. O Google não publicou nenhuma tabela de benchmark própria junto com o lançamento; todos os números de desempenho aqui são do painel independente, em seu próprio harness. A aritmética por trás do 66 é uma questão separada e um artigo separado.

Integrando-o a um pipeline que você já roteia

O OrcaRouter não oferece o gemini-decision-1, e o motivo é estrutural, não comercial: um endpoint apenas de probabilidades não é um alvo de chat-completions, então não há nada que um roteador no nosso formato possa colocar por trás de uma única chave. A metade do pipeline para a qual existimos é a outra metade. Um serviço de decisão quase sempre envolve duas chamadas — algo redige a resposta candidata, a rubrica ou a lista de pré-selecionados, e algo a pontua —, e é na chamada de redação que a escolha do modelo é de fato disputada.

Essa chamada pode ser executada em mais de 200 modelos em um único endpoint, pelo preço de tabela do provedor repassado com 0% de markup, então quando um fornecedor reduz um preço, o novo número fica ativo do nosso lado no mesmo dia, e não no próximo ciclo de cobrança. A fusão de modelos se justifica aqui de uma forma que não se aplica em uma interface de chat: dois geradores de rascunho produzem respostas candidatas concorrentes, e a Decisions API pontua ambas com a mesma rubrica em uma única requisição, o que transforma um teste A/B em uma decisão por registro.

Vale a pena ser preciso sobre failover também. O failover automático protege a chamada generativa — se o provedor por trás do seu modelo de redação retornar erros, a solicitação é redirecionada e o pipeline continua avançando. Ele não consegue proteger a chamada de pontuação, porque há exatamente um lugar para enviá-la. Se o endpoint de decisões estiver fora do ar, seu pipeline estará fora do ar, e nenhuma quantidade de roteamento muda isso. Projete a metade de redação para ser resiliente e aceite que a metade de pontuação é uma dependência.

Conclusão

A Decisions API vale a pena ser adotada por um motivo, e não é a posição no leaderboard: ela reduz mil idas e voltas a uma única entrada faturada, e isso muda quais perguntas saem baratas de fazer. Construa sobre ela se seus problemas se parecerem com muitos julgamentos sobre um único objeto grande — um contrato, um arquivo de sinistro, uma hora de vídeo — e espere manter seus prompts dentro de uma única requisição, porque tudo o que a torna barata acontece entre o primeiro e o último token de uma única chamada. Se seus problemas se parecerem com uma pergunta sobre mil objetos pequenos, o envelope não lhe compra nada e a tarifa de entrada é simplesmente três vezes o que cobra um modelo de decisão mais barato.