Google introduced the Gemini Decisions API on November 11, offering developers a model that selects among defined outcomes rather than writing an answer. The release targets software decisions such as classification and request routing, where a paragraph of generated text may be unnecessary.
According to Google’s announcement, Gemini Decision 1 accepts multimodal input, including text, images, audio, video and PDFs. A request can contain up to 256,000 input tokens and 1,000 separate questions. Those are capacity limits, not a promise that every request will finish equally quickly.
What the API returns instead of prose
Google AI Studio’s documentation describes three response types: a yes-or-no probability, a selection from a fixed list, or a score against an ordered rubric. Responses also include confidence information that applications can use when deciding whether to proceed or escalate a case.
The documentation says questions are evaluated independently against shared input. One question cannot read another question’s answer. Google therefore recommends small, focused checks whose results are combined in application code, rather than treating a single request as a chain of reasoning steps.
Pricing and performance need separate checks
Google lists pricing at $0.10 per million input tokens, with no output-token charges because the model generates no text. The announcement reports end-to-end latency of roughly 150 to 250 milliseconds in tests using contexts up to 16,000 tokens and between one and 100 questions. That benchmark does not establish performance at the maximum request size.
The practical distinction is between a classification service and an assistant. For example, a developer could define categories for incoming support requests and use the returned scores to select a queue. That hypothetical workflow would still need an explicit rule for cases that do not fit the available categories.
Confidence is a design input, not permission
The API documentation positions confidence as a signal for automatic handling or escalation. It also specifies that applications receive typed answers directly, avoiding the need to extract a decision from free-form text. Developers should still test whether those signals behave usefully on their own examples.
A sensible evaluation would include ambiguous requests, incomplete records and cases that belong in none of the proposed categories. Those are editorial recommendations, not additional Google product features. Teams should decide in advance which errors are tolerable and which decisions must remain with a person.
Where this fits in an application
The main architectural question is whether the task has a bounded set of acceptable outcomes. Routing a ticket is different from composing a reply. A system could use a classifier for the first step and a generative model for the second, while keeping their permissions and failure handling separate.
The release gives developers another component to evaluate, not a reason to remove safeguards. Buyers should measure complete workflow cost, accuracy and response time together. A fast answer has little operational value if the surrounding application cannot recognize uncertainty or recover from a wrong decision.
