Gemini Decision 1: AI Routing Costs and Confidence

Customer requests often reach an application as ordinary language, yet the next operation requires a specific choice between approved destinations. Google’s November 11 announcement addresses that translation with Gemini Decision 1, a model that evaluates supplied options and returns probabilities. Its commercial appeal lies in a narrower purchase: paying for a decision that software can inspect, with the final action remaining subject to the application’s rules.

For a business evaluating AI routing, the interesting question concerns how much of its workload already fits explicit categories. Requests with stable labels offer a sensible starting point. Ambiguous policies demand editorial work by the people who own them, followed by tests against representative customer messages. The announced model supplies a new component for that work; the business still determines which decisions deserve automatic execution.

What Google Released

Google introduced the model through its Gemini Decisions API, available through Google AI Studio, with Google Cloud support described as forthcoming in the announcement. Developers submit shared input alongside independent questions. Google specifies a ceiling of 262,144 input tokens and 1,000 questions per request. Supported material includes text or images. Audio and video are accepted too. PDF documents offer another input format.

Several answer formats accommodate different software needs, with fixed-choice questions accepting between two and 255 options. Binary checks return a probability, and rubric questions evaluate ordered levels. Google describes the returned probabilities as calibrated. The useful engineering difference is their machine-readable relationship to the supplied alternatives: the application receives a result associated with its own categories.

Application designers must decide whether a customer request belongs within those categories in the first place. Google’s API documentation warns that a choice question distributes probability among the supplied options even when the input falls outside their scope. Requests outside the named categories need an explicit fallback destination. Separate scope checks offer another safeguard when business eligibility requires its own decision.

The Invoice Starts with Input

Google’s published paid price is $0.10 per million input tokens, with zero output tokens generated by the Decisions API. Shared input is charged once within a request. Question instructions and criteria contribute additional input tokens, so a longer evaluation still increases consumption. Google’s pricing page lists context caching and Batch API support as unavailable for this model.

For budgeting, the useful comparison is the bill for a completed decision at an acceptable error rate. Token rates alone leave the surrounding application’s costs unresolved. Maintenance belongs in that calculation, as does the labor required to review uncertain cases. Even an inexpensive classification becomes commercially unattractive when its mistakes create expensive corrections in subsequent operations.

Shared-input billing deserves particular scrutiny when several checks use the same document or customer message. Google’s pricing description permits independent questions to reuse that material within the request. Repeated instructions still consume tokens. Teams assessing the savings need actual request measurements, with the question text included, against the current implementation’s total consumption.

Google provides a free tier, and its pricing table identifies free-tier content as eligible for product improvement. Production data deserves a separate contractual review of the selected service tier. Synthetic evaluation material offers a sensible starting point for experimentation; customer records require the organization’s approved handling arrangements.

Confidence Needs Local Evidence

Google’s confidence field estimates the probability that the selected answer is correct, and its documentation recommends choosing thresholds using labeled examples from the application’s own traffic. The project budget needs to include that work. Someone familiar with the business must establish the expected answers, especially for requests where colleagues already disagree.

The most useful evaluation set includes ordinary messages alongside difficult boundary cases, with recent customer language represented in both groups. Support terminology that appears obvious internally may resemble another category in a short customer complaint. When reviewers disagree, the disagreement supplies evidence of an unclear policy or an inadequate label. Reviewers need to resolve that ambiguity as part of preparing the test.

Threshold selection then becomes a business decision with a measurable tradeoff between automatic handling and review workload. As the threshold rises, additional cases generally reach review, subject to the observed score distribution. The relevant calculation includes the staff capacity available for that queue. The remaining requests require a workable destination, even when the automated subset achieves the required accuracy.

Performance deserves examination by category, since a strong overall result may conceal a weak result on an uncommon request type. Expensive mistakes deserve separate treatment in the evaluation report. Incorrectly routed general inquiries and incorrectly authorized account actions have different consequences, even when both count as one error in a summary metric.

Probability as an Input to Software

Permissions belong in application code, where an approved action can be checked against the authenticated user’s authority and current business records. Model confidence supplies evidence for a decision. Payment authorization remains a separate operation, with its own permission requirements. The same separation applies to customer-facing messages that commit the business to an outcome.

For routing work, a useful early deployment keeps the existing operational path active and compares the proposed destination with the actual destination. Disagreements then become reviewable cases for examination prior to customer-facing action. The trial needs a stated sampling period and an agreed acceptance criterion, both selected for the business’s actual volume. The result is an engineering evaluation, distinct from a public benchmark.

OPERENDIA’s custom AI agent development covers systems that connect language interpretation with business operations. When an application has a measured classification problem, a routing model merits evaluation within that engineering discussion. The commercial justification comes from fewer incorrect transfers or a shorter review queue, established through the application’s own evidence. Procurement can then assess the model against a specific operational target.

Read the Latency Claim in Context

Google reports median model computation of approximately 50–100 milliseconds and end-to-end latency of approximately 150–250 milliseconds in its launch material. The reported tests used context lengths up to 16,000 tokens. The announcement describes nearly flat latency across one to 100 questions. Larger supported limits require separate measurement for the intended workload.

Customer-facing applications include network travel and local processing time, so the most relevant timer starts when the request enters that application. Long-tail delays deserve examination alongside the median. Retries consume additional time, and dependent decisions require sequential work when a later question needs an earlier answer. Google’s API guide confirms that questions within one request are evaluated in isolation.

Evaluation Worth Funding

The strongest initial candidate is a frequent classification task whose expected answer is already recorded in existing operations, with a reversible routing action following classification. Historical records with verified final dispositions supply an evaluation set and an observable outcome. Once category-level results establish acceptable accuracy and review demand, the trial has evidence for expansion.

Procurement still needs the selected route’s availability and data terms checked against the deployment’s requirements. OpenRouter currently lists Gemini Decision 1 with a Google AI Studio provider route for evaluation. Provider choice remains an explicit implementation decision. Applications already in production deserve a measured trial with their current traffic patterns prior to approving a replacement.

Gemini Decision 1 makes a specific proposition: software teams can purchase probability-based classification at a low published input rate. The worthwhile question for a business is which existing decisions have sufficiently clear criteria to benefit from that proposition. The documented trial should end with observed errors and measured operating cost, followed by approval for the exact categories that achieved the agreed operational targets.