La API Decisions de Google responde 1.000 preguntas y no factura ninguna salida

La parte más barata de Gemini Decision 1 es la parte que no existe. Google puso el modelo detrás de una nueva Gemini Decisions API el 11 de noviembre de 2026, y la página de precios indica la salida a cero —no barata, ni con descuento, sino ausente, porque POST /v1beta/decisions no tiene prosa que generar. Envías un bloque de entrada compartida más hasta 1.000 preguntas tipadas; recibes una respuesta calibrada por pregunta y nada más. El número de la tabla de clasificación acaparó la atención el día del lanzamiento. La línea de facturación es la que cambia lo que construyes, y vale la pena hacer las cuentas antes de copiar el diagrama de arquitectura de cualquier otro.

Todas las demás decisiones sobre modelos que has tomado en los últimos dos años estuvieron condicionadas por dos costes que tiraban en direcciones opuestas: la entrada que quieres enviar una sola vez y la salida que quieres mantener corta. Este endpoint elimina por completo la segunda tensión y la sustituye por otra distinta, interna a una única solicitud. Una vez que veas dónde reside la nueva tensión, el resto del diseño de la API —el límite de preguntas, el contexto compartido, la ausencia de caché— dejará de parecer arbitrario.

Lo que cero tokens de salida le hacen a la aritmética

Toma un trabajo realista de puntuación de documentos: una política o un contrato de 40.000 tokens y 1.000 preguntas que quieres responder sobre él. Una solicitud a la API Decisions factura 40.000 tokens de entrada una sola vez, a $0.10 por millón, es decir, cuatro décimas de centavo: $0.004 por las mil respuestas.

Ahora formula las mismas 1,000 preguntas tal como las habrías formulado una semana antes, como 1,000 llamadas independientes a generate-content. Cada llamada tiene que transportar el documento, porque un endpoint de chat no tiene forma de mantenerlo entre llamadas. Eso son 40 millones de tokens de entrada, o $4.00 con la misma tarifa por token, y la brecha se amplía una vez que añades los tokens de salida que habría producido cada una de esas llamadas. El sobre no es una función de conveniencia. Es una diferencia de coste de mil veces para el mismo trabajo, y proviene de una única decisión de diseño: las preguntas se evalúan contra un contexto compartido en una sola pasada, no una por cada ida y vuelta.

Esa aritmética también te indica la forma de la carga de trabajo que este modelo quiere. Muchas preguntas sobre un único objeto grande, respondidas en conjunto. Si tus preguntas son sobre 1,000 objetos diferentes, obtienes 1,000 solicitudes y nada del ahorro.

El presupuesto: 262.144 tokens, compartidos y con un tope de 1.000 preguntas

La ventana de contexto cubre la entrada compartida y todas las preguntas de la solicitud en conjunto, con 262.144 tokens. Dentro de ese presupuesto, puedes plantear entre 1 y 1000 preguntas. El número que importa es el límite superior: 1000 preguntas en una sola llamada no es territorio de un clasificador, es el equivalente al juicio de un motor de reglas comprimido en una sola pasada. Un ticket de soporte se puede contrastar con cuarenta cláusulas de política; un expediente de préstamo se puede evaluar frente a todas las reglas de suscripción a la vez.

Dos propiedades de la forma de la solicitud son fáciles de pasar por alto y costosas de descubrir más adelante. Las preguntas se evalúan de forma independiente: la respuesta de una pregunta no condiciona la siguiente, así que no puedes encadenar razonamientos haciendo una pregunta de seguimiento que dependa de una respuesta anterior. Además, el modelo nunca ve las claves de tus preguntas, solo el texto de instrucciones que escribes, por lo que las claves son para tu propio control y las instrucciones deben ser autosuficientes.

Tres formas de preguntas y la trampa que hay dentro de cada una

• Sí/no — el tipo noul devuelve una probabilidad entre 0,01 y 0,99 además de una puntuación de confianza. El límite se recorta en ambos extremos, por lo que un umbral de enrutamiento establecido en 0,995 nunca se activará, sin importar cuán seguro esté el modelo. Elija umbrales dentro del rango que la API puede devolver realmente.

• Elección — de dos a 255 opciones con nombre; devuelve la opción ganadora, una probabilidad para cada opción que suma uno y un nivel de confianza. Antes de puntuar, la API ordena las claves de tus opciones alfabéticamente en orden de bytes UTF-8, lo que significa que el orden de las claves JSON es irrelevante y un empate exacto se resuelve a favor de la clave que se ordene primero. La recomendación de Google se deriva de eso: llama other a tu opción comodín, porque un nombre como none_of_the_above se ordena antes que la mayoría de las categorías reales y ganará empates que debería perder.

• Puntuación — de dos a 255 niveles de rúbrica ordenados, con dos a diez recomendados. El valor devuelto es un nivel esperado ponderado por probabilidad y, como el valor esperado promedia los índices de la matriz en lugar de las etiquetas, una escala escrita como 1/10/100/1000 produce un número que no está en tu escala. Mantén la rúbrica uniformemente espaciada en términos de índices o convierte tú mismo el índice esperado de vuelta a una etiqueta.

