Gemini Decisions API Turns Classification into a Batch—Confidence Still Needs a Job

A customer support team may need to route a thousand short cases: which queue should handle this, does the attachment contain a required form, and should a person review it? A chat model can answer each question in prose, but the system still has to parse and constrain that answer. Google’s new Decisions API turns a set of fixed-choice questions into one scoring request. The engineering challenge shifts from generating an answer to deciding what to do with uncertainty.

A decision endpoint, rather than another chat turn

Google says Gemini Decision 1 can take text, images, audio, video and PDFs, plus up to 1,000 independent questions, and return probabilities and confidence scores in one forward pass. The company reports 150–250 milliseconds end-to-end latency and $0.10 per million input tokens with no output-token charge. It says the shared input is billed once per request, while question criteria add their own token cost. These are Google’s announced figures and should be verified against the live API pricing and measured in the region and workload a team plans to use. ^[1]

The API offers three bounded formats: yes/no, a choice among candidate options and an ordered rubric score. That is structurally different from asking a general model to write an answer and then extracting a category from its prose. OpenAI has announced a similar typed decision endpoint; our Decisions API review explains how to compare structured classification with free-form generation. For a fixed task, the returned choice and probabilities can make the application logic simpler and easier to inspect. ^{[1] [2]}

Examples in Google’s announcement include selecting tools, routing models, checking policies and grading context. These are potential use cases, not proof that the model is suitable for every decision in those categories. A policy check may be low risk when it routes a document to the right team; it may be high risk if it blocks a person’s access or determines a financial outcome.

Confidence is an input to a policy, not a verdict

The API’s confidence score can help an application decide whether to accept a result automatically, request a second check or send the item to a person. But a number from zero to one does not mean “this answer is that likely to be correct” unless calibration has been demonstrated for the relevant population, task and model version. Confidence can be poorly aligned with actual error rates, especially when inputs differ from the examples used to develop the system.

Build the threshold from a labeled evaluation set that resembles production. Measure false positives and false negatives separately for each decision type; the harm from an incorrect “yes” may differ from a missed “yes.” Review performance across language, image quality, document format and other factors that change the input distribution. Keep a clear “unknown” or escalation route when confidence is low or evidence is ambiguous.

NIST’s AI Risk Management Framework treats measurement as part of a continuing risk process, not a one-time benchmark. That is a useful way to think about a new endpoint: establish who is accountable for the decision, what failure would cost, and how performance will be monitored after launch. ^{[3] [4]}

Batch questions can make throughput cheaper—and evaluation more important

Scoring many questions against one shared input can reduce repeated work when the questions belong together. For example, an intake process might ask whether a form is present, whether a date is visible and which of several document types best fits. A system can then route a clean case quickly while sending incomplete or conflicting results to a reviewer.

The same efficiency can amplify a systematic mistake. If one input is misread, every related question may inherit that error. If a rubric is vague, a thousand decisions can apply the ambiguity at scale. Start with a small batch, inspect representative outputs and compare each score with a human-labeled answer. Keep the questions independent where possible so the meaning of one result does not silently influence another.

Google reports benchmark advantages for routing, reasoning, ranking and multimodal understanding, including lower calibration error on its evaluation suite. Those comparisons are vendor-reported and do not tell a team how the API will perform on its proprietary documents. Ask for the benchmark task and conditions, then run a local evaluation with your own decision boundaries and acceptable error costs. ^[1]

Compare the full workflow, not only token rates

For a routing job, the relevant cost is not just model tokens. Include ingestion, retries, human review, downstream handling and the expense of an incorrect route. A cheaper score can still lose if it increases manual review or misses cases that require intervention. Conversely, a simple bounded endpoint may save engineering time compared with building a prompt-and-parser chain for a task that truly has fixed outcomes.

Keep a generative model for work that needs explanation or synthesis. A decision model can classify a known set of options; it does not replace a person’s judgment or provide a complete rationale simply because it returns a confidence value. If users need to understand a result, present the evidence and a clear correction path. Our analysis of confidence estimates in a local decision model discusses why score calibration needs to be checked against observed outcomes.

A small pilot that answers the real question

Select one low-risk queueing task with an existing labeled dataset. Define the candidate choices, the meaning of each rubric level and the escalation threshold before running the API. Compare the result with the current process, stratify errors and record latency and human-review time. Test adversarial and incomplete inputs, and retain a human override.

If the endpoint improves the workflow without hiding uncertainty, expand cautiously. If the error profile is uneven or the scores do not predict actual correctness, keep the model in an assistive role while improving the data or criteria. A fast API can help a system make more decisions. The team still has to decide which decisions should be automatic.