Gemini Decisions API: Google’s Model That Writes No Text
Google has released the Gemini Decisions API, a new endpoint powered by a model called Gemini Decision 1 that does something generative models are not built to do. It writes nothing. You send one multimodal input and up to 1,000 typed questions, and it returns calibrated probabilities. Your code branches on the numbers directly, with no text to parse. The Gemini Decisions API is a structural break from how models have been sold.
The model identifier is gemini-decision-1, and it went live on 11 November in Google AI Studio and the Gemini Developer API at v1beta, requiring the google-genai SDK 3.2 or later. The pricing is 0.10 dollars per million input tokens, with zero output tokens billed, because there are none.
A no-cost tier exists for prototyping in Google AI Studio, and demo apps named Doorstep Parcels, Speed Sketch and Find the Zoo Keeper ship alongside the documentation. The Gemini Decisions API team also published Python, JavaScript and REST guides.
Google DeepMind principal scientist Felix Yu announced the release on Google's blog. Sundar Pichai summed up the design philosophy in a post on X: not every problem needs a full response from an LLM. Sometimes you just need a fast, structured decision.
The Gemini Decisions API is aimed at the smallest, most numerous calls in an agent's workflow: routing, tool selection, policy checks, safety filters and grading.
Those decisions have traditionally required either a generative call whose text has to be parsed, or a bespoke classifier that has to be trained and maintained. The Gemini Decisions API proposes a third option, and the ecosystem's reaction will show whether the market agrees.
For context on where agents spend their tokens, our coverage of Muse Ember and programmatic tool calling describes the same trend from the model side. Independent analyses from SCCC and CellCog add the caveats this article draws on.
What the Gemini Decisions API actually does
A request to the Gemini Decisions API has three parts: a model identifier, a shared input, and a map of questions. The shared input accepts text, images, audio, video and PDFs, up to 262,144 tokens combined. Inline uploads can reach 100MB per request, or 50MB for PDFs.
The questions come in three types, and each returns structured numbers rather than text.
The yes and no type, called noul in the documentation, estimates the probability that a condition holds. The result is bounded between 0.01 and 0.99, with optional criteria defining what counts as true or false.
The choice type selects from 2 to 255 options and returns normalised probabilities for every candidate. Options are sorted alphabetically before scoring, so list order cannot bias the result.
The score type grades the input across 2 to 255 ordered rubric levels, returning a probability for each level and a probability-weighted score.
Google's own arithmetic example shows why the single-request design matters. A 2,000-token document with 50 checks of 40 tokens each is roughly 4,000 tokens in one request, or 102,000 tokens as 50 separate generative calls.
Every answer carries a confidence value from 0 to 1, and Google's guidance is to route low-confidence cases to a fallback or a human reviewer. Questions run in parallel and cannot see one another, so adding, removing or reordering one question does not change the scores of the others. That independence is a real property for production systems, because it means a checklist can be extended without re-validating every previous check.
A concrete example from Google's documentation shows the shape of it. A support team could send a customer's voice note once and ask, in the same request, whether it is a refund request, which team should handle it and how urgent it sounds. Three questions, three structured answers, one bill for the audio.
Why scoring instead of generating changes the economics of decisions
Standard models decode an answer token by token, and the developer parses that text or JSON. Gemini Decision 1 instead scores the candidate options in a single forward pass, and the entire cost structure follows from that design.
Billing treats the shared input as billed once per request, however many questions ride along with it. Each question adds only its own instruction and criteria tokens. There are no output-token charges, no variable thinking-token bills, and no separate audio transcription or OCR costs, because the model reads the media natively. The economics of the Gemini Decisions API follow directly from that billing design.
Google reports median model compute of 50 to 100 milliseconds and 150 to 250 milliseconds end to end for inputs up to 16K tokens, staying nearly flat from 1 to 100 questions per request. The math of bundling is where the savings concentrate. Take a 2,000-token document and 50 checks of 40 tokens each: as one request that is roughly 4,000 tokens. As 50 separate generative calls it is 102,000 tokens or more, once you add the repeated context. The same decision coverage, ordered of magnitude cheaper.
Against Gemini 3.5 Flash-Lite running Google's own Interactions API, the company claims the Gemini Decisions API is nearly 5 times cheaper across its shared benchmark suite, 0.88 dollars versus 4.14 dollars. The arithmetic works out to about 4.7 times, and the comparison set includes the generative path doing the same job worse, which is the point.
How teams are using the Gemini Decisions API
Four internal Google deployments are named in the announcement, and they illustrate the intended shape of the product better than any feature list.
Gemini Notebook uses the Gemini Decisions API as a real-time router. It classifies each incoming query in milliseconds to pick the optimal model tier and thinking level. Google says that serves everyday queries with up to 40 percent lower latency, while reserving deep reasoning models for complex tasks.
Stitch's rapid canvas experiment uses the Gemini Decisions API to generate playable wireframes of a product flow in seconds. Edits made by voice or tap are applied almost instantly, handing off to the full Stitch experience when the flow feels right. CC from Google Labs uses it to pick an emoji reaction from a palette of more than 200 options in a fraction of a second. And Google Search uses it as a safety layer, detecting adversarial behaviour and content against adversarial evals within the latency envelope.
Those four use cases share a shape: a bounded decision inside a latency budget, where generating text would be slower, more expensive and less reliable than scoring options. That is the market the Gemini Decisions API is built for, and Google's own products are its first customers. The Search deployment is the most telling. A safety filter that flags adversarial MCP tool calls has to be fast and has to be right, and a generative model writing a safety verdict would fail on both counts.
The benchmarks, and the asterisks on them
Google published a nine-benchmark table comparing Gemini Decision 1 against TypeSafe Jev 1.14, OpenAI's GPT-6 Luna running the OpenAI Decisions API, and Gemini 3.5 Flash-Lite. All figures are the Gemini Decisions API team's own measurements. The table notes that refusals and requests a model could not accept count as incorrect.
Gemini Decision 1 ranks first on seven of the nine. JevBench, a public decision benchmark, comes in at 92.2 percent against 90.0 for Jev 1.14 and 90.9 for GPT-6 Luna. Amazon ESCI shopping relevance scores 58.7 percent Macro-F1, New Yorker Caption hits 79.7 percent, PubMedQA 79.8 percent, non-English Global-MMLU-Lite 86.0 percent, the audio benchmark MMAU 71.8 percent and Video-MME without subtitles 69.1 percent. The audio and video tests have no score for Jev or GPT-6 Luna, because those models do not accept those inputs.
Two tests go to the rival. Jev 1.14 leads on Mind2Web Multimodal, 86.8 percent to 86.2 percent, and on When2Call, the tool-routing benchmark, 82.0 percent to 79.9 percent. And Jev is cheaper across the seven shared benchmarks, 0.68 dollars to 0.88 dollars, with an input list price of 0.042 dollars per million tokens against Google's 0.10.
The clearest gap is calibration, which measures whether a model saying it is 80 percent sure is actually right about 80 percent of the time. Gemini Decision 1's top-1 expected calibration error is 0.0250, roughly half of Jev's 0.0494, with GPT-6 Luna at 0.0721 and Flash-Lite at 0.2104. For a product whose entire value proposition is routing automation on confidence thresholds, calibration is not a vanity metric. It is the difference between an automation threshold that works and one that silently routes wrongly, and it is the single strongest number in the Gemini Decisions API launch.
The asterisks are real. These are Google's own tests, run on Google's own benchmark suite, and no independent evaluation has been published. CellCog's detailed fact-check of the launch notes that nobody outside Google has repeated the tests, and that the benchmark table was read from an image in the announcement. Treat the table as the vendor's opening claim rather than a settled result.
How a decision pipeline is built on the Gemini Decisions API
For a developer wiring this into an agent, the Gemini Decisions API replaces three separate pieces of machinery, and the replacement pattern is worth walking through.
Consider an agent that handles support tickets. Today it might call a generative model with a prompt asking whether the message is a refund request, parse the text, and hope the answer is stable. Then it would call the same model again for urgency and again for routing. With the Gemini Decisions API, those become three questions on one shared input: a noul question for refund classification, a choice question over the team list, and a score question over an urgency rubric. One call, three calibrated answers, one bill for the input tokens.
The confidence score on every answer is the operational hook. A threshold of, say, 0.8 routes high-confidence decisions straight through, mid-band decisions to a cheaper re-check, and low-confidence cases to a human queue. Because the Gemini Decisions API reports its own calibration error at 0.0250, those thresholds mean what they say, which is the property that lets automation replace review without silent failures.
The three question types compose well. A yes and no check can gate a choice question, so a classification only runs when the document is in scope. Rubric scores can grade the outputs of earlier agent steps, which is how teams are starting to build evaluation into the pipeline rather than after it. And because questions cannot see each other, the same shared input can serve an unrelated audit checklist alongside the live routing decisions without cross-contamination.
The one thing the Gemini Decisions API does not do is reason across questions. Each question is scored alone, so a workflow that needs question B's answer to inform question C belongs in the agent's code, not in the request. That is by design, and it is the boundary between a decision model and an agent.
The ecosystem is meeting the model where it lands. Integrations are rolling out across OpenRouter, AI gateways, LangChain, Vercel AI SDK, LiteLLM, Pydantic AI, Pipecat, LiveKit and OpenCode, which means the routing and grading calls can slot into agent stacks that already abstract their model choices.
What the documentation warns about
The Decisions API guide contains warnings that are more useful than the benchmarks, and they deserve their own section.
A choice question always distributes probability across the options, even when none of them fits. Google suggests a catch-all option named other with a clear description, or a confidence threshold paired with a yes and no check before the choice. User-supplied text can argue for its own classification, which is a prompt-injection vector specific to decision APIs: the input being scored can lobby for the answer it wants. Google's guidance is to keep a human, or a second check, on high-stakes actions such as payouts, and to compare numbers, dates and durations in code rather than in the model.
The limits list is equally practical. The Gemini Decisions API is available only on the Gemini Developer API at v1beta for now, with Google Cloud support coming soon. Context caching and the Batch API are not supported. That means a team sending the same large PDF in separate requests pays full input tokens each time. Bundling questions into one request is the mitigation. There is no conversation history, so earlier turns must be passed as plain text. And media cannot sit inside questions, only in the shared input.
Each of those limits shapes the architecture around the API, and the bundling constraint in particular rewards the design Google is recommending: one shared input, many questions, one bill. Free-tier users should also note the trade. Free-tier inputs may be used to improve Google products, while paid-tier inputs are not. That makes prototyping with sensitive data on the free tier a decision to make deliberately.
How Google itself is using it
Four internal deployments are named in the announcement, and they illustrate the intended shape of the Gemini Decisions API better than any feature list.
Gemini Notebook uses the Gemini Decisions API as a real-time router, classifying each incoming query in milliseconds to pick the optimal model tier and thinking level, which Google says serves everyday queries with up to 40 percent lower latency. Stitch's rapid canvas experiment uses it to generate playable wireframes of a product flow in seconds and to apply voice or tap edits almost instantly. CC from Google Labs uses it to pick an emoji reaction from a palette of more than 200 options in a fraction of a second. And Google Search uses it as a safety layer, detecting adversarial behaviour and content on MCP tool calls within the latency envelope.
Those four use cases share a shape: a bounded decision inside a latency budget, where generating text would be slower, more expensive and less reliable than scoring options. That is the market this API is built for, and Google's own products are its first customers.
The market this enters
The Gemini Decisions API is not first of its kind, and the comparison table acknowledges the competition. OpenAI announced its Decisions API at DevDay on 29 September, running on a specialised GPT-6 Luna, with a public beta from 6 October and a limit of 400 questions per request. TypeSafe's Jev 1.14 and Microsoft-Decision-1 both list 0.042 dollars per million input tokens, less than half the Gemini price. Ecosystem support is rolling out across OpenRouter, LangChain, Vercel AI SDK, LiteLLM, Pydantic AI, Pipecat, LiveKit and OpenCode, with Gemini in Google Cloud to follow.
The market the Gemini Decisions API enters
The Gemini Decisions API is not first of its kind, and the comparison table acknowledges the competition. OpenAI announced its Decisions API at DevDay on 29 September, running on a specialised GPT-6 Luna, with a public beta from 6 October and a limit of 400 questions per request. TypeSafe's Jev 1.14 and Microsoft-Decision-1 both list 0.042 dollars per million input tokens, less than half the Gemini price. Ecosystem support is rolling out across OpenRouter, LangChain, Vercel AI SDK, LiteLLM, Pydantic AI, Pipecat, LiveKit and OpenCode, with Gemini in Google Cloud to follow.
The differentiators in this market are legible and few. Input modality coverage is one, where Gemini is alone in listing audio and video. Questions per request is another, where Gemini's 1,000 leads OpenAI's 400. Calibration is the third, where Google's numbers claim a halving of error. And price is the fourth, where Jev and Microsoft currently undercut everyone. Buyers should test against their own traffic, because Google's own guide instructs developers to set thresholds using labelled examples from their own data rather than trusting published scores.
There is also a licensing detail with real cost implications. The free tier's inputs may be used to improve Google products, while paid-tier inputs are not. Prototyping on the free tier with sensitive data is therefore not the same as prototyping on the paid tier.
Rate limits scale by usage tier: 200 requests per minute on the free tier, then 1,500, 5,000 and 15,000 as tiers advance. CellCog's arithmetic puts the free tier at roughly 100 classifications of 500 tokens each per minute, which is enough for evaluation and far short of production volume.
Questions readers are asking
What is the Gemini Decisions API for?
Closed-set decisions inside a latency budget: routing, tool selection, policy checks, content grading and safety filters. It is not for generating text, reasoning through multi-step problems or anything requiring prose, and Google's guide points those cases to its Interactions API instead.
How much does the Gemini Decisions API cost?
0.10 dollars per million input tokens, with zero output tokens billed because the model produces none. The shared input is billed once per request regardless of question count, there is a free tier for prototyping, and there are no transcription, OCR or thinking-token charges. Context caching and the Batch API are not supported.
How accurate is Gemini Decision 1?
In Google's own nine-benchmark table it ranks first on seven, including 92.2 percent on JevBench and the lowest calibration error at 0.0250, about half of the nearest competitor's. Jev 1.14 leads on Mind2Web Multimodal and When2Call and is cheaper across the shared suite. All figures are Google's own, and no independent evaluation exists yet.
Closed-set decisions inside a latency budget: routing, tool selection, policy checks, content grading and safety filters. It is not for generating text, reasoning through multi-step problems or anything requiring prose, and Google's guide points those cases to its Interactions API instead.
How does the Gemini Decisions API handle questions that overlap?
It does not need to. Each question is scored independently against the shared input, so the API returns the same answer for a question whether it runs alone or alongside 999 others. Workflows that need sequential reasoning stay in the agent's code.
What is the Gemini Decisions API's biggest limitation?
The absence of context caching. A team checking the same large document across many requests pays full input tokens every time, and the same document with the same ten questions bundled into one request costs a fraction of that. Design around the shared input and the limitation mostly disappears.
Can the Gemini Decisions API make decisions about audio and video?
Yes, and it is currently the only decision model of the four whose documentation lists audio and video input. A request can combine modalities in one shared input, such as a call recording with account metadata, and tune image and video resolution to control token cost.
The bottom line
The Gemini Decisions API is Google's entry into a product category that did not exist in the consumer imagination six months ago and now has four vendors: models that answer structured questions with calibrated probabilities instead of text. Gemini Decision 1's claim to leadership rests on calibration, modality coverage and question count, and its pricing sits at a premium to Jev while matching OpenAI.
The design is a bet on where agent infrastructure is going. The bet holds that the majority of tokens in agentic systems will soon be spent on small bounded decisions rather than on generating prose. It also holds that a model built for scoring will beat a generative model doing the same job in latency, cost and reliability.
Google's own products are already running on that bet. Gemini Notebook routes queries, and Search filters MCP tool calls, inside its latency envelope. The verification burden, as with all self-reported benchmarks, now sits with the independent evaluators, and the first one to publish will have a useful franchise. Until then, the Gemini Decisions API is best understood as a strong opening claim in a category that is being defined in public, one launch at a time.