Lo que la documentación indica como no disponible

Las carencias apuntan todas en la misma dirección: se trata de un endpoint de un solo uso, sin nada que lo envuelva. No hay almacenamiento en caché de contexto, así que un documento de políticas reutilizado entre solicitudes se vuelve a facturar completo cada vez. No hay API de lotes, lo que descarta un barrido nocturno a mitad de precio de los tickets del año pasado. No hay nivel Flex ni Priority. El modelo solo está en la API para desarrolladores de Gemini, en la versión v1beta, y no figura en Vertex AI en la documentación que Google distribuyó: un detalle que importa a cualquiera cuyo departamento de compras opere mediante un contrato de nube en lugar de una clave de API.

El contenido multimedia es inusualmente amplio y, al mismo tiempo, inusualmente limitado. Texto, imagen, video, audio y PDF van todos en una sola solicitud. Los límites son 100 MB de base64 en línea, 50 MB para un PDF y 15 MB por URL HTTPS externa. No se aceptan enlaces de YouTube ni URI gs://; se pasan referencias a archivos subidos, URLs firmadas o bytes.

Los límites de frecuencia comienzan en 200 solicitudes y 50.000 tokens por minuto en el nivel gratuito, pasan a 1.500 y un millón en el Nivel 1, y alcanzan las 5.000 solicitudes y cuatro millones de tokens por minuto en el Nivel 2 sin límite diario de solicitudes. El nivel gratuito no tiene costo, pero está documentado que se utiliza para mejorar los productos de Google, lo que lo descalifica para cualquier uso sujeto a una cláusula de confidencialidad.

El marcador, en breve

En el Artificial Analysis Decision Index v2.1, el modelo se sitúa en 66 —65,98 sin redondear—, noveno de los dieciocho modelos de decisión que clasifica el panel. Es primero en solitario en dos de los seis componentes, AA-Omniscience-Decision v1.1 y HLE-MultiChoice v1.1, ambos con un peso del 15%, y está en la mitad de la tabla en AA-Paperclip, con un peso del 30%, que es el componente que decide la mayor parte del compuesto. El coste medido es de 345 $ por millón de tareas y la latencia de 211 milisegundos por tarea, frente a una mediana del conjunto de 209. Google no publicó ninguna tabla de referencia propia con el lanzamiento; todas las cifras de rendimiento que aparecen aquí son del panel independiente, obtenidas con su propio banco de pruebas. La aritmética que hay detrás del 66 es una cuestión aparte y objeto de otro artículo.

Integrarlo en un pipeline que ya enrutas

OrcaRouter no incluye gemini-decision-1, y el motivo es estructural, no comercial: un endpoint que solo devuelve probabilidades no es un destino de chat-completions, así que no hay nada que un router con nuestra arquitectura pueda poner detrás de una sola clave. La mitad del pipeline para la que estamos diseñados es la otra mitad. Un servicio de decisión casi siempre consta de dos llamadas —algo redacta la respuesta candidata, la rúbrica o la lista corta, y algo la puntúa—, y la llamada de redacción es donde la elección del modelo es realmente lo que está en juego.

Esa llamada puede ejecutarse en más de 200 modelos en un único endpoint, al precio de lista del proveedor repercutido con un 0 % de margen, así que cuando un proveedor baja un precio, la nueva cifra está activa en nuestro lado el mismo día en lugar de en el siguiente ciclo de facturación. La fusión de modelos se gana su lugar aquí de una forma en la que no lo hace en una interfaz de chat: dos redactores producen respuestas candidatas que compiten entre sí, y la API Decisions puntúa ambas con la misma rúbrica en una sola solicitud, lo que convierte una prueba A/B en una decisión por registro.

También conviene ser precisos con la conmutación por error. La conmutación por error automática protege la llamada generativa — si el proveedor que hay detrás de tu modelo de redacción devuelve errores, la solicitud se redirige y el pipeline sigue avanzando. No puede proteger la llamada de puntuación, porque hay exactamente un único lugar al que enviarla. Si el endpoint de decisiones está caído, tu pipeline está caído, y ninguna cantidad de enrutamiento lo cambia. Diseña la mitad de redacción para que sea resiliente y acepta que la mitad de puntuación es una dependencia.

En resumidas cuentas

Vale la pena adoptar la API de Decisions por una sola razón, y no es la posición en la clasificación: reduce mil viajes de ida y vuelta a una única entrada facturada, y eso cambia qué preguntas resultan baratas de plantear. Apóyate en ella si tus problemas se parecen a muchos juicios sobre un único objeto grande —un contrato, un expediente de siniestro, una hora de vídeo— y cuenta con mantener tus prompts dentro de una sola solicitud, porque todo lo que la hace barata ocurre entre el primer y el último token de una única llamada. Si tus problemas se parecen a una pregunta sobre mil objetos pequeños, el envoltorio no te aporta nada y la tarifa de entrada es simplemente tres veces lo que cobra un modelo de decisión más barato.