Gemini Decisions API Turns Agent Guardrails Into One Cheap Checklist Call

Google and OpenAI now both sell models that only answer yes, no, or pick-one. That changes how you should build the checks around your agents.

Most AI agents in production are guarded by a second AI that was never built for the job.

Before an agent sends an email, runs a shell command or issues a refund, a lot of teams ask a chat model a question like "does this action look safe?" and then try to parse a yes or no out of a paragraph. It works, sort of. It is slow, you pay for every word of the answer, and the "yes" comes with no number you can set a threshold on. So people check less often than they should.

On November 11, Google launched the Gemini Decisions API, and it is built for exactly this. It does not write text at all. You give it one input and a list of closed questions, and it hands back an answer and a confidence score for each. OpenAI's Decisions API, which OpenAI now lists as generally available (out of beta and supported for production), works the same way.

Two vendors with the same product shape means this is a category now, not an experiment. And it makes one design choice obvious: stop asking your guard one question at a time. Ask it the whole checklist at once.

What a decision endpoint is, in plain terms

A normal model call is an essay question. A decision call is a multiple-choice test.

With Gemini, the model is gemini-decision-1. One request carries a shared input (text, images, audio, video or PDFs, up to 256K tokens; a token is a word fragment, about three-quarters of an English word, so that is a few hundred pages of text) plus between 1 and 1,000 questions (docs). Each question is one of three types:

• noul for yes/no. You get back a probability that the answer is yes.
• choice for picking one of 2 to 255 options. You get the winner plus a probability for every option.
• score for grading on an ordered rubric, like "clean / minor issue / serious issue." You get a weighted score and a probability for each level.

Every answer also carries a confidence from 0 to 1, which Google describes as the hook for routing "ambiguous cases to a fallback or human reviewer."

The pricing is the other half of the story. Google lists $0.10 per million input tokens and $0 for output, and bills the shared input "once per request no matter how many questions you evaluate" (Google blog). Each extra question adds only its own short instructions. Google quotes 150 to 250 ms end to end, staying nearly flat from 1 to 100 questions, measured on inputs up to 16K tokens.

Those speed numbers are Google's own, from its own tests. Treat them as the launch claim until you have measured your own traffic.

The shift: from one judge per question to one checklist per step

Here is why the billing detail matters more than the headline price.

Say your agent is about to act, and the context it is acting on (the conversation, the tool call, the retrieved documents) is 4,000 tokens. You want to check ten things before you let it go: is this action in scope, does it touch customer data, does it send anything outside the company, does the user's request actually ask for it, and so on.

Ask ten separate questions and you send those 4,000 tokens ten times. Put all ten in one decision request and you send them once, plus ten short questions. At Google's listed price, one request with about 4,500 input tokens comes to roughly $0.00045, by my arithmetic. Ten thousand guarded agent steps a day would cost about $4.50.

That changes the economics of guardrails. The expensive part was always reading the context, not answering the question. Once reading is paid for once, there is no reason to keep your checks vague. Split them up. "Is this safe?" becomes ten narrow questions, each one specific enough that you can tell when it is wrong.

Putting it into practice

1. Write the checklist before you write any code. List the actions your agent can take that would hurt if they went wrong. For each, write questions a careful reviewer would ask, in plain language, one idea per question. Ten is a good start. Keep them narrow: "Does the command delete or overwrite files outside the project folder?" beats "Is this command dangerous?"

For an agent that can run shell commands and send email, a first checklist might look like this:

• Does the command delete or overwrite files outside the project folder?
• Does the command install software or change system settings?
• Does the action send user data to a domain outside the company?
• Does the email go to anyone who was not in the original conversation?
• Did the user explicitly ask for this action in the last few messages?
• Does the action spend money or change a billing setting?
• Does the action read a file that looks like a credential or key?
• Which tool is the agent calling? (a choice over your allowed tools, plus "none of these")
• How risky is this action if it is wrong? (a score from harmless to irreversible)

Notice that none of these ask the model to be wise. Each one asks it to notice one specific thing. That is the kind of question a small, fast model answers well, and the kind of answer you can check by hand when it gets one wrong.

2. Send it as one Gemini request. Google's docs require the google-genai SDK 3.2 or later and the v1beta API version. Here is the shape, adapted from Google's own example:

from google import genai

client = genai.Client(http_options={"api_version": "v1beta"})

