$0.10 per Million Tokens: Decisions API Has a Different Catch

A cheap judgment still needs a decision policy

Google introduced the Gemini Decisions API on November 11, powered by Gemini Decision 1. It evaluates bounded questions across text, images, audio, video and PDFs, returning probabilities rather than generated prose. The launch price is $0.10 per million input tokens, with no output-token charge. Google advertises 150–250 milliseconds of end-to-end latency and support for up to 1,000 independent questions against shared input. Those are vendor claims, not measurements from an EgoistAI test. Google’s announcement

For builders, the interesting change is where this fits in an application. A support system might need to decide which queue receives a complaint before anyone writes a reply. A document workflow might need to flag an incomplete submission before generating a summary. In both cases, a paragraph explaining the choice can be extra work when the next consumer is an ordinary branch in code.

The catch is that cheaper judgments make it tempting to automate more of them. The API can supply a probability; the application owner still has to decide what that probability authorizes. Sending a ticket to the wrong department and approving an unwarranted refund are different mistakes. Putting both behind the same confidence threshold would be a product decision disguised as a technical default.

The important constraint is the answer menu

The documentation describes three question types: yes/no checks, selection from fixed choices and scoring against an ordered rubric. Questions are evaluated independently against shared input. Choice responses distribute probability across the supplied options even when none fits, while rubric responses return a probability-weighted score. The docs advise narrow questions and combining results in application code. Decisions API documentation

That makes the option list part of the specification. Consider an illustrative customer-service router with billing, delivery and technical-support destinations. If a message reports account impersonation, the router needs an appropriate escape route. Otherwise, a tidy response can conceal an untidy classification: the winning destination may simply be the least unsuitable choice.

A useful design exercise is to write the cases each destination must refuse before writing the cases it accepts. Billing can handle an invoice dispute, but an invoice attached to a suspected account takeover may require a different process. This forces the team to resolve overlapping responsibilities instead of expecting a probability distribution to settle an organizational argument.

Independent questions also call for explicit composition. A proposed workflow could check whether a submission is readable, whether it falls within the service’s scope and which destination fits it. The application can require the first checks to pass before acting on the destination. That is a proposed implementation pattern, not evidence that the API has validated the workflow’s business rules.

Calibration is a claim about repeated outcomes

Calibration means that estimated probabilities correspond to observed correctness over comparable predictions. The research paper On Calibration of Modern Neural Networks, by Chuan Guo and colleagues, explains why confidence and correctness need separate attention: a classifier can produce convincing probabilities without those probabilities reliably representing its success rate. That paper supplies background for interpreting this launch, not an independent evaluation of Gemini Decision 1. The calibration paper

For an illustrative calibration check, collect predictions assigned similar confidence and compare them with adjudicated outcomes. A system calling cases highly certain earns that description through repeated results, not through the appearance of a precise decimal. A single successful demonstration cannot establish that relationship, and a single failure does not measure it either.

The practical question is which population the confidence describes. A ticket router could behave differently on short English complaints, mixed-language messages and screenshots containing the only useful evidence. An aggregate result could hide the weak segment. Builders evaluating this API can separate those groups and examine both mistakes and the amount of work diverted to review.

Google’s documentation recommends setting thresholds with labeled examples from the application’s own traffic and weighing false positives against false negatives. That is the right place to start, but choosing a threshold also requires an operational answer: who receives an uncertain case, what information reaches them and what happens while the case waits? Threshold guidance

Read the price beside the workload

Google says shared input is billed once per request; each question contributes its own instructions and criteria. Its launch latency discussion reports nearly flat performance from one to 100 questions, with the cited latency measurements covering contexts up to 16K tokens. The supported input limit is larger, at 256K tokens. Capacity and measured performance are different claims. Launch pricing and performance details

The sensible comparison is a representative application run. Record the material sent, the questions asked, the returned usage and the elapsed time seen by the caller. Include the path taken when a request fails or a decision needs review. A low inference bill can coexist with an expensive workflow if people spend time undoing avoidable routing mistakes.

Batching deserves a workload-specific test too. Questions about the same photograph may naturally belong together. Unrelated tasks that happen to arrive together may have different deadlines or retry requirements. Design the request around the evidence and the action it supports, then measure whether grouping questions improves the complete workflow.

There is also a maintenance cost that token pricing cannot capture. Someone must update the answer menu when a department changes responsibility, revise the rubric when policy changes and preserve enough information to investigate disputed decisions. Treat those definitions as versioned application behavior. A quiet edit to a criterion can matter as much as a code change.

Multimodal evidence needs a missing-evidence path

For a concrete pilot, imagine evaluating a damaged-delivery report containing a customer message and photographs. This is an editorial example, not a reported deployment. The useful questions would distinguish visible packaging damage from evidence of damage to the item itself. Those findings could inform a review queue without automatically determining the customer’s entitlement.

The distinction matters because evidence can be absent, contradictory or irrelevant. A photograph of a crushed box does not necessarily establish a broken product. An intact box does not settle whether something inside has failed. The application needs a route for insufficient evidence rather than forcing every submission into a substantive conclusion.

Build an evaluation set around those disagreements. Include clear cases, ambiguous cases and examples where the decisive detail is unavailable. Have reviewers record what they can establish from the supplied material separately from what they know through other channels. Otherwise, the evaluation may punish the system for lacking evidence it never received—or reward it for a lucky guess.

Keep the permitted action narrow during the pilot. Sorting reports for inspection gives the team a chance to observe errors before tying the same judgments to refunds, account restrictions or other consequential actions. Expanding authority can then depend on evidence about that particular task, with an owner responsible for the decision.

The first deployment needs a way to disagree

Start with a bounded existing decision whose outcomes can be checked. Run the proposed API workflow beside the current process and preserve disagreements for review. Decide how the comparison will be judged before inspecting the results: correct destination, review burden and time to resolution answer different questions. Pick the outcome that matches the reason for changing the system.

Inspect confident errors first. An uncertain response already offers an opportunity to pause; a confident mistake is more likely to pass through an automated gate. Look for recurring causes such as overlapping options, missing context or inconsistent reviewer labels. Fixing a badly defined task may help more than adjusting a threshold around it.

Give the fallback path the same engineering attention as the successful call. Timeouts, invalid responses and uncertainty need explicit behavior. Preserve the question definitions and application version alongside each decision so a reviewer can reconstruct what was asked. An unexplained destination change is difficult to debug even when the underlying API response was perfectly valid.

The launch gives builders a concrete reason to revisit workflows that generate prose only to extract a small judgment from it. The purchase decision, however, rests on the whole process: whether the API makes the intended distinction, whether uncertainty reaches the right person and whether the resulting action improves the service. A cheap answer is useful when the application knows what to do with disagreement.

Frequently asked questions

What is the Gemini Decisions API?

A Google API for bounded multimodal judgments, returning probabilities for yes/no checks, fixed choices and rubric scores.

What does it cost?

Google lists $0.10 per million input tokens and no output-token charge; question instructions and criteria contribute to input usage.

Does confidence make automatic action safe?

Confidence alone does not establish that. Validate the task on representative labeled cases and define an appropriate fallback before granting authority.