Gemini Decisions API for Search Engineers: Wider Forms, Graded Judgments, and Media Solr Couldn’t Read

• Mandar Shinde


• 13 Nov 2026

Six weeks ago I wrote about Cloudflare’s Clef and argued that a decision model, a model that fills in a typed form with probabilities instead of writing text, changes a Solr index more than it changes a Solr query. This week Google shipped its own: the Gemini Decisions API, running a model called Gemini Decision 1 (gemini-decision-1). That makes three vendors in two months (Typesafe’s Jev, Cloudflare’s Clef, now Google), and the question types are the same in all three: noul, choice and score. When three teams converge on the same three words, the format is turning into a standard.

I won’t repeat the basics here; the Clef post covers what a decision model is, why it skips the token loop, and how to gate a query-time decision by its confidence. This post is about the four numbers in Google’s announcement that are new, because each one moves a different part of a search stack:

• Up to 1,000 questions per request, against one shared input that is billed once. Asking a question is now almost free, so the form can be as wide as you like.
• Multimodal input up to 256K tokens: text, images, audio, video and PDFs, with no separate transcription or OCR charge.
• Choices of 2 to 255 options, and an ordered score that returns a continuous weighted score as well as a probability for each level.
• $0.10 per million input tokens and $0 for output, with 150–250 ms end to end that stays nearly flat from 1 to 100 questions.

Read as a search engineer, those four numbers point at three jobs I didn’t propose for Clef: reranking a result list in one call, generating graded relevance judgments for learning to rank, and indexing media that Solr could only describe by its filename. There’s also a fourth that Google is already running in production, and it matters more every month: guarding a search engine that agents call as a tool.

The shape of the call

The request has three parts: a model name, an input list made of the same Content blocks the Gemini Interactions API uses, and a questions map in which each named question has a type, an instruction and, for choice and score, its criteria. Here is the catalog example from the Clef post, rewritten in that shape. Treat it as a sketch: the structure follows Google’s announcement, but check the exact keys against the Decisions API docs before you copy it.

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

resp = client.decisions.create(
    model="gemini-decision-1",
    input=[
        {"type": "image", "uri": photo_uri, "mime_type": "image/jpeg"},
        {"type": "text",  "text": listing_text},
    ],
    questions={
        "hazmat": {"type": "noul",
                   "instructions": "Is this a hazardous-material listing?"},
        "dept":   {"type": "choice",
                   "instructions": "Which department does it belong to?",
                   "criteria": {"footwear":  "Shoes, boots, sandals, insoles",
                                "apparel":   "Clothing and outerwear",
                                "equipment": "Packs, poles, tents, tools"}},
        "condition": {"type": "score",
                      "instructions": "Item condition, best first.",
                      "criteria": ["New, sealed",
                                   "Open box, unused",
                                   "Used, good",
                                   "Damaged"]},
    },
)
# every answer carries a 0-1 confidence; choice returns the winner plus a probability
# per option; score returns per-level probabilities and a continuous weighted score

Under the hood, Google says the model scores candidate options in a single forward pass rather than generating text, which is the same idea as Clef. Unlike Cloudflare, Google doesn’t describe the scoring head, the training losses or the backbone, so this post treats the model as a black box. Everything below depends only on the published interface and prices.

One input, a thousand questions: the marginal question is nearly free

The detail that changes the most is in the pricing paragraph. The shared input is billed once per request, however many questions you ask, and each question adds only its own instruction and criteria tokens. Output is free. So the cost of a request is roughly document + Σ(question text), and the document usually dominates.

In the Clef post I recommended starting with three fields: one boolean, one choice and one score. With this pricing that advice is too timid. If the document costs the same whether you ask three questions or forty, then the cheapest thing to do is to write every facet question you have ever wanted into one form and run it once per document. The form becomes a schema artefact, versioned next to managed-schema, not a prompt someone tweaks.

Here is the arithmetic for a mid-sized catalog. The prices are Google’s. The token counts are mine, and the image token count in particular depends on the resolution you choose, which Google says you can tune to trade visual detail against cost:

About $720 to tag two million products against forty typed fields, image included, with a probability on every answer. A full re-tag after a schema change costs the same again. That is cheap enough that the deciding question stops being “can we afford to enrich?” and becomes “do we trust the answers enough to facet on them?”, which is the calibration question from the Clef post.

A reranker that is one request wide

Here’s the idea I didn’t have for Clef. The shared input doesn’t have to be one document. It can be the user’s query plus the top N snippets Solr just returned, with one score question per snippet: “How well does snippet C satisfy this query?” on a 0–3 rubric. The context is small (eight snippets of 300 tokens is about 3K tokens, well inside the 16K range where Google says latency stays flat from 1 to 100 questions), and the output is a weighted relevance score for every candidate. It amounts to a listwise reranker, and it takes one HTTP call.

I’d still be careful about putting this on the live query path, for three reasons. At 150–250 ms end to end it uses most of an interactive budget on its own, so you either run it as a second stage on queries that justify it (long, ambiguous, zero-click-history) or you accept a slower page. Second, it sees snippets, not documents, so it can only be as good as your highlighter. Third, putting eight candidates into one input invites position bias: models of every kind tend to favour whatever comes first. Shuffle the snippet order and check whether the scores move before you trust them.

Where it pays off first: graded judgments for learning to rank

I think the same rerank call is more valuable offline. Every Solr LTR project hits the same wall: you need a judgment list (query, document, graded relevance) to train a model, and you never have enough of them. Clicks are biased, human raters are slow and expensive, and asking a generative LLM to grade thousands of pairs gives you a pile of text to parse and confidence numbers that mean nothing.

