Gemini Decisions API Pricing: How Shared Inputs Change the Cost

Google launched the Gemini Decisions API and gemini-decision-1 on November 11. It costs $0.10 per million input tokens, with no output-token charge. For developers checking the same document against several rules, the important detail is that shared input is billed once per request.

A closed-set decision means choosing among answers you define, rather than asking a model to write an answer. That makes this worth considering for a specific part of an application: deciding which queue, tool or review path should receive an input before a more expensive workflow starts.

Gemini Decisions API pricing and limits

Google’s launch announcement lists text, images, audio, video and PDFs as supported inputs. A request can include up to 256K tokens and 1,000 independent questions. The question types cover yes/no checks, multiple choice with 2–255 options, and ordered rubric scoring.

The pricing page separates the shared input from each question’s instructions, criteria and formatting. All of those question tokens still count. Output is zero tokens, rather than an allowance you can accidentally exceed.

Item	Gemini Decision 1
Paid input price	$0.10 per million tokens across supported modalities
Output charge	None
Free tier	Available
Context caching	Not available
Batch API	Not supported
Product-improvement use of content	Yes on free tier; no on paid tier, as listed by Google

Combining questions in one request is different from using the Batch API. You can evaluate several checks against shared material without assuming an additional asynchronous batch discount. Nor should you budget for cached-input discounts that the model’s pricing table does not offer.

A worked cost example: ten checks against one document

Consider a hypothetical document-processing workflow. Each document contributes 10,000 input tokens, and each of ten checks contributes another 100 tokens of instructions, criteria and formatting. These are planning assumptions, not measured token counts or a test result.

Putting all ten checks in one request gives 11,000 billable input tokens. At $0.10 per million, that is $0.0011 per document, or $11 for 10,000 documents.

Making ten separate requests repeats the 10,000-token document ten times. The total becomes 101,000 tokens per document: $0.0101 each, or $101 for the same 10,000 documents. Grouping the checks saves $90 in this example, before retries, downstream generation or human review.

The arithmetic explains where this design is useful. A long shared input and short questions create a large saving. A tiny input surrounded by lengthy rubrics leaves much less repeated material to remove. Measure both rather than treating the maximum question count as an efficiency target.

How to design a document-triage workflow

Start with one narrow operational decision. For an incoming vendor document, that might be whether it contains the required purchase-order reference, whether essential fields are missing, and which review queue should receive it. Define what each answer means before adding more questions.

Keep independent checks together. If the second question needs the first answer to determine which policy applies, separate that dependency in your application instead of pretending both checks can be evaluated independently against the same input. A shorter request that matches the business process is more useful than a thousand loosely related questions.

Include an exception path in the queue options. Otherwise, an incomplete or unfamiliar document can still be pushed toward the least-wrong available destination. Route questionable cases to review, and keep the document and returned scores available for investigating misclassifications under your retention policy.

This is also where deterministic validation belongs. If a required identifier must match a database record, perform that lookup in code. A model’s assessment that an identifier looks plausible is not evidence that the record exists.

Confidence scores need your own acceptance test

A probability score is not permission to automate a consequential action. Pick a threshold using labelled examples from your own workflow, then measure the mistakes that matter: incorrect automatic approvals, unnecessary reviews and cases the system cannot classify.

A useful first rollout is shadow mode. Let the decision run alongside the existing process without changing its outcome, then compare the proposed routes with the routes reviewers actually chose. Include incomplete scans and unusual document layouts, not only clean examples. This is a suggested evaluation procedure, not a test conducted for this article.

For independent context, Simon Willison’s launch-day notes describe his own video experiment and the probabilities it returned. That small example helps illustrate the interface; it does not establish reliability for another company’s documents or policies.

What to check before adopting it

Google’s reported 150–250 ms end-to-end latency is a vendor measurement, with its near-flat latency discussion covering contexts up to 16K tokens and one to 100 questions. Do not extend that claim to a full 256K-token request with 1,000 questions. Benchmark the request size you intend to send.

Google Cloud support is still described as coming soon. Verify your project’s actual quota and deployment requirements before building a migration plan around it. This article does not establish a universal requests-per-minute allowance.

The strongest starting point is a repeated, bounded decision over material you already process. Group the independent checks, count the entire input, and evaluate the fallback workload. The cheapest classification call is not necessarily the cheapest workflow if it creates more manual cleanup afterward.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product decisions and complex engineering into clear stories that developers can use and share.

Book a 30-minute call