Google's Decisions API Answers 1,000 Questions and Bills No Output

The cheapest part of Gemini Decision 1 is the part that does not exist. Google put the model behind a new Gemini Decisions API on 11 November 2026, and the pricing page lists output at zero — not cheap, not discounted, absent, because POST /v1beta/decisions has no prose to generate. You send one block of shared input plus up to 1,000 typed questions; you get back one calibrated answer per question and nothing else. The leaderboard number got the attention on launch day. The billing line is the one that changes what you build, and it is worth doing the arithmetic before you copy anyone's architecture diagram.

Every other model decision you have made in the last two years was shaped by two costs pulling in opposite directions: input you want to send once, and output you want to keep short. This endpoint removes the second tension entirely and replaces it with a different one, internal to a single request. Once you see where the new tension sits, the rest of the API's design — the question ceiling, the shared context, the absence of caching — stops looking arbitrary.

What zero output tokens does to the arithmetic

Take a realistic document-scoring job: a 40,000-token policy or contract, and 1,000 questions you want answered about it. One request to the Decisions API bills 40,000 input tokens once, at $0.10 per million, which is four tenths of a cent — $0.004 for all one thousand answers.

Now ask the same 1,000 questions the way you would have asked them a week earlier, as 1,000 separate generate-content calls. Each call has to carry the document, because a chat endpoint has no way to hold it across calls. That is 40 million input tokens, or $4.00 at the same per-token rate, and the gap widens once you add the output tokens each of those calls would have produced. The envelope is not a convenience feature. It is a thousand-fold cost difference on the same work, and it comes from a single design choice: questions are evaluated against one shared context in one pass, not one per round trip.

That arithmetic also tells you the shape of the workload this model wants. Many questions about one large object, answered together. If your questions are about 1,000 different objects, you get 1,000 requests and none of the saving.

The envelope: 262,144 tokens, shared, and capped at 1,000 questions

The context window covers the shared input and every question in the request together, at 262,144 tokens. Inside that budget you can pose between 1 and 1,000 questions. The number that matters is the upper bound: 1,000 questions in one call is not classifier territory, it is a rules engine's worth of judgement compressed into one pass. A support ticket can be checked against forty policy clauses; a loan file can be tested against every underwriting rule at once.

Two properties of the request shape are easy to miss and expensive to discover later. Questions are evaluated independently — one question's answer does not condition the next, so you cannot chain reasoning by asking a follow-up that depends on an earlier reply. And the model never sees your question keys, only the instruction text you write, so the keys are for your own bookkeeping and the instructions have to stand on their own.

Three question shapes, and the trap inside each

• Yes/no — the noul type returns a probability between 0.01 and 0.99 plus a confidence score. The bound is clamped at both ends, so a routing threshold set at 0.995 will never fire, no matter how certain the model is. Pick thresholds inside the range the API can actually return.

• Choice — two to 255 named options, returning the winning option, a probability for every option summing to one, and a confidence. Before scoring, the API sorts your option keys alphabetically in UTF-8 byte order, which means JSON key order is irrelevant and an exact tie resolves toward whichever key sorts first. Google's guidance follows from that: name your catch-all option other, because a name like none_of_the_above sorts ahead of most real categories and will win ties it should lose.

• Score — two to 255 ordered rubric levels, with two to ten recommended. The return value is a probability-weighted expected level, and because the expected value averages array indices rather than the labels, a scale written as 1/10/100/1000 produces a number that is not on your scale. Keep the rubric evenly spaced in index terms, or convert the expected index back to a label yourself.

What the documentation lists as unavailable

The gaps are all in the same direction: this is a single-shot endpoint with nothing wrapped around it. There is no context caching, so a policy document reused across requests is billed again in full each time. There is no Batch API, which rules out a half-price overnight sweep of last year's tickets. There is no Flex or Priority tier. The model is on the Gemini Developer API only, at version v1beta, with no Vertex AI listing in the documentation Google shipped — a detail that matters to anyone whose procurement runs through a cloud contract rather than an API key.

Media is unusually broad and unusually bounded at the same time. Text, image, video, audio and PDF all go in one request. The limits are 100 MB of inline base64, 50 MB for a PDF, and 15 MB per external HTTPS URL. YouTube links are not accepted and neither are gs:// URIs; you pass uploaded file references, signed URLs, or bytes.

Rate limits start at 200 requests and 50,000 tokens per minute on the free tier, step to 1,500 and one million at Tier 1, and reach 5,000 requests and four million tokens per minute at Tier 2 with no daily request cap. The free tier is free of charge but documented as used to improve Google's products, which disqualifies it for anything under a confidentiality clause.

The score, briefly

On the Artificial Analysis Decision Index v2.1 the model lands at 66 — 65.98 unrounded — ninth of the eighteen decision models the board ranks. It is first outright on two of the six components, AA-Omniscience-Decision v1.1 and HLE-MultiChoice v1.1, both weighted 15%, and mid-table on AA-Paperclip at 30% weight, which is the component that decides most of the composite. Measured cost is $345 per million tasks and latency 211 milliseconds per task against a field median of 209. Google published no benchmark table of its own with the release; every performance figure here is the independent board's, on its own harness. The arithmetic behind the 66 is a separate question and a separate article.

Fitting it into a pipeline you already route

OrcaRouter does not carry gemini-decision-1, and the reason is structural rather than commercial: a probabilities-only endpoint is not a chat-completions target, so there is nothing for a router in our shape to put behind one key. The half of the pipeline we are for is the other half. A decision service is almost always two calls — something drafts the candidate answer, the rubric, or the shortlist, and something scores it — and the drafting call is where model choice is actually contested.

That call can run across more than 200 models on one endpoint, at provider list price passed through with 0% markup, so when a vendor cuts a price the new number is live on our side the same day rather than at the next billing cycle. Model fusion earns its place here in a way it does not in a chat UI: two drafters produce competing candidate answers, and the Decisions API scores both against the same rubric in a single request, which turns an A/B test into a per-record decision.

Failover is worth being precise about too. Automatic failover protects the generative call — if the provider behind your drafting model returns errors, the request reroutes and the pipeline keeps moving. It cannot protect the scoring call, because there is exactly one place to send that. If the decisions endpoint is down, your pipeline is down, and no amount of routing changes it. Design the drafting half to be resilient and accept that the scoring half is a dependency.

Bottom line

The Decisions API is worth adopting for one reason and it is not the leaderboard position: it collapses a thousand round trips into one billed input, and that changes which questions are cheap to ask. Build on it if your problems look like many judgements over one large object — a contract, a claim file, an hour of video — and expect to keep your prompts inside one request, because everything that makes it cheap happens between the first and last token of a single call. If your problems look like one question over a thousand small objects, the envelope buys you nothing and the input rate is simply three times what a cheaper decision model charges.