Gemini Decision vs Gemini Decision 1: Um é um nome, o outro é um ID de modelo

Pesquise por Gemini Decision e você encontrará cobertura de lançamento, uma entrada no ranking, uma linha de preços e uma referência de API, todos usando palavras um pouco diferentes para a mesma coisa. Pesquise por Gemini Decision 1 e você encontrará o ID do modelo que realmente funciona. As duas strings diferem por um único caractere e se comportam de forma completamente diferente no código: uma é como as pessoas chamam o produto, e a outra é o único valor que POST /v1beta/decisions aceitará. Se você já passou uma tarde em um 404 se perguntando por que um modelo que claramente existe não pode ser encontrado, este é o artigo que teria salvado sua tarde.

The confusion is not anyone's mistake in particular. G​oogle shipped a model, an endpoint and a family name in the same release on 11 November 2026, and the natural way to write about all three is to shorten them. The shortening works in prose and fails in a request body, and the gap between those two facts is where most of the support tickets in this category will come from over the next month.

Para o que os dois nomes são resolvidos

Comece pelo mapeamento, porque todo o resto decorre dele.

• Gemini Decision — a product name. It refers to the decision-model line, and in G​oogle's own documentation it appears as the family label in prose, in the model card heading, and in sentences like "available with G​emini Decision only". It is not a model id, there is no alias behind it, and passing it as model returns an unknown-model error rather than falling back to the newest member of the family.

• Gemini Decision 1 — the model, and the id gemini-decision-1. This is the value that works. It is the only model the Decisions API serves, and the documentation says so explicitly: the endpoint is available with G​emini Decision 1 only.

Two names, one model, and no alias between them. That last part is the unusual bit. Most G​oogle model families offer a moving alias and a pinned id — a -latest form for prototypes and a dated or numbered form for production. This one offers only the pinned form, so any code path built on the assumption that families have a floating head will fail here rather than silently tracking a new version.

Onde o segundo nome continua aparecendo

A razão pela qual a ambiguidade persiste é que três sistemas separados descrevem este modelo e nenhum deles compartilha uma convenção de nomenclatura.

A página de preços o lista sob o próprio nome do modelo, ao lado de uma tarifa e de uma observação de que a saída não é aplicável. A referência da API descreve o endpoint e nomeia o modelo na frase de disponibilidade, e não em uma tabela de modelos. O ranking independente que o avalia usa o nome legível em sua linha e em seu gráfico. Nenhum deles está errado, e nenhum deles é um ID de modelo, então copiar de qualquer um deles para o corpo de uma solicitação produz a mesma falha.

Há uma quarta fonte de variação que será cada vez mais importante com o passar do tempo: a escrita de outras pessoas. Coberturas de lançamento, tutoriais e respostas em fóruns encurtam o nome, e alguns deles o encurtam para algo que parece um id — minúsculo, com hífen, plausível. A solução não é confiar em nenhum deles. Consulte o endpoint.

Como verificar o que uma determinada chave pode realmente chamar

Antes de escrever uma solicitação, liste os modelos aos quais a chave tem direito. A chamada padrão list-models na API Generative Language retorna os modelos disponíveis para o seu projeto com seus IDs, e executá-la uma vez resolve a questão permanentemente para essa chave.

Se gemini-decision-1 aparecer, você tem acesso, e é exatamente essa string que vai na requisição. Se não aparecer, o problema é de permissão de acesso ou de região, e não de grafia, e nenhuma quantidade de renomeação vai ajudar. O que você não encontrará nessa lista é uma entrada chamada gemini-decision, porque não existe tal modelo.

A segunda verificação é na resposta. Uma resposta de decisão bem-sucedida identifica o modelo que a atendeu, então um pipeline que registra o campo model junto com seu próprio request id consegue responder "qual modelo produziu esta resposta" meses depois sem reler a configuração. Isso parece tarefa de manutenção até a primeira vez que alguém pergunta por que uma decisão mudou e a resposta honesta é que um alias mudou.

