Gemini Decision vs Gemini Decision 1: uno es un nombre, el otro es un ID de modelo

Busca Gemini Decision y encontrarás cobertura del lanzamiento, una entrada en la clasificación, una fila de precios y una referencia de API, todo con palabras ligeramente distintas para lo mismo. Busca Gemini Decision 1 y encontrarás el id de modelo que realmente funciona. Las dos cadenas difieren en un solo carácter y se comportan de forma completamente distinta en el código: una es lo que la gente llama el producto, y la otra es el único valor que aceptará POST /v1beta/decisions. Si te has pasado una tarde con un 404 preguntándote por qué no se encuentra un modelo que claramente existe, este es el artículo que te lo habría ahorrado.

La confusión no es un error de nadie en particular. Google lanzó un modelo, un endpoint y un nombre de familia en el mismo lanzamiento el 11 de noviembre de 2026, y la forma natural de escribir sobre los tres es abreviarlos. La abreviatura funciona en prosa y falla en el cuerpo de una solicitud, y la brecha entre esos dos hechos es de donde provendrán la mayoría de los tickets de soporte de esta categoría durante el próximo mes.

A qué resuelven los dos nombres

Empieza con el mapeo, porque todo lo demás se deriva de él.

• Gemini Decision — un nombre de producto. Se refiere a la línea de modelos de decisión y, en la propia documentación de Google, aparece como la etiqueta de la familia en la prosa, en el encabezado de la ficha del modelo y en frases como «disponible solo con Gemini Decision». No es un id de modelo, no hay ningún alias detrás y, si se pasa como model, devuelve un error de modelo desconocido en lugar de recurrir al miembro más reciente de la familia.

• Gemini Decision 1 — el modelo, y el id gemini-decision-1. Este es el valor que funciona. Es el único modelo que ofrece la API de Decisions, y la documentación lo dice explícitamente: el endpoint está disponible solo con G​emini Decision 1.

Dos nombres, un modelo y ningún alias entre ellos. Esa última parte es lo inusual. La mayoría de las familias de modelos de G​oogle ofrecen un alias móvil y un id fijado —una forma -latest para prototipos y una forma fechada o numerada para producción. Esta solo ofrece la forma fijada, así que cualquier ruta de código construida sobre la suposición de que las familias tienen una cabeza flotante fallará aquí en lugar de rastrear silenciosamente una nueva versión.

Donde el segundo nombre sigue apareciendo

La razón por la que la ambigüedad tiene recorrido es que tres sistemas distintos describen este modelo y ninguno de ellos comparte una convención de nomenclatura.

La página de precios lo incluye bajo el nombre propio del modelo, junto con una tarifa y una nota de que la salida no aplica. La referencia de la API describe el endpoint y nombra el modelo en la frase de disponibilidad en lugar de en una tabla de modelos. La clasificación independiente que lo evalúa usa el nombre legible en su fila y en su gráfico. Ninguno de estos es incorrecto, y ninguno de ellos es un id de modelo, así que copiar cualquiera de ellos en el cuerpo de una solicitud produce el mismo fallo.

Hay una cuarta fuente de variación que importará más con el paso del tiempo: los escritos de otras personas. La cobertura del lanzamiento, los tutoriales y las respuestas de los foros acortan el nombre, y algunos de ellos lo reducen a algo que parece un id: en minúsculas, con guiones, verosímil. La solución no es confiar en ninguno de ellos. Pregúntale al endpoint.

Cómo comprobar qué puede llamar realmente una clave determinada

Antes de escribir una solicitud, enumera los modelos a los que tiene derecho la clave. La llamada estándar list-models de la API Generative Language devuelve los modelos disponibles para tu proyecto con sus ids, y ejecutarla una vez resuelve la cuestión de forma permanente para esa clave.

Si aparece gemini-decision-1, tienes acceso, y esa cadena exacta es la que va en la solicitud. Si no aparece, el problema es de entitlement o de región, no de escritura, y ningún cambio de nombre lo va a solucionar. Lo que no encontrarás en esa lista es una entrada llamada gemini-decision, porque ese modelo no existe.

La segunda comprobación se realiza sobre la respuesta. Una respuesta de decisión exitosa identifica el modelo que la atendió, así que un pipeline que registra el campo del modelo junto con su propio id de solicitud puede responder «qué modelo produjo esta respuesta» meses después sin volver a leer la configuración. Eso suena a tarea de mantenimiento hasta la primera vez que alguien pregunta por qué cambió una decisión y la respuesta honesta es que se movió un alias.