result = client.decisions.create(
    model="gemini-decision-1",
    input=agent_step_context,  # the transcript, tool call and arguments
    questions={
        "deletes_outside_project": {
            "type": "noul",
            "instructions": "Does the command delete or overwrite files outside the project folder?",
        },
        "sends_data_externally": {
            "type": "noul",
            "instructions": "Does this action send user data to a domain outside the company?",
        },
        "risk_level": {
            "type": "score",
            "instructions": "How risky is this action if it is wrong?",
            "criteria": ["Harmless and reversible.", "Annoying but reversible.", "Hard or impossible to undo."],
        },
    },
)

answer = result.answers["deletes_outside_project"]
print(answer.noul, answer.confidence)

The REST version is a POST to https://generativelanguage.googleapis.com/v1beta/decisions with your key in the x-goog-api-key header (docs).

3. Keep your checklist vendor-neutral. OpenAI's version uses different names for the same ideas. Its yes/no type is called predicate and returns a probability; its questions go in an array with a name field instead of a map keyed by name; it runs on gpt-6-luna at POST /v1/decisions (OpenAI docs). Store your checklist in your own simple format (a key, a type, the question text, any options) and write a ten-line adapter (a small function that turns your format into each vendor's request) per provider. Then a price change, an outage or a better model on the other side becomes a config change.

Watch the limits when you translate. Google allows up to 1,000 questions per request; OpenAI's docs say up to 400. Google's question instructions are text only.

4. Set thresholds from your own data, not from intuition. Google's docs give three rules worth copying (docs):

• Yes/no probabilities always fall between 0.01 and 0.99, so a check that requires "above 0.99" will never fire.
• A choice question always spreads probability across the options you gave it, even when none fits. Add a catch-all option like "none of these," or ask a yes/no scope question first.
• Set thresholds "using labeled examples from your own traffic," weighing the cost of a false alarm against a miss. The docs' own example sends anything under 0.7 confidence to human review.

In practice: run the checklist in log-only mode (it records answers but blocks nothing) for a week, have a person label a few hundred real agent steps, and pick thresholds from that. A guard that blocks on a number you made up is a guard you will turn off in a month.

5. Decide what happens on "unsure." Three outcomes, not two. Allow, block, or escalate to a person. The confidence score exists to fill the third bucket. A starting rule might read: block if any hard-stop question comes back yes with confidence of 0.7 or more, escalate if any answer's confidence is below 0.7, otherwise allow. Then tune those numbers from your labeled week.

What to expect. Fast answers that are easy to log and graph. A few questions that fire constantly because they were worded loosely; rewrite those. And a handful of real catches that a single "is this safe?" prompt would have waved through.

Honest limitations

• It only answers what you ask. A decision model cannot notice a risk you did not write a question for. Your checklist is the ceiling on what your guard can catch.
• Vendor numbers only. Google's "nearly 5x cheaper" figure is against Gemini 3.5 Flash-Lite on Google's own benchmark suite. Measure latency and accuracy on your traffic.
• The free tier is not private. Google's pricing page says free-tier content may be used to improve Google's products, while paid-tier content is not. Agent transcripts often hold customer data, so prototype with fake data or on a paid key.
• Gemini API only, for now. The launch post says support in Google Cloud is "coming soon," so today it runs through the Gemini API and Google AI Studio.
• No caching or batch discounts. Google's docs say the endpoint does not support context caching (discounted re-reads of repeated input), the Batch API (cheaper delayed jobs), or the Flex and Priority service tiers.
• Safety blocks are errors. If the input trips Google's safety filters, you get an HTTP 400 with a code such as safety or prohibited_content, not an answer. Decide in advance whether a blocked check means block or escalate.
• Status is unstated. Google's pages do not call it preview or generally available. OpenAI's version is GA.
• A guard from the same vendor as your agent is not independent. If Gemini drives your agent and Gemini guards it, they may share blind spots. Running the guard on the other vendor's endpoint is cheap insurance, and the neutral checklist from step 3 makes it a one-line switch.

The bigger point

For two years, "add a guardrail" has meant adding another expensive, chatty model call and hoping its paragraph contained a clear "no." Decision endpoints make the guard boring: a list of questions, a list of numbers, thresholds you tuned on your own data.

Boring is what you want here. Write the ten questions your most careful reviewer would ask before letting your agent act. Send them in one call. Look at the numbers for a week. You will learn more about where your agent goes wrong from that log than from any benchmark either vendor publishes.

Sources: Google blog, "Gemini Decisions API" (November 11, 2026) · Gemini Decisions API docs · OpenAI Decisions API guide · Gemini API pricing (checked November 11, 2026)