Os três erros que essa ambiguidade realmente causa

• O 404 de modelo desconhecido. O óbvio. gemini-decision no corpo da solicitação retorna um erro que parece um problema de permissões, mas não é. Se o erro mencionar o modelo em vez do projeto, verifique a string antes de verificar a conta de cobrança.

• A suposição silenciosa de alias. Mais difícil de detectar. Uma equipe que internalizou convenções -latest escreve uma configuração com um nome de família e uma etapa de resolução, e a etapa de resolução retorna silenciosamente o nome literal da família quando não existe alias. A falha então aparece na primeira solicitação real, em vez de no deploy, que é o pior momento possível para isso.

• A suposição do endpoint errado. Ainda mais sutil, porque o modelo existe e o nome está correto: gemini-decision-1 enviado a um endpoint comum de generate-content ainda falha. O modelo não pode ser chamado dessa forma de jeito nenhum. Ele é um alvo somente de probabilidades no endpoint de decisões, e uma requisição que lhe pede texto está pedindo algo que ele não produz. Qualquer biblioteca de cliente que use chat completions por padrão precisará de um caminho explícito.

O que isto diz sobre o modelo, não apenas o seu nome

A nomenclatura é um sintoma da decisão de design real, que é que este não é um modelo de chat com um formato de saída diferente. Um modelo de chat retorna texto, então seu id pode ser trocado livremente entre provedores, proxies e gateways que todos falam o mesmo esquema. Um modelo que retorna probabilidades calibradas sobre suas próprias perguntas tipadas não tem esse esquema comum, e o id está vinculado a um endpoint com um formato de requisição.

É por isso que a família ainda não tem alias flutuante nem um segundo membro: não há nada com que ser compatível. Isso também explica por que o modelo não pode simplesmente ser adicionado a um roteador de propósito geral. O OrcaRouter não inclui gemini-decision-1, porque um endpoint somente de probabilidades não é um alvo de chat-completions, e colocá-lo atrás de uma chave que fala esse schema seria uma promessa que a camada de roteamento não consegue cumprir. O que de fato incluímos no espaço de decisão é typesafe/jev-1.14 da TypeSafe, um modelo de decisão que pode ser chamado pela mesma interface que todo o resto do catálogo.

A parte de um pipeline de decisão que o roteador de fato atende é a metade de elaboração — a chamada generativa que produz a resposta candidata ou a rubrica que o avaliador então avalia. Essa chamada é executada em mais de 200 modelos em um único endpoint, com o preço de lista do provedor repassado com 0% de margem, e é a chamada em que trocar de fornecedor é uma mudança de configuração, e não uma reescrita. A chamada de pontuação, por outro lado, está vinculada a um único endpoint por design, e a arquitetura honesta a trata como uma dependência fixa, e não como algo em torno do qual rotear.

Se você estiver escolhendo entre as duas strings em um formulário

There is a version of this question that is not about identifiers at all, and it is worth answering directly because the phrasing invites it: someone comparing "G​emini Decision" with "G​emini Decision 1" may believe they are looking at two products, an older one and a newer one, and want to know which to adopt. There is only one. Nothing called G​emini Decision shipped before G​emini Decision 1, and the shorter name is the family label for a family that currently has a single member.

A consequência prática é que qualquer tabela comparativa, avaliação ou benchmark que você encontrar e que liste os dois como entradas separadas está descrevendo o mesmo modelo duas vezes. Duas linhas, um modelo, um preço. Se as duas linhas divergirem em um número, uma delas está desatualizada, em vez de estar medindo algo diferente.

Conclusão

Use gemini-decision-1 in every request body, endpoint path and config value, and use "G​emini Decision" only where a human reads it. There is no alias to fall back on, no second model hiding behind the shorter name, and no chat-completions path to the longer one. The cost of getting this wrong is small — one 404, one confused afternoon — but the cost of assuming an alias exists is larger, because that mistake survives review and fails in production. Pin the id, log the model the response names, and treat the family name as prose.