Gemini Decisions API explained: Google's model that answers with probabilities, and what it really costs

On 11 November 2026 Google announced the Gemini Decisions API in a post by Min Choi, a product manager, and Felix Yu, a principal scientist, both at Google DeepMind. The API runs one new model, Gemini Decision 1, and you can use it today with a key from Google AI Studio.

The idea is simple. Many calls an application makes to a language model are not really asking it to write anything. They ask it to pick: is this message a complaint, which support queue should take it, does this photo show damage, which model should answer this question. Normally you would ask a chat model to reply with a word or some JSON and then read that word back. The Decisions API skips the writing. You give it the input and a list of typed questions, and it gives you back a probability for each possible answer.

Google lists four teams already using it inside the company. Gemini Notebook uses it to route each question to the right model and thinking level, which Google says cut latency by up to 40% for everyday queries. Stitch, Google's design tool, uses it to apply design edits made by voice or tap almost at once. CC, a Google Labs app, uses it to pick an emoji reaction from more than 200 options. And Google Search uses it as a safety layer for MCP tools (the standard way AI agents call outside tools), to catch tools and content that try to trick the agent.

In short: this is a fast, cheap classifier you set up by writing questions instead of training a model. The rest of this page is about how it works, what a call really costs, and the cases where it is the wrong tool.

A call has three parts: the model name (gemini-decision-1), one shared input, and a map of questions. The input can be plain text or a list of content blocks: text, an image, audio, a video or a PDF, sent as the file itself, a web link to it, or a link to a file you uploaded to Google earlier. Each question has a key you choose, a type, the instructions, and for choice and score, the criteria.

There are three question types. A yes-or-no question (Google's type name is noul) returns the probability that the answer is yes, between 0.01 and 0.99. A choice question picks one of 2 to 255 options you describe, and returns the winner and a probability for every option, adding up to 1. A score question rates the input against ordered levels (0 is the first) and returns a weighted average, for example 2.99 on a 0-to-3 scale of how likely a customer is to leave, in Google's own example, plus the probability of each level.

Every answer also has a confidence, the model's estimate that its top answer is right. Google calls the probabilities calibrated, which means that when the model says 0.9, it should be right about 9 times in 10. That is a claim you should check on your own data. For a yes-or-no question it is the larger of the yes and no probabilities. The docs' advice is to act automatically above a threshold you set from your own labelled examples, and send the rest to a person or a bigger model.

Two rules matter when you write questions. First, questions cannot see each other: each one is scored on its own against the shared input, and adding or removing one does not change the others. Second, the model never sees your question keys, so the instructions must say the whole question. Google's advice is to ask narrow, single-purpose questions and combine the answers with ordinary if-statements in your code.

Why is it fast? Writing text means running the model once per output token. Here the model reads the input and the questions in one pass (the prefill) and reads off probabilities for the given options, so there is nothing to generate. Google says the model's own compute is 50 to 100 milliseconds at the median, 150 to 250 milliseconds end to end, and stays nearly flat from 1 to 100 questions for inputs up to 16,000 tokens. Those are Google's measurements; I could not repeat them.

Read next: Model routing and cascades: sending each request to the right model

The docs are clear about what the API does not do, and two of these limits change the bill. It has no context caching and no Batch API, and no cheaper slow tier (Flex) or faster paid tier (Priority), so repeated input across requests counts in full every time. That matters for a router in front of a chat: on every turn it must read the whole conversation again.

I worked this through for a chat where each turn adds about 266 tokens and the router asks one question per turn. Over 30 turns it reads 124,680 tokens in all. On Decision 1 that is $12.47 per 1,000 chats. On Gemini 3.5 Flash-Lite, with every earlier turn served from the cache at $0.03 per million and only the new turn at $0.30, it is $6.31. That assumes the cache hits on every turn and leaves out the storage charge for explicit caches ($1 per million tokens per hour), so the real gap is smaller, and on short chats it can reverse. But on long chats Decision 1 is not the cheap option. By Google's figures it is still the fast one, and it still gives you probabilities; for a short check on a short input it is the cheaper option on these list prices.

Some other limits from the docs. It is only on the Gemini Developer API, version v1beta, with this one model; Google says Gemini in Google Cloud is coming soon. Question instructions are text only. It does not take YouTube links or links to files in Google Cloud Storage (gs://). It does not accept a model's earlier reasoning steps or tool calls as input, so you have to write a chat out as plain text. If Google's input safety filters block a request, you get an HTTP 400 error with a code such as safety or image_safety instead of answers, so your code needs a path for that. Google listed OpenRouter, LangChain, Vercel, LiteLLM and others as integrations that are rolling out; when I checked OpenRouter's public model list on 12 November, Decision 1 was not on it yet.

Two practical points on the free tier. It allows 200 requests a minute, 50,000 tokens a minute and 10,000 requests a day, so one high-resolution image per call would hit the token limit at around 40 calls a minute. And on the free tier, Google's pricing page says your data is used to improve its products; on the paid tier it is not. Do not send customer data through a free-tier key.

Read next: Reusing a prompt's start: what prompt caching saves

The facts about the API come from Google's launch post of 11 November 2026 and from the Decisions API guide, the model page, the pricing page and the rate-limits page in Google's docs, all read on 12 November 2026 and linked below. The model's details (input limit 262,144 tokens, method createDecision) also come from Google's public model endpoint, which I called for free.

I did not call Gemini Decision 1, because the live call returned a billing block (HTTP 402) on our account, so I cannot confirm its speed, its accuracy or its calibration. The latency and the "nearly 5 times cheaper" figure are Google's. The token counts are real, from Google's own counter on a related model, and miss the few formatting tokens Decision 1 adds per question. The costs are my arithmetic on Google's list prices. The OpenAI numbers are from our own recorded run in October.