Gemini Decisions API: When AI Should Choose Instead of Chat
- AI
- Guides
- Gemini
- API
- AI models
- Written by
- Bhargav Tibadiya
- Published
- Reading time
- 8 min read
The Gemini Decisions API is for choosing among defined answers, not writing an open-ended response. It takes shared material plus independent yes/no questions, candidate choices or ordered rubrics, then returns scores and probabilities. Google introduced the endpoint on November 11, 2026, powered by Gemini Decision 1[1].
The useful distinction is between deciding which option fits and generating a new explanation. A routing system may need a model tier, a document workflow may need a category, and a review process may need an ambiguity flag. None of those decisions automatically gives the application permission to carry out a consequential action.
This is a source-based explanation, not a latency benchmark or a tested integration. Google's maximum request size and its reported speed measurements describe different conditions and should not be combined into one promise.
What the Gemini Decisions API returns
A generative model normally produces an answer as a sequence of output tokens. Google says Decision 1 instead scores the supplied candidate options in a single forward pass. That makes the endpoint a different primitive from asking a chat model to write a label and then parsing its prose[1].
The launch describes three decision types. A yes/no check estimates whether a condition holds. Multiple choice selects among 2 to 255 options and returns probabilities across the candidates. An ordered rubric produces a continuous weighted score and probabilities for its levels.
Questions can share a multimodal input containing text, images, audio, video or PDFs. The endpoint accepts up to 256K input tokens and up to 1,000 independent questions in a request, according to the announcement[1].
The word “independent” matters. A set of separate checks about the same source is different from a chain where the second question depends on the first answer and changes what the model should inspect.
Use closed choices when the application already knows the options
Consider an illustrative customer-support workflow with categories for billing, account access, technical issues and an “other or unclear” route. The application needs a bounded result it can handle consistently, rather than a beautifully worded paragraph explaining that a message sounds like billing.
That is a natural closed-set problem. The usefulness depends on whether the categories actually cover the incoming work, whether their descriptions are clear and whether the fallback catches ambiguity.
A bad choice set can force a confident answer into the wrong category. If a ticket contains both a billing dispute and an account-security concern, a single label might be inadequate. The application designer must decide whether to allow multiple checks, split the work or send it to review.
This is why a scoring endpoint does not remove product design. It moves some complexity from parsing generated prose into defining options and handling the result correctly.
Do not confuse 1,000 questions with the latency benchmark
The launch's headline capacity is up to 1,000 independent questions over an input of up to 256K tokens. Its detailed speed claim is narrower: 150-250 milliseconds end to end on the described multimodal inputs and contexts up to 16K tokens, remaining nearly flat from 1 to 100 questions[1].
Those statements are compatible, but they are not interchangeable. The article does not establish that a maximum-size input with 1,000 questions will finish in the same latency band.
Google also distinguishes 50-100 milliseconds of model compute from the end-to-end figure. An application experiences more than model compute, including request handling and its own upstream and downstream work.
Measure the complete path for your own representative input sizes, question counts and deployment environment. Record slower cases and failures as well as a median. A launch range is a lead to evaluate, not an application service-level agreement.
The price is based on input, not generated output
Google lists $0.10 per million input tokens, with no output-token charge. The shared input is billed once per request, while each question adds its own instruction and criteria tokens. The announcement also describes a no-cost API tier for prototyping[1].
At that listed input rate, an illustrative 100,000 billed input tokens would cost $0.01. That arithmetic is not a measured invoice or a complete account-specific bill. The final request size includes question material, and current account and product conditions still need checking.
“Zero output tokens billed” is different from “free.” It changes the pricing structure, but input volume still matters. Repeating a large document in several requests can cost more than evaluating suitable independent questions together.
The LLM token-usage guide explains why context selection and repetition matter. The Decisions API gives another reason to think about shared inputs carefully, without making unrelated questions magically independent.
Confidence helps route uncertainty, not erase it
The endpoint returns confidence scores and candidate probabilities. Google presents this as a way to send ambiguous cases to a fallback or human reviewer. VentureBeat's reporting likewise frames the product as a decision layer rather than free-form generation[2].
A confidence score is not proof of correctness for a particular case. It describes the model's scoring behavior under the supplied options and input. Poorly defined candidates, missing evidence or unfamiliar data can still produce an unhelpful result.
Choose a review threshold using labeled examples from the workflow you care about. If the cost of a wrong decision is high, the threshold and fallback should reflect that cost. A threshold copied from a demo may not fit a different application.
Keep an “unclear” route when the source does not support a decision. If none of the options is right, normalizing probabilities across the listed options does not create a correct answer.
A policy check is not authority to act
Google lists policy checks, tool selection and model routing among the intended uses. Those are useful places for a fast scoring step, but the output should remain evidence for application logic rather than an authorization system on its own[1].
A classifier can identify that a message asks for a refund. It cannot establish that the sender owns the account, that a refund is permitted or that the user approved the payment. Those facts require the relevant records and controls.
Likewise, selecting a tool does not establish that the tool's effect is safe. A system should validate inputs, check permissions and require the appropriate approval before an irreversible or costly operation.
The guide to verifying an AI agent's final state covers the other end of that workflow: after an allowed operation, verify what actually changed. Good routing and good closeout solve different problems.
Multimodal checks still depend on the evidence supplied
The launch demonstrates combining an image and a text note, then asking separate questions about the scene. That makes it possible to share context across checks without requesting a long generated description first[1].
For an illustrative document review, one question might ask whether a date is present, another whether a signature field is filled and another which document category fits. These are possible workflow ideas, not tests performed for this article.
A model cannot reliably infer a missing page, a cropped detail or an unreadable field simply because the request is multimodal. Image resolution, video sampling and source quality still affect what evidence reaches the model.
Separate “the field appears present” from “the document is legally valid” or “the person approved the transaction.” The second pair depends on facts a visual classifier may not have.
Reported use cases are not independent performance guarantees
Google describes internal applications in Gemini Notebook routing, Stitch design iteration, CC emoji selection and a safety layer for MCP tools in Search. These examples help explain why bounded scoring is useful across very different products[1].
They do not establish the same benefit for every developer. A router that improves one workload might choose badly for a different mix of requests. An emoji palette has a very different error cost from a tool-permission decision.
The launch also reports broad benchmark and calibration advantages. Those claims remain Google's evidence under the specified evaluations, not an independent ranking produced here.
Do not compare a company's full application latency with another model's compute-only number. Match the task, input, output requirements, hardware path and measurement definition before drawing a conclusion.
Start with a shadow evaluation
A safe first integration can score real examples without controlling the live outcome. Compare its decisions with known labels or existing review results. Track where the model is confidently wrong, where categories overlap and where the source lacks enough information.
Then test a bounded low-risk use, such as suggesting a route while leaving the existing decision process in place. Keep the selected option, confidence, model version, criteria and input reference so errors can be inspected.
Only after that should you decide which cases can proceed automatically and which need review. External permissions, spending limits and user consent remain separate checks.
This is a proposed evaluation path, not a completed integration. The endpoint's promise is a cheaper, faster way to score defined choices. Whether that improves a real product depends on the choices, evidence and controls around it.
FAQ
What is the Gemini Decisions API?
It is a Gemini API endpoint powered by Gemini Decision 1 for bounded decisions, including yes/no checks, multiple choice and ordered rubric scores over shared multimodal input.
Does it generate normal chat responses?
Its purpose is to score supplied options and return structured decisions, probabilities and confidence, rather than produce an open-ended answer token by token.
Can it answer 1,000 questions in 150 milliseconds?
The launch supports up to 1,000 independent questions, but its detailed 150-250 millisecond end-to-end measurements cover contexts up to 16K tokens and 1 to 100 questions. The maximum capacity should not be presented as the latency-test condition.
What does Gemini Decision 1 cost?
Google lists $0.10 per million input tokens and no output-token charges. Shared input is billed once per request, while questions add their own instruction and criteria tokens; account-specific conditions still need checking.
Does a high confidence score authorize an action?
No. Confidence is model output, not proof of identity, permission, policy eligibility or user consent. The application must enforce those checks separately.
Was the API benchmarked for this article?
No. This is a source-based explanation of the launch and outside reporting. The workflow examples and evaluation plan are illustrative, not measured results.
