Table of Contents
Gemini Decision 1: Google's API for fast yes/no and multiple-choice calls
Ask a chat model whether a customer's package arrived damaged and it will still write you a sentence back, even when all your code actually needs is a number between 0 and 1. Google's answer, shipped November 11, is a model that never writes the sentence. Gemini Decision 1 scores your candidate answers directly and returns a probability with a confidence value in 150 to 250 milliseconds, per Google's announcement. One call can carry up to 1,000 of these scored questions at once, spanning text, images, audio, video, or PDFs, and Google bills $0.10 per million input tokens with nothing charged for output. We went through the docs line by line to see what that buys an agent builder who is currently burning a full chat completion just to route a support ticket.
Score instead of generate: how the three question types work
Gemini Decision 1 runs your input through Gemini's multimodal encoder once, then scores every question against that shared context in a single forward pass instead of decoding an answer token by token, according to Google's launch post from DeepMind product manager Min Choi and principal scientist Felix Yu. No next-token sampling means no output tokens to bill, and it means latency barely moves whether you ask one question or a hundred: Google reports the model-compute floor stays at 50 to 100 ms and the latency curve holds "nearly flat from 1 to 100 questions per request."
Every question you send is typed as one of three things:
noul(yes or no): the calibrated probability that a statement holds, bounded between 0.01 and 0.99, plus a confidence score.choice: pick one option from a list of 2 to 255, with normalized probabilities returned for every candidate.score: rate the input against an ordered rubric starting at 0, returning a weighted average plus a probability for each level.
Yes, the yes/no type really is named noul in Google's own SDK and API reference, not bool. We checked both the launch post and the decisions-api reference page twice before believing it.
Google's quickstart shows the minimal shape of a request:
from google import genai
client = genai.Client(http_options={"api_version": "v1beta"})
result = client.decisions.create(
model="gemini-decision-1",
input="The blue mug I ordered on Monday arrived cracked on Wednesday.",
questions={
"is_damaged": {
"type": "noul",
"instructions": "Did the item arrive damaged?",
},
},
)
answer = result.answers["is_damaged"]
print(f"P(yes)={answer.noul:.2f} confidence={answer.confidence:.2f}")
The response carries a probability and a confidence value, and nothing that resembles a written answer, per the Decisions API reference:
{
"answers": {
"is_damaged": { "type": "noul", "noul": 0.99, "confidence": 0.99 }
},
"usage": {
"total_input_tokens": 100,
"total_output_tokens": 0,
"total_tokens": 100
}
}
That single-question example undersells it, though. The real pitch is stacking all three types against one shared input in one call. Google's own demo feeds the model a photo of a breakroom counter plus a short note, then asks three different things at once: is there a spill, which cleanup action fits, and how severe is the mess. Three answer shapes, one forward pass, one bill.
Getting it running
Setup skips training a classifier entirely. The process is four steps:
- Install an SDK built on version 3.2 or later:
pip install -U google-genai(Python) ornpm install @google/genai@latest(JavaScript). - Grab an API key in Google AI Studio. A no-cost tier covers prototyping before you need billing turned on.
- Call
client.decisions.create()withmodel="gemini-decision-1", your sharedinput, and aquestionsmap. Question keys are whatever strings you pick (up to 64 characters), and the model never sees those keys, only theinstructionstext, so write the real question there. - Read
confidencealongside the answer and set a threshold in your own code. Google's docs recommend routing anything under that threshold to a fallback model or a human reviewer rather than trusting the top answer blindly.
Integrations are rolling out for OpenRouter, LangChain, Vercel's AI SDK, LiteLLM, Pydantic AI, Pipecat, and LiveKit, with Gemini-on-Google-Cloud support still pending, per Google's post.
What it costs, and the real catch in "zero output tokens"
Per Google's launch post, the headline price is $0.10 per million input tokens with no charge for output, cache reads, or anything else. Your shared input is billed once per request no matter how many questions ride along; each additional question only adds the tokens in its own instructions and criteria fields. Google frames the result as "nearly 5x cheaper" than running the same workload through Gemini 3.5 Flash-Lite on the Interactions API, since that comparison model still has to decode and bill output tokens for an answer Decision 1 never writes.
Read the latency number carefully, though. Google's own reference page describes the 150 to 250 millisecond figure as end-to-end, including network time; the model-compute portion alone runs 50 to 100 ms, and that holds for contexts up to 16,000 tokens. Push the shared input toward the full 262,144-token ceiling and the latency math changes, though Google has not published where the curve bends.
Inside Google, the API already runs as the router in front of other models: Gemini Notebook uses it to pick a model tier and thinking level per incoming query, which the company says shaves up to 40% off latency for everyday requests by reserving the expensive reasoning models for the queries that actually need them.
The limits that matter before you wire this in
A few numbers from the reference table in Google's docs are worth pinning down before you build around them:
| Limit | Value |
|---|---|
| Questions per request | 1 to 1,000, bounded by the 262,144-token context window |
Options per choice question | 2 to 255 |
Levels per score question | 2 to 255 (Google recommends 2 to 10 for most rubrics) |
| Question key length | 1 to 64 ASCII characters |
| Context window | 262,144 tokens, shared input plus all questions combined |
Three gotchas sit underneath those numbers. First, questions cannot see each other inside one call: there is no multi-step reasoning or chaining, so anything that needs a second question to depend on the first answer has to happen in your application code, not inside Decision 1. Second, option keys for choice and score sort alphabetically on the way back, so if you add a catch-all bucket, Google's docs tell you to key it other rather than something like none_of_the_above, or the sort order quietly misleads whoever reads the raw response. Third, when Decision 1's safety filters trip, the API does not return a low-confidence answer; it returns an HTTP 400 with a typed error.code (safety, prohibited_content, blocklist, image_safety, or content_blocked), so your retry logic needs a branch for "no answer at all," not just "low confidence."
And the structural limit: Decision 1 only scores closed-ended questions, so it can't generate prose, call tools, or chain reasoning steps. Google's own docs point you back to the Interactions API the moment you need generated prose, extracted JSON against your own schema, or a model deciding which tool to call next.
Where it sits next to OpenAI's Decisions API and AWS Strands Decider
Gemini Decision 1 is the third major-vendor entrant in a category that barely existed two months ago. Pondero already covered the other two: AWS's Strands Decider 2B launch and OpenAI's Decisions API. Lined up, the differences land on access model more than raw numbers:
| Gemini Decision 1 | OpenAI Decisions API | AWS Strands Decider 2B | |
|---|---|---|---|
| Access | Hosted, Google AI Studio, live now | Hosted, beta since October 6 | Open-weight checkpoint, self-hosted |
| Price | $0.10 / 1M input tokens, $0 output | $0.10 / 1M input tokens, $0 output | No API fee; your own compute |
| Latency (vendor-reported) | 150 to 250 ms end-to-end | ~150 ms per OpenAI's DevDay materials, not yet independently benchmarked | ~115 ms median on an Nvidia RTX 3090 |
| Questions per call | 1 to 1,000 | No published cap yet | One scored decision per call |
| Modalities | Text, image, audio, video, PDF | Text, image | Text (Qwen3.5-2B base) |
| Source | Google's launch post | OpenAI's API changelog | AWS Strands Labs announcement |
Per Google's own numbers and OpenAI's published pricing, the two hosted vendors landed on exactly $0.10 per million input tokens with free output, specific enough to be worth noting rather than a coincidence: the category converged on a price point before anyone published independent latency benchmarks to compare against it. Access splits them instead of price. AWS shipped the only checkpoint you can download, inspect, retrain, or run fully offline, while Google and OpenAI both keep you on their metered infrastructure. If your agent stack already lives inside one of those hosted ecosystems, that distinction matters more than a 35-millisecond gap between vendor-reported latency numbers that nobody outside the vendors has verified yet.
Who should wire this in this week
If you are already calling Gemini elsewhere in your pipeline, put the Decisions API in front of anything that currently burns a full chat completion on a yes/no or routing call. The price undercuts a standard completion by design, it is live today with no waitlist, and the noul/choice/score split maps cleanly onto the moderation gates, intent routers, and tool-selection checks most agent builders are already hand-rolling with prompt engineering.
If your governance story requires owning the weights, inspecting the training recipe, or running fully offline, none of Google's or OpenAI's hosted options clear that bar; AWS's Strands Decider 2B is the only one of the three you can actually take home. And if you are deep in OpenAI's stack already, there is no pricing reason to switch: the two hosted options are priced identically, so the choice comes down to which API you are already paying for, not which one claims the faster number on a page neither vendor has let anyone outside their own team verify.