Google launches Gemini Decision 1: video-based decisions at $0.10 per million tokens

A support request arrives with a photo of a damaged product. The application needs to identify the problem, select a department, and determine whether human review is required. Generating several paragraphs of explanation is usually unnecessary. Google has released the Gemini Decisions API: the developer supplies the material and allowed answers, and the Gemini Decision 1 model returns scores that code can then act on.

The practical appeal is the ability to move repetitive checks into a separate API call. For example, requests could be routed first, with difficult cases then passed to a person or a model that drafts a customer response. For a team, this is an opportunity to examine how much time and money currently goes into generating text just to make a single operational decision.

What the application receives

According to Google's announcement, the API accepts text, images, audio, video, and PDFs. It supports three question types: yes/no, selection from predefined options, and ratings on a defined scale. Pricing is $0.10 per million input tokens; there is no charge for output tokens.

Imagine an apartment inspection service. A user uploads a video of a room with the comment: "Water appeared near the window after it rained." The team could formulate several independent questions: are there visible signs of a leak, which specialist should receive the request, and how urgently is an inspection needed? This is an example of a possible application, rather than a published product test result.

The quality of this workflow starts with the wording. Asking "Is everything OK here?" leaves too much room for interpretation. It is more useful to list observable signs and define categories: water on the floor, stains on the wall, damage to interior finishes. Assessing urgency also requires clear criteria; otherwise, it will be difficult to connect a number to an action.

Why 92% is not yet a guarantee

Simon Willison tested the API on a video featuring a robot. He asked whether a dragon or a robot appeared in the frame and whether the action took place in France or the United States. In the response he shared, the probability of a robot being present was about 92.3%, and that of a dragon about 5%. The model returned roughly 92.3% for the United States and 8.3% for France.

This experiment demonstrates the response format and the ability to process that particular clip. It does not establish the model's accuracy on arbitrary videos. Crucially, a score of 92% does not, by itself, mean that exactly 92 out of a hundred similar decisions will be correct. That relationship needs to be tested on labeled examples from your own task.

Geography introduces another pitfall. Confidently recognizing an object and identifying the country where footage was recorded are different tasks. A frame may contain enough evidence to identify a robot but insufficient information about the location. If an error affects money or a user's access to a service, it is useful to provide an "insufficient information" outcome and a route to human review.

How to assess its value before deployment

I would start with one operation the product already performs regularly: routing requests, checking a document for completeness, or selecting the next tool for an agent. An initial comparison requires real examples with known correct answers, including difficult cases: poor photos, contradictory comments, and several problems occurring at once.

Next, measure three things: the proportion of incorrect decisions, processing time, and the total cost per request. The price per million tokens helps compare rates, but the product pays for the material it processes. A long video and a short text request can have very different economics. Repeated calls and human review also belong in the calculation.

The automation threshold should be chosen based on the cost of an error. An incorrectly assigned tag is usually easy to fix. An incorrectly rejected claim, however, creates a conflict with the customer. The same model score may therefore justify an automated action in one workflow while requiring review in another.

The Gemini Decisions API is worth testing where the available actions are known in advance. You can start in observation mode: save the model's decisions alongside those made by staff, examine discrepancies, and only then enable automated processing. This will give the team an answer to the central question: does the new API help its particular product?