Una decisión con la Gemini Decisions API cuesta 0,10 dólares por millón de tokens de entrada y nada por la salida: etiquetar un ticket de soporte de 2.000 tokens sale unos 0,0002 dólares, o cerca de 200 dólares por millón de tickets. Google lanzó el endpoint el 11 de noviembre de 2026 junto con un modelo nuevo, gemini-decision-1, que puntúa un conjunto fijo de opciones en una sola pasada en lugar de generar una respuesta.
Al 12 de noviembre de 2026: la API está disponible en la Gemini Developer API (
v1beta) y en Google AI Studio, con un nivel gratuito para prototipos. Google todavía no había publicado los límites de uso (rate limits) en la página de documentación, y el soporte en Vertex AI figuraba como “coming soon”.
Ese precio importa por lo que publicamos hace dos días en yoDEV: Amazon cambió Claude Sonnet por un modelo de decisión autoalojado y bajó el costo por ticket un 98 por ciento. La pregunta obvia para cualquier líder de ingeniería pasa a ser otra: ¿alojo yo el modelo de decisión o le pago a Google por token? La respuesta depende de tres cosas que repaso en esta nota: el volumen, adónde pueden ir tus datos y cuántas preguntas haces sobre cada entrada.
¿Qué es la Gemini Decisions API?
Es un endpoint de Google para decisiones de conjunto cerrado (closed-set classification): elegir una herramienta, revisar una política, enrutar entre modelos (LLM router), calificar contenido. Sirve para cualquier pregunta cuya respuesta sale de una lista conocida. Envías una entrada y hasta 1.000 preguntas independientes sobre ella, y por cada pregunta recibes probabilidades y una confianza entre 0 y 1. El modelo nunca escribe texto, así que no hay tokens de salida que cobrar.
Hay tres tipos de pregunta, y conviene saber sus nombres exactos porque uno parece una errata:
| Tipo | Qué responde | Qué devuelve |
|---|---|---|
noul |
Sí/no: ¿se cumple una condición? | noul (una probabilidad entre 0,01 y 0,99) y confidence |
choice |
Elegir una de entre 2 y 255 opciones | choice (la ganadora), probabilities por opción, confidence |
score |
Calificar en una rúbrica ordenada de 2 a 255 niveles | score, probabilities por nivel, legend, confidence |
noul es el nombre real del tipo sí/no, no un error de tipeo de bool. La documentación aclara que no existe un tipo bool. Es el mismo vocabulario que usan Jev y Strands Decider, lo que indica que Google entra en una categoría que ya existe en lugar de inventar una.
La entrada puede ser texto, imágenes, audio, video o PDF, todo procesado en una sola pasada. Si los modelos de decisión son nuevos para ti, explicamos el concepto en Microsoft-Decision-1 vs Jev.
¿Cuánto cuesta una decisión con la API de Gemini? Las cuentas
La regla de precios que cambia las cuentas es esta, de la página de precios de Google (Gemini API pricing): cada solicitud cobra la entrada compartida una sola vez, sin importar cuántas preguntas hagas. Cada pregunta suma solo los tokens de su propia instrucción y sus criterios.
Tres escenarios al precio de lista de 0,10 dólares por millón de tokens de entrada:
| Escenario | Tokens por solicitud | Costo por solicitud | Costo por decisión |
|---|---|---|---|
Un ticket, una pregunta choice con 20 etiquetas |
~2.000 | 0,0002 USD | 0,0002 USD |
| El mismo ticket, 5 preguntas (equipo, urgencia, sentimiento, idioma, spam) | ~2.300 | 0,00023 USD | ~0,000046 USD |
| Documento de 10.000 tokens, 1.000 preguntas cortas (~30 tokens cada una) | ~40.000 | 0,004 USD | 0,000004 USD |
Son estimaciones mías, no de Google, y la cantidad de tokens depende del tokenizador. Lo que importa es la forma de la curva: cuantas más preguntas cuelgas de una misma entrada, más se acerca a cero el costo por decisión.
Ahora ponlo al lado de los números que Amazon publicó para su sistema de tickets:
| Por millón de tickets | Costo | Fuente |
|---|---|---|
| Claude Sonnet 4.6 en Bedrock, generando una etiqueta JSON | ~22.200 USD | Amazon (autorreportado) |
Strands Decider E4B en una ml.g5.xlarge de SageMaker |
~500 USD | Amazon (autorreportado) |
| Gemini Decisions API, ~2.000 tokens por ticket | ~200 USD | Estimación de yoDEV a precio de lista |
La comparación no es exacta. El ticket de Amazon medía 2.009 tokens con el tokenizador de Decider, y sus 500 dólares incluyen margen para picos en una GPU trabajando cerca de su capacidad. Aun así, el resultado es útil: a precio de lista, el endpoint alojado queda en el mismo orden de magnitud que un despliegue propio bien ajustado, y bastante por debajo si tu instancia no está saturada. Aquí está cómo midió Amazon el 98 por ciento.
¿Es gratis la Gemini Decisions API?
Para prototipos, sí. La página de precios de Google indica “Free of charge” para la entrada en el nivel gratuito, y 0,10 dólares por millón de tokens en el nivel de pago. Al momento de publicar esta nota, Google no había publicado las cuotas del nivel gratuito, y la página de documentación enlaza a una página de límites en lugar de indicarlos. Revísalos antes de planificar una carga de producción sobre ella.
¿Qué latencia tiene gemini-decision-1?
Google habla de 150 a 250 ms de punta a punta, con una mediana de 50 a 100 ms de cómputo del modelo, y dice que la latencia se mantiene casi plana entre 1 y 100 preguntas por solicitud. Ojo con la letra chica: la cifra de cómputo mediano aplica a entradas de hasta 16K tokens. El límite real es mucho mayor, 262.144 tokens entre la entrada compartida y todas las preguntas juntas. Espera que un video de 200K tokens sea más lento que la cifra del titular; Google no dice cuánto.
Como referencia, Amazon reportó 897 ms por llamada para Strands Decider E4B en su configuración de SageMaker, y 4.215 ms para Sonnet.
¿Gemini Decisions API o un modelo propio como Jev o Strands Decider?
Así es como yo lo dividiría.
El endpoint alojado gana cuando:
- El volumen es bajo o irregular. Una instancia con GPU cuesta lo mismo ociosa que ocupada. Los 500 dólares por millón de Amazon suponen una instancia trabajando; con unos pocos miles de decisiones al día, pagas sobre todo tiempo muerto. El cobro por token no tiene costo ocioso.
- La entrada es grande o multimodal. El E4B de Strands Decider trabajaba con una ventana de 4.096 tokens, y Amazon tuvo que reescribir todas las descripciones de etiquetas y recortar los tickets largos para que cupieran. Gemini acepta 262K tokens, imágenes, audio, video y PDF. Un comentario en Hacker News lo resumió igual: cuesta más que otros modelos de decisión de su categoría, pero la entrada de audio y video puede justificarlo.
- No tienes un equipo para operar inferencia. La configuración de Amazon involucraba SQS, Lambda, SageMaker, AppConfig, CloudWatch y CDK en tres etapas. La llamada a la API son unas pocas líneas.
Alojarlo tú gana cuando:
- Los datos no pueden salir de tu infraestructura. La Decisions API solo está en la Developer API
v1beta. Vertex AI, donde viven la mayoría de los acuerdos de tratamiento de datos empresariales, figuraba como “coming soon” al momento de publicar. Para datos regulados, eso por ahora define la decisión. - Necesitas throughput garantizado. No hay límites de uso publicados, ni Batch API, ni inferencia Flex o Priority. No puedes planificar capacidad sobre un techo desconocido.
- Corres loops de agentes. La API no tiene context caching y no acepta historial de conversación como entrada, así que cada paso de un agente vuelve a cobrar la trayectoria completa. Un motor propio como Flide guarda los estados anteriores en una caché de sesión y solo calcula los tokens nuevos. Además usa el mismo truco de “calcular el estado compartido una vez” que Google cobra, pero en tu propia GPU.
- El volumen es muy alto y constante. Una GPU saturada tiene un costo fijo por decisión que no crece con tu factura.
Mi lectura para un CTO: la Decisions API hace que el primer experimento sea casi gratis. Toma las llamadas de clasificación que hoy envías a un LLM frontera, pásalas por este endpoint con un umbral de confianza y mide la precisión contra lo que ya tienes. Si los resultados se sostienen y tus datos pueden ir a Google, quizá nunca necesites alojar nada. Si se sostienen y tus datos no pueden salir, acabas de validar el caso para alojarlo tú casi sin costo.
¿Cómo usar la API de Gemini para tomar decisiones?
Necesitas el SDK google-genai en la versión 3.2 o posterior:
pip install -U google-genai
Este es el quickstart de la documentación de Google. Hace una pregunta noul sobre un texto corto:
from google import genai
client = genai.Client(http_options={"api_version": "v1beta"})
result = client.decisions.create(
model="gemini-decision-1",
input="The blue mug I ordered on Monday arrived cracked on Wednesday.",
questions={
"is_damaged": {
"type": "noul",
"instructions": "Did the item arrive damaged?",
},
},
)
answer = result.answers["is_damaged"]
print(f"P(yes)={answer.noul:.2f} confidence={answer.confidence:.2f}")
La misma llamada por REST:
curl -X POST "https://generativelanguage.googleapis.com/v1beta/decisions" \
-H "x-goog-api-key: $GEMINI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gemini-decision-1",
"input": "The blue mug I ordered on Monday arrived cracked on Wednesday.",
"questions": {
"is_damaged": {
"type": "noul",
"instructions": "Did the item arrive damaged?"
}
}
}'
Para enrutar un ticket, usa una pregunta choice. Según el esquema documentado, criteria es un objeto que asigna una descripción a cada ID de opción, y la respuesta trae choice (la ganadora) y probabilities:
result = client.decisions.create(
model="gemini-decision-1",
input=ticket_text,
questions={
"team": {
"type": "choice",
"instructions": "¿Qué equipo debería atender este ticket?",
"criteria": {
"billing": "Pagos, facturas, reembolsos o cobros",
"technical": "Errores, caídas o bugs del producto",
"sales": "Precios, planes o compras nuevas",
},
},
},
)
answer = result.answers["team"]
if answer.confidence >= 0.8:
route_to(answer.choice)
else:
send_to_human(ticket_text)
El umbral de 0.8 es un ejemplo: ajústalo con tus propios datos, como hizo Amazon. Cada respuesta incluye un objeto usage con total_input_tokens y total_output_tokens, que siempre vale 0. Regístralo desde la primera llamada y tu costo por decisión pasa a ser una división, no una estimación.
¿Se puede confiar en los benchmarks de Google?
Todos los benchmarks son de Google. El post dice que gemini-decision-1 lidera su suite en enrutamiento de agentes, razonamiento, ranking y comprensión multimodal, con el menor error de calibración (calibration error), y que es casi 5 veces más barato que Gemini 3.5 Flash-Lite en la suite de benchmarks compartida. Esa última comparación es contra el propio modelo generativo de Google, no contra Jev, Strands Decider ni Microsoft-Decision-1, y el post no publica su metodología.
Dos lecciones de la migración de Amazon también aplican aquí. Primero, mide la sensibilidad a la entrada: Amazon descubrió que solo el orden de las claves del JSON movía las probabilidades de Decider hasta en 0,19, así que fija el formato de tus entradas antes de comparar modelos. Segundo, corre ambos sistemas en paralelo sobre tráfico real antes de apagar el anterior. Un benchmark del proveedor es una razón para probar, no un sustituto de la prueba.
¿Y tú? Si mañana movieras tus clasificaciones a un modelo de decisión, ¿cuál sería la primera?
- El costo por decisión
- Dónde quedan los datos
- La latencia y el throughput
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.