Gemini Decision 1: 1,000 questions per call, 150 ms, $0.10 per million input tokens and no output bill

Google launched the Gemini Decisions API on November 11. The model behind it, gemini-decision-1, does not write anything. It takes a shared input of up to 256,000 tokens, in text, images, audio, video or PDF, and up to 1,000 independent questions about that input, then scores each question's options in a single forward pass and returns probabilities and confidence scores. Questions can be yes/no checks, multiple choice with between 2 and 255 options, or rubric scores.

The numbers

Google quotes 150 to 250 milliseconds end to end, with median model compute of 50 to 100 milliseconds, and says performance barely changes between one and 100 questions per request. Pricing is $0.10 per million input tokens with no output charge; shared input is billed once per request, while each question adds its own instruction and criteria tokens. Google says the model is nearly five times cheaper than Gemini 3.5 Flash-Lite across its shared benchmark suite and claims the lowest calibration error against competing systems on agent routing, reasoning, ranking and multimodal tasks. It is live in Google AI Studio with a free tier, and integrations are rolling out through OpenRouter, LangChain, Vercel, LiteLLM and Pydantic AI. Context caching and the Batch API are not supported. All figures are Google's own.

Why a model that cannot talk

Most of the calls inside a production agent are not generation. They are decisions: which tool to call, which model tier to route to, whether a response violates a policy, which of five retrieved chunks matters, what score a draft deserves. Teams have been making those calls by asking a small generative model to answer in one word, then parsing the word, then retrying when the model adds a sentence. A scoring head removes the parsing, returns a probability instead of a token, and runs in a fraction of the time because there is no decode loop. Google says it uses the model to route Gemini Notebook queries between tiers and reasoning levels, cutting latency for everyday queries by up to 40%, to pick emoji reactions from more than 200 options in its CC assistant, and as a safety layer in Search that flags adversarial behaviour involving MCP tools. That last one is the most interesting: a cheap judge that cannot generate text is a sound thing to put in front of agents that can.

The competition

OpenAI launched its own Decisions API in October on GPT-6 Luna, with up to 400 questions per request, the same $0.10 per million starting price and a claim of up to ten times the speed of its Responses API. TypeSafe's Jev sells a similar product. Google's edge on paper is question count, 256K multimodal context and the free tier; OpenAI's is a head start of a month and the Luna model's wider availability. Both vendors chose the same price, which tells you the market has already settled on what a decision should cost.

The counter-argument

A decision model is only as good as the options you give it, and it cannot tell you when none of them fit. Open-ended problems, anything that needs an explanation a human will read, and tasks where the error mode is 'the question was wrong' still need generation. The calibration claim is Google's, measured on Google's suite; routing decisions that look confident but are not are worse than slow ones. And lock-in cuts the other way: a pipeline built around 1,000 questions per call does not port cleanly to a 400-question API.

What to build with it first

Start with the three calls in your agent loop that already return one word: model routing, tool selection and the pass/fail policy check before a response goes out. Log the existing Flash answer and the Decision 1 probability side by side for a week and measure agreement, latency and cost. Then try batch grading of evals, where the no-output-charge pricing matters most. Keep a generative fallback for anything the model scores below a threshold you set from your own data, not Google's. And register the model in your pricing tracker as a separate line, because your bill is about to split into generation, retrieval and decisions.