Los tres errores que esta ambigüedad realmente provoca

• El 404 de modelo desconocido. El más obvio. gemini-decision en el cuerpo de la solicitud devuelve un error que parece un problema de permisos y no lo es. Si el error menciona el modelo en lugar del proyecto, revisa la cadena antes de revisar la cuenta de facturación.

• La suposición silenciosa del alias. Más difícil de detectar. Un equipo que ha interiorizado las convenciones de -latest escribe una configuración con un nombre de familia y un paso de resolución, y el paso de resolución devuelve discretamente el nombre de familia literal cuando no existe ningún alias. El fallo entonces aparece en la primera solicitud real en lugar de en el despliegue, que es el peor momento posible para que ocurra.

• La suposición del endpoint equivocado. Aún más sutil, porque el modelo existe y el nombre es correcto: gemini-decision-1 enviado a un endpoint generate-content ordinario sigue fallando. El modelo no se puede invocar de esa manera en absoluto. Es un objetivo de solo probabilidades en el endpoint de decisiones, y una solicitud que le pide prosa está pidiendo algo que no produce. Cualquier biblioteca cliente que use chat completions por defecto necesitará una ruta explícita.

Lo que esto dice sobre el modelo, no solo su nombre

La denominación es un síntoma de la verdadera decisión de diseño: este no es un modelo de chat con un formato de salida diferente. Un modelo de chat devuelve texto, por lo que su id se puede intercambiar libremente entre proveedores, proxies y pasarelas que hablan el mismo esquema. Un modelo que devuelve probabilidades calibradas sobre tus propias preguntas tipadas no tiene ese esquema común, y el id está vinculado a un único endpoint con una única forma de solicitud.

Por eso la familia aún no tiene un alias flotante ni un segundo miembro: no hay nada con lo que ser compatible. También explica por qué el modelo no puede simplemente añadirse a un router de propósito general. OrcaRouter no incluye gemini-decision-1, porque un endpoint que solo proporciona probabilidades no es un destino de chat-completions, y ponerlo detrás de una clave que habla ese esquema sería una promesa que la capa de enrutamiento no puede cumplir. Lo que sí incluimos en el espacio de decisiones es typesafe/jev-1.14 de TypeSafe, un modelo de decisión al que se puede llamar mediante la misma interfaz que todo lo demás del catálogo.

La parte de un pipeline de decisiones que el enrutador sí cubre es la mitad de redacción: la llamada generativa que produce la respuesta candidata o la rúbrica que luego evalúa el evaluador. Esa llamada se ejecuta en más de 200 modelos en un solo endpoint, con el precio de lista del proveedor trasladado con un margen del 0%, y es la llamada en la que cambiar de proveedor es un cambio de configuración en lugar de una reescritura. La llamada de evaluación, en cambio, está vinculada a un solo endpoint por diseño, y la arquitectura honesta la trata como una dependencia fija en lugar de algo que haya que rodear mediante enrutamiento.

Si está eligiendo entre las dos cadenas de un formulario

Hay una versión de esta pregunta que no tiene nada que ver con identificadores, y vale la pena responderla directamente porque la formulación invita a ello: alguien que compare "G​emini Decision" con "G​emini Decision 1" puede creer que está viendo dos productos, uno antiguo y otro nuevo, y querer saber cuál adoptar. Solo hay uno. Nada llamado G​emini Decision se lanzó antes de G​emini Decision 1, y el nombre más corto es la etiqueta de familia para una familia que actualmente tiene un solo miembro.

La consecuencia práctica es que cualquier tabla comparativa, reseña o benchmark que encuentres que enumere ambos como entradas separadas está describiendo el mismo modelo dos veces. Dos filas, un modelo, un precio. Si las dos filas discrepan en una cifra, una de ellas está desactualizada en lugar de estar midiendo algo diferente.

En resumidas cuentas

Usa gemini-decision-1 en cada cuerpo de solicitud, ruta de endpoint y valor de configuración, y usa "G​emini Decision" solo donde lo lea una persona. No hay ningún alias al que recurrir, ningún segundo modelo escondido tras el nombre más corto y ninguna ruta de chat-completions hacia el nombre más largo. El coste de equivocarse en esto es pequeño —un 404, una tarde de confusión—, pero el coste de suponer que existe un alias es mayor, porque ese error sobrevive a la revisión y falla en producción. Fija el id, registra el modelo que la respuesta nombre y trata el nombre de la familia como prosa.