Google Gemini Decisions API: Speed and Limits of Single-Pass Scoring
Google's Gemini Decisions API scores bounded multimodal choices in one forward pass. Its potential benefit is less generation and repeated processing, but the reported latency covers a narrower range than the maximum input limits. Calibration, fallback frequency, and total workflow cost still require business-specific evaluation.
THE BRIEF
Blog highlights
Evidence scope: Google AI's November 11, 2026 announcement is the sole source. It says the endpoint is available through the Gemini API in Google AI Studio, while support for Gemini in Google Cloud is coming soon. Specifications, pricing, performance, calibration, and internal application results are Google's claims. This article includes no independent testing or verification of account access or Token4AI integration.
Source announcement ·
What changes for developers
Google introduced the Gemini Decisions API on November 11, 2026, powered by Gemini Decision 1 (gemini-decision-1). The endpoint turns bounded tasks such as tool selection, content checks, and model routing into a dedicated operation. Multiple questions can evaluate a shared input containing text, images, audio, video, or PDFs. For developers, the practical change is receiving structured probabilities directly, reducing the generation and parsing needed to obtain a label from a conversational response. These capabilities are Google's reported specifications. Google AI
According to the announcement, the model scores candidate options in a single forward pass instead of decoding answer text token by token. The API accepts up to 256K input tokens and 1,000 independent questions. Our inference is that sharing an input could reduce repeated processing, particularly where the possible answers are already known. Forward computation still has a cost, and the post does not disclose the internal scoring architecture or training method. Independent questions evaluate common evidence; developers should not assume that a later question can consume an earlier answer within the same request.
Latency and cost depend on the measurement conditions
Google reports median model computation latency of 50–100 milliseconds and end-to-end latency of 150–250 milliseconds. The relevant performance passage covers contexts up to 16K tokens and says latency remains nearly flat as requests grow from one to 100 questions. Those conditions do not establish performance at 256K tokens or 1,000 questions. The supplied material also leaves workload, region, media duration, and tail latency unspecified. An accepted input limit and a measured performance range answer different engineering questions. Google AI
The announced price is $0.10 per million input tokens, with no output-token charges. Shared input is billed once per request, while each question adds its own instruction and criteria tokens. Image and video resolution can be adjusted, creating a tradeoff between visual detail and token cost. Google's claimed “nearly 5x cheaper” result against Gemini 3.5 Flash-Lite through the Interactions API applies to its shared benchmark suite. Our assessment is that an application budget must also include retries, fallback calls, and human review; removing output charges does not remove the other costs of reaching a usable decision.
Probabilities require local calibration
The three question types have distinct meanings. noul estimates the probability that a yes/no condition holds. choice returns a winner and normalized probabilities across two to 255 candidates. score returns a continuous weighted score and per-level probabilities for an ordered rubric starting at zero. Google also says every answer includes a confidence score between zero and one, but the announcement does not fully explain how confidence is calculated for each type. Answer probabilities, confidence values, and rubric scores therefore need separate interpretation: a weighted rubric score is not itself the probability that the judgment is correct.
Google claims the lowest calibration error across its benchmark suite, but the supplied material lacks detailed results, sample composition, and metric definitions needed to audit that claim. Calibration concerns whether similar predicted probabilities match observed frequencies across cases; it cannot certify an individual answer. Our inference is that normalization can still assign high probability to an incorrect option when the correct answer is absent. An “insufficient evidence” or “none applies” outcome may help, but its effectiveness needs testing. Changing the candidate set should also trigger threshold revalidation. Google AI
Multimodal evidence and agent execution have different limits
Consider the announcement's example of combining a claim PDF with damage photographs. A hypothetical workflow could check whether documents are complete, whether another photograph is needed, and whether descriptions conflict with visible evidence. Native multimodal input reduces the caller's need to translate every piece of evidence into text, but it does not guarantee recognition of small print, subtle damage, or relationships across pages. Lower resolution may save tokens while removing decisive information. If a subsequent question can only be defined after an earlier result, the workflow needs multiple stages and its latency must be measured again.
The announcement cites model routing in Gemini Notebook and MCP tool safety checks in Google Search. These internal examples do not establish equivalent gains for arbitrary applications. For cloud agent workflows, our recommendation is to use probabilities as routing inputs while deterministic authorization rules constrain tool execution. A safety classifier should not independently grant permissions. Low confidence can trigger fallback, and high-confidence predictions still need adversarial testing. The claims workflow and permission design described here are engineering recommendations, not verified deployments or evidence that this endpoint is integrated into Token4AI.
Validate the complete decision policy
Start by fixing labels, candidate options, and rubric definitions. Build business-specific examples covering missing options, ambiguous images, difficult audio, and instruction injection, then separate threshold tuning from a final held-out evaluation. Alongside accuracy, inspect reliability curves and Brier scores, with errors broken down by class and modality. Rubric tasks also need checks for errors between rating levels. Choose thresholds using the costs of incorrect acceptance, incorrect rejection, and review. Record both automated coverage and the error rate among automatically accepted decisions. These are proposed evaluation methods; this article reports no tests of its own.
For performance, compare a generative alternative using the same inputs, tasks, and acceptance criteria. Vary context length, question count, media resolution, and concurrency separately. Measure end-to-end median and tail latency, failures, and total cost including fallback. The hypothesis to test is that single-pass scoring reduces whole-workflow overhead when candidate sets are complete, input reuse is substantial, and fallback is uncommon. Long media, complex criteria, or frequent review may offset that gain. Evaluation should determine whether the complete workflow improves under the application's actual operating conditions.
Practical checklist
- Verify current account access, quotas, pricing, and platform availability against the documentation; the announcement does not establish Token4AI integration.
- Freeze candidate sets and rubric definitions, then test missing-answer and insufficient-evidence cases before selecting thresholds.
- Use a held-out dataset to assess calibration, automated coverage, and errors among accepted decisions, including breakdowns by modality and class.
- Measure latency and total cost across input sizes, question counts, resolutions, and concurrency, including retries and fallback.
- Test adversarial inputs and confirm that tool permissions remain enforced independently of model confidence.
References
Independent analysis by Token4AI. Vendor capabilities and availability on our platform are separate; consult the console for supported models and current pricing.