A 0–3 score rubric is the TREC-style graded relevance scale. Run your top 2,000 queries against their top 20 results, one request per query with 20 score questions, and you get 40,000 graded pairs. Each pair comes with its full probability distribution, so you can drop the ones the model was unsure about. Roughly 2,000 requests × ~7K tokens is 14M tokens, which costs about a dollar and forty cents.

# judgments.tsv: qid, doc, grade (rounded weighted score), weight (= max level probability)
q0412   SKU-48812   3   0.91
q0412   SKU-11930   2   0.74
q0412   SKU-77105   0   0.96
q0412   SKU-20341   1   0.58   # below 0.6: route to a human rater, don't train on it yet

# and at index time, the per-document answers become plain LTR features
{ "name": "dept_conf",      "class": "org.apache.solr.ltr.feature.FieldValueFeature",
  "params": { "field": "dept_p" } },
{ "name": "condition_w",    "class": "org.apache.solr.ltr.feature.FieldValueFeature",
  "params": { "field": "condition_w" } },
{ "name": "photo_quality_w","class": "org.apache.solr.ltr.feature.FieldValueFeature",
  "params": { "field": "photo_quality_w" } }

Two things make this better than the version of it I could have built with Clef. The continuous weighted score stores naturally as a pfloat (condition_w above), where an argmax step index throws away the difference between “used, nearly open-box” and “used, nearly damaged”. And because the judgment generator and the index enricher are the same API, the LTR model learns from features and labels drawn from the same source. That is a strength and a trap at once: if the model has a blind spot, your ranker will learn it from both sides. Keep a few hundred human-graded pairs as a holdout that the decision model never touches, and report NDCG on that set, not on the synthetic one.

255 options, and taxonomies bigger than that

A choice question takes at most 255 options. That covers a department list or a mid-level category, but most retail taxonomies have a few thousand leaves. The obvious workaround is to walk the tree in two calls: department first, then the leaves under the winner. The 1,000-question limit allows a better one: ask every branch in the same request.

There is a cost catch. The document is billed once, but the criteria are not: every option’s description counts toward its own question’s tokens. Fourteen leaf questions averaging 200 options at ~10 tokens each come to about 28K tokens of criteria per document, roughly ten times the listing itself. At catalog scale, either trim the criteria to the label plus a few words, or go back to the two-call walk for the documents whose department probability is already above 0.95. Which is cheaper depends on your tree, so measure both.

Routing and guarding the query path

Two of Google’s own deployments describe the query side better than I could. Gemini Notebook uses the API as a real-time router, picking the model tier and thinking level for each query, and reports up to 40% lower latency on everyday queries. And Google Search uses it as a safety layer for MCP tools, detecting adversarial behaviour and content before a tool runs.

Both map directly onto a search stack in 2026. The router is the “keyword vs. hybrid vs. answer” decision every team that bolted RAG onto Solr now has to make for each query. The safety layer matters because your search engine is increasingly called by agents, not people. Once Solr sits behind an MCP tool such as search_catalog(q), the query string is written by a model that might have read a hostile web page a few seconds earlier. A query can now carry an injection.

A decision model is a layer, not a security boundary. The unsafe question catches the obvious injections cheaply, but the real defence is still the boring kind: the MCP tool’s Solr user can only read the collections it is meant to read, the request handler pins fl and drops qt, stream.* and every other parameter the agent has no business setting, and rows are capped. The guard reduces the noise reaching those controls; it doesn’t replace them.

Documents Solr could only index by their filename

Clef reads text and images. Gemini Decision 1 also reads audio, video and PDFs, up to 256K tokens, and Google says there are no separate transcription or OCR charges. For an enterprise index that is the bigger change, because most corporate content that search handles badly is exactly this: recorded calls, training videos, scanned contracts and spec sheets that Tika turns into a wall of text or nothing at all.

The trade-off is honest: you get answers to the questions you asked and nothing else. A transcript is searchable for questions nobody anticipated; a call_issue_s field is not. For audio and video I’d keep both, a cheap transcript for full-text recall and a decision form for the facets and filters, and treat the form as the part that makes the content browsable rather than merely findable.

Clef or Gemini Decision 1?

They share a request format, so switching between them is cheap, and they are good at different things. From the two launch posts:

My split, for what it’s worth: Clef-flash on the interactive query path, where 39 ms matters and the questions are short; Gemini Decision 1 for index-time enrichment and offline judgments, where wide forms, media inputs and a cheap per-question price matter more than the last 100 ms. Because both speak noul/choice/score, the form you write for one runs on the other, which also makes it easy to check one against the other on your own data.

Where this will disappoint you

What I’d do this quarter

1. Take the three-field form from the Clef post and widen it to every facet the schema has but merchants leave blank. Run it on 2,000 documents in the AI Studio free tier and plot calibration against existing labels.
2. Generate a judgment list for the top 2,000 queries with the one-request rerank, keep only pairs above 0.6 confidence, and train a first LTR model against a human-graded holdout.
3. Pick one media-heavy collection (call recordings, training videos, scanned PDFs) and add a decision form next to the transcript, not instead of it.
4. Put the router and the unsafe question in front of any MCP tool that reaches Solr, behind hard request-handler limits, with every decision logged.
5. Run the same form through Clef and Gemini on the same sample. Wherever they disagree, a person should look.

In the Clef post I said a decision model gives a search index the one thing it always wanted from machine learning: a typed value, in a field the schema already knows how to use, with a number that says how much to believe it. Google’s version keeps that promise and adds one: the next question is almost free. That turns enrichment from a project you scope carefully into something closer to a schema you simply write down.

What is established and what is my framing

This is a day-one read of an API released today, written from the announcement and not yet from a test against a real catalog. As with the Clef post, I’ve written the plan down before testing it so I can report honestly afterwards on what held up.