Google's new gemini-decision-1 model answers yes/no, multiple-choice and rubric questions by scoring the options instead of generating text. We explain why that makes it fast and cheap, what its probabilities do and do not mean, and how to tune the cut-off on your own data before you route real traffic with it.
This explains reporting by
Google: Introducing the Gemini Decisions API (November 11, 2026). Read the original first:
https://blog.google/innovation-and-ai/technology/developers-tools/gemini-decisions-api/
In one minute #
- Google launched the Gemini Decisions API on November 11, backed by a new model, gemini-decision-1, in the Gemini API and Google AI Studio.
- It answers three closed question types: noul (yes/no), choice (2 to 255 options) and score (an ordered rubric). Every answer has a confidence from 0 to 1.
- Google says it scores the options in a single forward pass rather than writing text, giving 150 to 250 ms end to end and nearly flat latency from 1 to 100 questions.
- Price: $0.10 per million input tokens and nothing for output. A shared input, such as a video, is billed once per request even with up to 1,000 questions.
- Benchmarks and the '5x cheaper than Gemini 3.5 Flash-Lite' figure are Google's own. The first outside test, by Simon Willison, is one video and four questions.
What Google shipped #
The Gemini Decisions API is a new endpoint for what Google calls closed-set decisions: questions where the answer must come from a list you supply. Google names tool selection, policy checks, model routing and grading context as the main uses.
One request takes one shared input, up to 256K tokens of text, images, audio, video or PDF, and up to 1,000 independent questions about it. Google says the input uses the same content format as its Interactions API.
There are three question types. A noul question returns the probability that a condition is true, with optional criteria for true and false. A choice question takes 2 to 255 options and returns the winner and a probability for every option. A score question takes rubric levels starting at 0 and returns a weighted score plus a probability for each level.
Why scoring beats writing for these jobs #
A normal chat model answers by writing tokens one at a time. Each new token needs another pass through the model. Even a one-word 'yes' usually comes with a preamble, and reasoning models may spend thousands of hidden tokens first.
A decision model skips that. Google says gemini-decision-1 scores the candidate options in a 'single forward pass'. In plain words, the model reads the input once and assigns a likelihood to each allowed answer, then the API returns those numbers. Nothing is written, so there are no output tokens to bill and no decoding loop to wait on.
That is why Google can quote 150 to 250 ms end to end, with 50 to 100 ms median model compute, and say latency stays nearly flat from 1 to 100 questions on contexts up to 16K tokens. The expensive part, reading the input, happens once and every question reuses it.
The trade-off is that it can only pick from what you give it. It will not explain itself, and it cannot answer an open question.
What the price means in practice #
Google's price is $0.10 per million input tokens and $0 for output. Google says shared input is billed once per request, and each question adds only its own instruction and criteria tokens. There are no charges for thinking tokens, audio transcription or OCR, and AI Studio has a no-cost tier for prototyping.
Worked example, using only those rules: a 10,000-token support ticket with 20 short routing questions of about 50 tokens each is roughly 11,000 input tokens, or about $0.0011 per ticket. Asking the same 20 questions as 20 separate chat calls would send the ticket 20 times. Our arithmetic, not Google's.
Google claims it is 'nearly 5x cheaper' than Gemini 3.5 Flash-Lite with the Interactions API across its shared benchmark suite. That figure is Google's own.
Probabilities are not a verdict until you tune them #
Every answer comes with a confidence from 0 to 1. It is tempting to treat anything above 0.50 as yes. Hamel Husain and Antaripa Saha, writing about decision models in October, argue against that: tune the cut-off per task on labeled data, using a measure like F1, and only read the number as confidence after you check calibration.
Their simple illustration: if every failure scores 0.40 and every pass scores 0.10, a threshold of 0.30 sorts them perfectly while the default 0.50 catches nothing. The model ranked them right; the cut-off was wrong. They then tested several decision models on 98 traces from an apartment-leasing agent, comparing them by F1.
Simon Willison's quick test shows why this matters. On his own video, gemini-decision-1 got four yes/no questions right but gave about 0.92 for a true answer, where other decision models he tried return 1.0 or 0.0. If your code checks for exactly 1.0, or for above 0.95, those answers fall through.
Practical recipe: collect 50 to 100 real examples with known answers, run them through the API, and pick the threshold that gives the best balance of misses and false alarms for that one question.
Where it sits among decision models #
Decision models are a young category. Husain's post lists TypeSafe's Jev, Perplexity's Decider, Liquid's d1, Cloudflare's Clef and OpenAI's Decisions API before Google's. Willison notes OpenAI's model is also $0.10 per million input, and Jev is cheaper at 4.2 cents per million.
Google says gemini-decision-1 leads its benchmark suite with the lowest calibration error. Latent Space's recap of Artificial Analysis puts it level with Jev on a decision index but slower; we could not open the Artificial Analysis page, so treat that as unverified.
Google already uses it inside its own products: routing in Gemini Notebook (up to 40% lower latency, Google says), picking emoji reactions in a Labs app, and a safety layer that flags adversarial behavior in MCP tools for Search.
Who is affected #
| Case | Status |
|---|---|
| Model routing and tool choice in agents | Good fit. Closed choice, latency-sensitive. |
| Policy and safety checks on inputs | Good fit, after you tune the threshold on labeled data. |
| Grading outputs against a rubric | Supported with the score type; check calibration first. |
| Open questions, explanations, extraction of free text | Not supported. Keep a generative model. |
| Google Cloud (Vertex) users | Google says support is 'coming soon'. Today it is the Gemini API and AI Studio. |
What to do #
- Pick one routing or yes/no check you already pay a chat model to do.
- Label 50 to 100 real examples and run them through the free AI Studio tier.
- Choose the threshold from that data, not 0.50, and record cost and latency against your current call.
- Group questions about the same input into one request, since the input is billed once.
- Keep a fallback to your current model until the numbers hold on live traffic.
What is still unknown #
- Independent benchmarks. Google's suite and its 5x cost claim are its own; the Artificial Analysis figures we saw were secondhand.
- The exact API field names. Google's docs pages did not render for us, so names here come from the blog.
- How the free tier is limited, and for how long.
- How well its probabilities are calibrated on your data. Only your own labeled test can tell you.
Sources #
- [Google: Introducing the Gemini Decisions API (November 11, 2026)](https://blog.google/innovation-and-ai/technology/developers-tools/gemini-decisions-api/) — the original report
- [Simon Willison: Gemini Decisions API (November 11, 2026)](https://simonwillison.net/2026/Nov/11/gemini-decisions-api/)
- [Hamel Husain and Antaripa Saha: evaluating decision models (October 20, 2026)](https://hamel.dev/blog/posts/decision-model-evals/)
[AI News Report](https://theainewsreport.com/)· every headline, every morning.