Google launched the Gemini Decisions API on November 11, 2026, powered by gemini-decision-1. It evaluates bounded questions rather than writing a conversational answer. For businesses building agents, the interesting opportunity is not another chatbot: it is a cheaper, more measurable decision step between incoming work and the system that handles it.
This guide was published November 12. Product facts come from Google's announcement and developer documentation; the deployment framework and worked examples below are Nerova analysis, not results from a live benchmark.
What launched, and where can developers access it?
Google's announcement describes access through Google AI Studio and the Gemini API, with Google Cloud support coming later. It supports text, images, audio, video and PDFs, with up to 256K input tokens and 1,000 questions. The stated price is $0.10 per million input tokens, with no billed output tokens. Google reports typical 150–250 millisecond end-to-end latency for its stated smaller workloads, not a guarantee for every maximum-size request.
How the answers differ from a chat completion
The API documentation defines three types: yes/no (noul), a fixed choice, and an ordered rubric score. Questions share input but cannot read one another's answers. For yes/no, the returned probability means “yes”; confidence measures certainty in either direction. Choice probabilities sum over the offered alternatives, even when none fits. A rubric score summarizes a distribution across ordered levels.
For an application designer, these distinctions change the contract. “Is this a billing request?” and “Should we refund this customer?” are different questions. The first describes a message. The second embeds policy, account history and permission to move money. A model can help classify the message without being allowed to approve the transaction.
A practical routing design for support teams
Consider a hypothetical business receiving messages about invoices, product problems and sales inquiries. Start with one narrow task: suggest the destination queue. Keep the existing queue assignment running while logging the proposed alternative. A reviewer can compare both with the correct destination without changing what customers experience.
- Define the labels. Write examples of what belongs in billing, technical support and sales. Include mixed requests and messages that do not belong anywhere.
- Record ambiguity. Give uncertain or unfamiliar messages a review path instead of forcing every message into a business category.
- Separate classification from action. A routing recommendation must not authorize account changes, refunds or disclosure of customer records.
- Validate each boundary. Test a message asking about a refund policy separately from one reporting an unauthorized charge. Similar words can require different treatment.
Do not let one model answer silently become the assumed input of another question in the same request. If the second judgment genuinely depends on the first result, make that dependency explicit in application code and evaluate the combined workflow.
What $0.10 per million input tokens means in a budget
As a simple arithmetic example, 100,000 requests averaging 2,000 total billed input tokens would consume 200 million tokens: $20 in model input charges at the stated rate. At 10,000 tokens each, the same request volume would imply $100. These are hypothetical calculations, not a quote for a particular deployment.
Use the API's reported usage rather than word count to reconcile an invoice. A message is not necessarily the entire billed input: instructions and question definitions also matter. Keep infrastructure, storage, human review and downstream model calls outside that narrow token-cost estimate, then add them back when comparing whole workflows.
The useful denominator is a correctly completed task. Suppose routing saves a fraction of a cent but introduces expensive reassignment work. The low token bill is real, yet the workflow may still be a regression. Conversely, avoiding unnecessary calls to a larger model can matter even if this decision step adds another network request.
How to evaluate confidence without trusting it blindly
Build a labeled holdout set that was not used to tune instructions. Include routine cases, rare expensive mistakes, languages your customers use, attachments and deliberately confusing wording. Report results by category as well as overall: a large easy category can hide a small but serious failure mode.
For each candidate threshold, count correct automatic routes, incorrect automatic routes and cases escalated for review. Choose a threshold based on the cost of those outcomes, not the largest-looking confidence number. A score of 0.9 is a model output to validate, not proof that nine out of ten future decisions will be correct on your traffic.
Measure p50 and p95 latency at your actual payload sizes and concurrency. Include timeouts and retries. For a customer-facing workflow, a fast median does not compensate for a slow tail or failures that leave a request unprocessed.
When not to replace an existing rule
If a deterministic rule already answers the question exactly, keep it. An explicit account identifier, a signed entitlement or an exact order status should usually be checked against its authoritative system. Add model judgment where the input is genuinely ambiguous, not where a database lookup would be both clearer and more reliable.
Our recommendation is a reversible shadow trial followed by a narrow rollout, with rollback criteria agreed before launch. Promote the new route only when it improves cost per correct outcome without worsening the error categories that matter. Gemini Decision 1 is worth evaluating as an agent component; its release alone is not evidence that a business should replace its current production routing.
For context on the wider category, read our OpenAI Decisions API GA coverage. Compare the products on the same labeled tasks rather than treating similarly named APIs as interchangeable.