Gemini Decisions API: Features and Pricing

At a Glance

What Is the Gemini Decisions API?

The Gemini Decisions API is a Google API for making fast, bounded choices from supplied material. It is powered by Gemini Decision 1, identified as gemini-decision-1, and is available through the Gemini API in Google AI Studio. Unlike a general-purpose text-generation request, its central job is to score candidate options for one or more defined questions and return probabilities and confidence scores.

This distinction makes the API relevant to application logic rather than only user-facing chat. A system may need to select a destination for a request, check whether content meets a policy condition, choose which model should handle a query, or grade a context against criteria. Those tasks have a defined set of possible outcomes. The Decisions API is designed for that kind of bounded choice, where an application needs a decision signal rather than a paragraph that must later be interpreted.

Google says a request can contain shared multimodal input and as many as 1,000 independent questions. Supported input types include text, images, audio, video, and PDFs, with an input capacity of up to 256K tokens. The model scores candidate options in a single forward pass instead of generating an answer token by token. The API therefore targets workflows where many checks can be evaluated against the same material, rather than requiring a separate model request for every question.

The product name matters: this is Google’s Gemini Decisions API, not an OpenAI Decisions API. Google’s announcement directs developers to obtain an API key in Google AI Studio and provides Python, JavaScript, and REST guides. The API is also described as available through the Gemini API. Google’s announcement presents it as a purpose-built interface for fast, calibrated decisions, not as a replacement for every Gemini model or every generative AI task.

How Gemini Decision 1 Works

A conventional generative-model workflow often asks a model to read a document, produce a response, and explain its answer. That approach can be useful when the task genuinely requires language generation. For a fixed checklist, however, the application may only need a score for each possible outcome. Gemini Decision 1 is designed to evaluate options directly and return probabilities and confidence scores, rather than making generated prose the primary result.

The shared-input design is significant. An application can provide one body of material—for example, a document or other supported input—and ask multiple independent questions about it. Google states that the shared input is billed once per request, regardless of how many questions are evaluated. Each additional question adds its own instruction and criteria tokens. This can matter for a review workflow with many checks: the request does not need to resend the same underlying input separately for every question when those checks are included together.

Google reports 150–250 ms end-to-end latency for the described decision-scoring workflow. That figure is a reported product metric, not a guarantee for every request, workload, network path, or integration. Teams should measure their own end-to-end performance, including request preparation and whatever application work follows the model response.

In an application, a returned score should be treated as an input to the application’s decision process—not as proof that a case is unambiguous. The available product description establishes that the API returns probabilities and confidence scores; it does not prescribe a universal threshold or a complete human-review policy. Developers should define their own handling for uncertain, conflicting, or out-of-scope cases rather than assuming a model score automatically settles them.

What Makes It Different?

The core difference is that Gemini Decisions API is built around scoring choices, not composing an open-ended answer. Developers specify questions and candidate options, provide shared input, and use the returned scores in a larger workflow. This is a purpose-built fit for tasks such as tool selection, policy checks, model routing, and context grading—the examples Google identifies for the API.

That design can reduce the need to ask a generative model for a prose answer and then build another layer to extract a label from it. It does not remove application engineering. The developer still defines the question, criteria, permissible options, and downstream behavior. The API returns a decision signal; application code determines what happens next.

Multimodal input is another notable feature. A single request can work across text, images, audio, video, and PDFs, according to the announcement. That makes the API potentially relevant when a decision depends on more than a short text field. The maximum described input size is 256K tokens, and the API can evaluate up to 1,000 independent questions against shared input. These capabilities distinguish the described use case from a workflow that repeatedly sends the same source material in separate calls.

The product should not be mistaken for a general assistant. Its purpose is not to draft a report, carry on an unrestricted conversation, or generate long-form content. If the result needs to be an explanation or a composed response, a generative model may be more appropriate for that part of the workflow. Gemini Decisions API is most compelling when the outcome can be represented as a set of candidate choices and the application benefits from scoring those choices directly.

Practical Use Cases for Developers

Model routing

A platform can use a bounded decision to route incoming requests among a defined set of models or processing paths. Google identifies model routing as a target use case. The decision layer can assess the supplied request and score eligible destinations; the application then applies its own routing logic. Google’s source also says Gemini Notebook uses the model to route queries to different models and levels of reasoning effort, and reports up to 40% lower latency for routine queries in that workflow. That result is a reported example from that specific workflow, not a general performance promise for every customer integration.

Policy checks and review triage

For a policy workflow, developers can define a question and candidate outcomes that represent the checks their application needs to perform. The API is described for policy checks and can score multiple questions against shared material. A team might use that pattern to determine which cases need further review, provided the application independently defines its policies and operational response. The API itself should not be described as a complete policy-management system or a replacement for human review.

Context grading

Retrieval and knowledge workflows often need to assess whether supplied context is suitable for a downstream task. Google identifies context grading as a purpose-built use for the API. A developer can frame a bounded evaluation around the available criteria and use the returned scores in the application. As with other uses, the quality of the result depends on the actual criteria and input, so teams should validate the decision behavior against representative examples.

Multimodal document and media checks

Because the API accepts text, images, audio, video, and PDFs, it can be evaluated for workflows where a checklist applies to different kinds of source material. A team might have multiple defined questions about one file or recording and evaluate them together, rather than issuing a separate request for each check. The verified product details support these input types and the multi-question structure; they do not establish specific industry templates or guaranteed accuracy for any particular document-review task.

Many checks against shared material

