Gemini Decisions API: $0 Output, 1,000 Questions per Call

Google shipped the Gemini Decisions API yesterday, and it doesn't write a single word back.

The new model, gemini-decision-1, reads your input and scores a fixed set of answers in one pass. You pay $0.10 per million input tokens. Output is free.

That sounds like a pricing gimmick. It isn't.

It's Google's bet on a category that had a very loud week: Amazon published how it swapped Claude Sonnet 4.6 for a small decision model and cut a classification bill by 98%, and Hugging Face added a native decision pipeline to Transformers.

If your app asks an LLM to pick from a list, this is the week to rethink that call. By my math below, a million ticket labels could cost around $20 on the new API.

Key features: what the Gemini Decisions API actually does

A normal chat model generates text, token by token. You ask Is this ticket billing or bug? and pay for the reasoning, the formatting, and the occasional answer that's neither.

A decision model skips all of that. You give it the input and the allowed answers, and it returns its pick.

Google's post and API pricing docs spell out the shape:

Question types: yes/no, multiple choice with 2 to 255 options, and rubric-style grading.
Batching inside one call: up to 1,000 questions per request.
Inputs: text, images, audio, video, and PDF, up to 256K tokens.
Speed: 150 to 250 ms end to end, with 50 to 100 ms of that being model compute. Google says latency stays nearly flat from 1 to 100 questions.
Price: $0.10 per 1M input tokens, $0 output, with a free tier in AI Studio.

The quiet detail is billing. Shared input is charged once per request, not once per question. Put a 50-page contract in the request, ask 200 questions about it, and you pay for the contract once.

The decision-model week: Amazon and Hugging Face

Google isn't alone here, and the other two stories are what make this worth your attention.

Amazon's Strands Decider post (9 November) is the production proof. An internal team was using Sonnet 4.6 to sort tickets into 20 categories. They moved to Strands Decider, first a 2B model and then an E4B build based on Gemma 4.

Output dropped from 170 tokens per ticket to one. Cost per million tickets fell from about $22,200 to about $500, and average latency went from 4,215 ms to 897 ms.

Hugging Face's update (10 November) gives you the open path. Transformers now ships pipeline("decision") and AutoModelForDecision. You can serve these models behind a /v1/systemone endpoint with transformers serve or llama.cpp, and find them under the Hub's decision-model tag.

Put together, that's a hosted option, a self-hosted option, and a real-world receipt. All in one week.

What a million classifications costs now

Here's the math Google's post doesn't do for you. These are my estimates from the published rates, not vendor numbers, and not a hands-on accuracy test.

Say each ticket plus your instructions comes to about 1,000 input tokens. A million tickets is a billion input tokens. At $0.10 per million, that's roughly $100, with nothing added for output.

Now use the shared-input rule. Put a 2,000-token instruction block and category list in once, then pack 1,000 short tickets of around 200 tokens each into the same request as separate questions (test that your setup supports this). Each request is about 202,000 tokens, and a thousand of them cover a million tickets for about $20.

That's also why the $0 output headline is the less interesting half. If your prompt already returns a bare label, free output saves little. Amazon's old setup spent 170 output tokens per ticket, so chatty prompts are a different story.

For most teams, the shared-input rule is where the money moves, but only if you restructure calls to pack questions together. At these sizes, the 1,000-question cap bites before the 256K input ceiling does.

Compare that with Amazon's numbers: about $22,200 per million on Sonnet 4.6 and about $500 on its own decision model. Those figures include Amazon's own setup and aren't a clean apples-to-apples test. Still, the gap is wide enough to make you look twice at every place your code says respond with only one of the following labels.

Real-world use cases

The fit is anything where the answer space is fixed and you already throw away the model's prose.

Ticket and email routing. The Amazon case. Twenty buckets, one label, done.
Content moderation. Yes/no per policy rule, many rules per item, one request.
LLM-as-judge evals. Rubric questions against a generated answer. Running 1,000 grading questions in one call changes what a nightly eval run costs.
Document checks. Upload a PDF once, ask Does it contain a termination clause? and a hundred similar questions.
Agent guardrails. A fast should this tool call run? gate in front of a slow, expensive model.

Hard limitations and flaws

Don't rip out your classifier yet. There are real gaps.

No accuracy numbers. Google claims the model is nearly 5x cheaper than Gemini 3.5 Flash-Lite with the Interactions API across a shared benchmark suite. It doesn't publish scores, and Amazon's post has no accuracy figures either. Cheaper is meaningless if it picks the wrong label more often, so measure it on your own labeled data.

Latency is only shown up to 16K tokens. The model accepts 256K, but the 150 to 250 ms figures cover contexts up to 16K. Long PDFs or video are unmeasured, so time them yourself.

No caching and no Batch API. This model has neither. The shared-input billing helps inside one request, not across requests.

Launch status is fuzzy. The changelog just says Released. Google doesn't call it preview or GA, so don't assume an SLA or a stable model string for production.

It can't explain itself. You get a pick, not a rationale. If a regulator or a support lead asks why a ticket was routed somewhere, you'll need a separate call to a generative model.

Open-source licensing has gaps. The Strands Decider code repo is Apache-2.0, but the license for the model weights isn't stated. The Hugging Face decision pipeline can serve these models, but TRL training support is still an open pull request (#8040), so fine-tuning your own isn't smooth yet.

Small context on the open side. Amazon's Strands Decider setup ran with a 4,096-token window. Don't expect it to swallow long documents the way the hosted API does.

Verdict: your developer action plan

This is the most practical AI pricing change of the week. Most teams are paying chat-model rates for jobs that only need a single label, and the Gemini Decisions API puts a hard number on how much that habit costs.

Here's what I'd do this week:

Grep your codebase for prompts that end in respond with only or answer yes or no. Those are your candidates.
Build a labeled set of 500 to 1,000 real examples per task before you test anything.
Run gemini-decision-1 on the AI Studio free tier against that set, next to your current model. Compare accuracy first, then cost.
Pack questions per request. If many questions share a document or instructions, batch them in one call. That's where the billing rule pays off.
Keep a self-hosted fallback in view. If data can't leave your network, Hugging Face's pipeline("decision") and llama.cpp support are the route. Check each model's weights license first.

Use it for the boring, high-volume yes/no work. Keep generative models for anything that needs a reason attached.

Gemini Decisions API: $0 Output, 1,000 Questions per Call