Gemini Decision 1 always spreads probability across your options and never returns a perfect 0 or 1 on yes or no questions, so a routing rule built on a threshold of 1.0 or on a missing option will quietly misroute. Set thresholds inside 0.01 to 0.99, add an explicit catch all option, and check confidence before acting.
Google's new Gemini Decisions API, launched on November 11, 2026 and powered by gemini-decision-1, scores many structured questions against one shared input and returns numbers instead of prose. That makes it easy to wire into code, and it also makes a few documented behaviors easy to trip over. Google's documentation says the score for a yes or no question ranges from 0.01 to 0.99, so a threshold above 0.99 never matches. If your routing rule says to auto approve only when the model is certain, and certain means 1.0, that rule will never fire.
The second trap is choice questions. Google's documentation says choice questions always distribute probability across the options and have no built in none option. Whatever you send, the model has to place its probability somewhere. The documentation gives three ways to cope: use a confidence threshold, pair the question with a separate scope check, or add an explicit catch all option such as other with a clear description. The catch all is the most robust, because it gives the model an honest place to put an input that fits nothing. Also remember that option keys sort alphabetically by UTF-8 bytes, so exact ties go to the alphabetically first key. Do not rely on a key name to win a tie.
Write each question so it stands alone. The documentation says the model never sees question keys, so the full question must be written in the instructions field. A key like refund_eligible tells the model nothing. For score questions, Google says 2 to 255 levels are supported with 2 to 10 recommended, indexed from 0, and that a score can fall between levels, so check the probabilities and confidence before acting on it. Where a decision depends on numbers or dates, the documentation advises comparing them in code and passing the result to the model as a named bucket instead of asking it to do arithmetic.
Finally, plan for cost and volume. A request accepts 1 to 1,000 questions, and the input field is the shared context for all of them. Google's documentation says context caching, the Batch API, and Flex or Priority inference are not supported, so repeated input is counted in full on every request. At the launch price of $0.10 per 1 million input tokens, with output tokens always 0 in the usage object, the way to save money is to put all of your questions about one document into one request rather than sending the document again and again.
Try it today
- Set every yes or no threshold inside 0.01 to 0.99, never at 1.0, and test the rule against a few labeled examples.
- Add an explicit catch all option such as other, with a clear description, to every choice question, or pair it with a separate yes or no scope check.
- Write the complete question in the instructions field, because the model never sees the question key.
- For score questions, keep to 2 to 10 levels indexed from 0, and check probabilities and confidence before acting on a score that falls between levels.
- Compare numbers and dates in your own code and pass the result as a named bucket.
- Batch all questions about one input into a single request, since caching and the Batch API are not supported.