The 1,000-question capacity is relevant when a workflow needs to evaluate a large checklist against a common input. The practical benefit is not simply a high question count: shared input is billed once per request, while each question adds its own instruction and criteria tokens. Developers should still test request size, question design, response handling, and cost with their own workload before choosing how to group checks.

Example Workflow: Evaluate a Shared Input

The following is a conceptual workflow, not a request-format example. Google’s announcement directs developers to its Python, JavaScript, and REST documentation for implementation details. In a real integration, follow the current official guide for the supported request syntax and response fields.

1. Obtain an API key in Google AI Studio and consult the Gemini Decisions API documentation.
2. Choose a supported input type and provide the shared material, staying within the documented input limit.
3. Define each question, its criteria, and the candidate options the application needs scored.
4. Submit the request through the documented Gemini API interface and inspect the returned probabilities and confidence scores.
5. Apply application-defined handling to the result, including an appropriate path for cases that do not meet the application’s decision criteria.
6. Measure quality, latency, and token usage with representative data before expanding the workflow.

Shared input: A document or other supported source material

Question 1: Which of the defined categories best fits this input?
Question 2: Does the input meet the stated review criterion?
Question 3: Which of the approved processing paths is the best match?

Application responsibility:
Use the documented API request format, inspect the returned scores,
and apply application-defined handling to the selected outcomes.

Pricing: Is Gemini Decisions API Worth It?

Google lists Gemini Decision 1 at $0.10 per 1 million input tokens and $0 for output tokens. Google also offers an API no-cost tier in Google AI Studio for prototyping. According to Google’s pricing description, shared input is billed once per request, regardless of the number of questions evaluated; each question adds its own instruction and criteria tokens. Google says there are no output-token charges, variable thinking-token bills, or separate audio-transcription and OCR costs for the described API usage.

VentureBeat reports that Google’s free-tier limits include 200 requests and 50,000 input tokens per minute. Treat those as reported limits and confirm the current quota and applicable terms in Google’s own documentation before planning a production workload. Free access is useful for prototyping, but it should not be confused with unlimited capacity.

The shared-input billing model can make multi-question evaluation more economical than repeatedly resending the same source material in separate requests. VentureBeat illustrates this with a cost comparison based on a 4,000-token record and 20 checks that add 50 tokens apiece: the example estimates about $0.50 per 1,000 records for one shared-input request, compared with $8.10 per 1,000 records for 20 separate calls that each resend the record. Those figures depend on the stated token assumptions and the described pricing; actual costs vary with billed input and request structure.

For teams with many checks against the same text, document, recording, or other supported input, the combination of low input-token pricing, no output-token charge, and shared-input billing is an explicit value proposition. The API may be less compelling for a simple classification that can be handled by a smaller or less expensive service, or where a general model already performs the task within acceptable cost and quality targets. Compare like-for-like workloads, including retries and any separate calls your design requires.

Limitations and Considerations

It is specialized, not a general-purpose generator. The API is designed for bounded choices. Teams that need a drafted answer, a long explanation, or open-ended content should not assume that a decision-scoring interface is a substitute for a generative model.

Request design still matters. Developers must formulate useful questions and criteria and decide how candidate scores affect application behavior. The existence of probabilities and confidence scores does not, by itself, define a safe threshold or settle how ambiguous cases should be handled.

Free-tier capacity is limited. The no-cost tier is intended for prototyping. VentureBeat reports limits of 200 requests and 50,000 input tokens per minute. Verify the current limits and account conditions before relying on the tier for ongoing usage.

Some integrations are not equally mature or available. VentureBeat reports that developers can access the model through OpenRouter and Vercel AI Gateway, with Vercel directing users who work with audio, video, or PDFs to its AI SDK 7 integration. Google Cloud support is described as coming, not as already available. Teams should check the chosen provider’s current model and modality support rather than assuming every route exposes identical capabilities.

Validate the reported performance in your own environment. Google describes 150–250 ms end-to-end latency, but the available product information does not establish that every workload will achieve that result. Input modality, request size, integration path, and application-side work can all affect the experience; measure the complete workflow you intend to deploy.

Confirm current API details before implementation. VentureBeat reports that developers can start through a v1beta endpoint. Use the current Google documentation for the supported endpoint, request schema, model availability, quotas, and integration guidance rather than copying an implementation from a secondary report.

Verdict

Gemini Decisions API addresses a specific, useful engineering problem: evaluating multiple bounded choices against shared input without turning every result into a generated paragraph. Gemini Decision 1 supports multimodal inputs, can evaluate up to 1,000 questions in one request, and returns probabilities and confidence scores. The reported pricing—$0.10 per 1 million input tokens and zero output-token charges—makes the shared-input approach worth testing for workloads with repeated checks against the same material.

It is best suited to developers building model routing, policy checks, context grading, and similar decision workflows. It is not a universal AI assistant, and the API does not remove the need to design criteria, validate results, or define application behavior. Start in Google AI Studio, review the official API guides, and benchmark your actual workload before committing to an integration. For teams in the GCC and wider Middle East, the same evaluation approach applies, but confirm access, quotas, and service terms directly with Google; the available verified material does not establish region-specific availability.

Sources and Further Reading

• Google: Gemini Decisions API — Fast, calibrated multimodal decisions
• VentureBeat: Google’s Gemini Decision 1 model scores up to 1,000 questions in one API call
• Google AI for Developers

Editorial review by the Gate of AI Editorial & Engineering Teams. GateOfAI, LLC is a Delaware, USA company.