Gemini Decision 1 API: Now Available on Felo
Explore Google's Gemini Decision 1: fast multimodal decisions, probabilities, pricing, and a practical guide to the Felo OpenAPI Decisions endpoint.
Gemini Decision 1 API: Now Available on Felo
Should an agent search the web, query a database, or ask for clarification? Gemini Decision 1, Google's new model for decisions over predefined options, is now available through Felo OpenAPI.
Google introduced the model on November 11, 2026. It evaluates candidate outcomes in one forward pass and returns probabilities and confidence scores, giving applications a direct signal for routing and grading.
For developers, the appeal is practical: define the decisions your application needs, supply the relevant context, and let your code act on typed results. Felo exposes the model through a dedicated Decisions endpoint. This guide explains the model, where it fits in an agent workflow, and how to make your first Felo request.
alt="Gemini Decision 1 on Felo OpenAPI, illustrating yes/no, choice, and score decisions" src="https://blog-static.felo.ai/gemini_decision_1_cover_final_bd5718bb2d.jpg" />
What is Gemini Decision 1?
Gemini Decision 1 is a specialized multimodal model for bounded decisions. You provide the possible outcomes or scoring criteria; it evaluates them against your input. It can handle text, images, audio, video, and PDFs.
Think of a customer support workflow. A message arrives, and the application needs to know which queue should receive it, whether it needs urgent attention, and how frustrated the customer sounds. Those are several decisions about the same evidence. A product can express each question separately and combine the answers in its own rules.
That separation is useful when building software. The team owns the queue definitions, escalation policy, and actions. The model supplies judgments within those definitions. If the business changes its support categories, the developer can revise the options and evaluate the change against existing examples.
Model specifications
| Property | Google specification |
|---|---|
| Model identifier | gemini-decision-1 |
| Input limit | 262,144 tokens, commonly described as 256K |
| Questions per request | Up to 1,000 independent questions |
| Input modalities | Text, image, video, audio, PDF |
| Decision types | Yes/no, single choice, ordered rubric score |
| Generated output tokens | 0 |
| Choice options | 2–255 |
| Rubric levels | 2–255 |
The input limit covers the request context; generated output tokens remain zero because the model returns decision values. The Felo request fields and a complete text-input example are explained below.
Three decision types for application logic
The model supports three question types: noul, choice, and score. Each has a different role in a workflow.
Yes/no: check a specific condition
A noul question estimates whether a condition holds. For Gemini Decision 1, its yes probability falls between 0.01 and 0.99. For example, a yes probability of 0.03 with confidence of 0.97 means the model is confident the answer is no. Set yes/no thresholds within the supported range.
For a support application, ask whether a customer reports a failed payment. Keep urgency as another question. Combining both into “Is this an urgent payment problem?” makes it harder to tell why the check failed and which action should follow.
Choice: select a route
A choice question returns the winning option and a probability distribution across the candidates, with the probabilities summing to one. Include an explicit fallback category when real inputs may fall outside your routes.
A team might define billing, technical, sales, and other. Write category descriptions around the boundary cases: does a failed payout belong to billing, or does a broken payout integration belong to technical support? Precise descriptions give you something concrete to improve when reviewing errors.
Score: apply an ordered rubric
A score question uses ordered criteria starting at index zero. Its result is a probability-weighted score, so it may lie between levels. For an illustrative three-level rubric, probabilities of 0.1, 0.2, and 0.7 produce a score of 1.6: (0 × 0.1) + (1 × 0.2) + (2 × 0.7).
For example, a document review could use “missing required information,” “partially complete,” and “complete.” Define what each level requires. A rubric that says only “bad, average, good” leaves too much interpretation to the model and makes disagreement harder to resolve.
Questions share the input but are evaluated independently. If a later decision depends on an earlier answer, combine the results in code or make a subsequent request.
alt="A customer message evaluated for urgency, support team, and frustration, followed by application routing rules" src="https://blog-static.felo.ai/gemini_decision_1_workflow_90979625c6.jpg" />
Speed, pricing, and the meaning of confidence
Google reports 150–250 ms end-to-end latency, including 50–100 ms of model compute, in the described tests with contexts up to 16K tokens. Latency stayed nearly flat across 1–100 questions. These figures have a narrower scope than the maximum context and question limits; they are Google measurements, not a Felo latency guarantee.
Google also reports strong calibration and performance across its evaluation suite. Its published comparison puts the Decisions API at nearly five times the cost efficiency of Gemini 3.5 Flash-Lite through the Interactions API on the shared benchmarks. That comparison describes those tests, rather than every possible workload.
For an application, evaluate the entire path. Measure the time from receiving a request to taking a useful action, including network calls and any fallback. A fast classification step helps only if it selects the right route often enough.
Current Felo listing
On November 12, Felo's Gemini Decision 1 page lists the Google AI Studio provider at $0.10 per million input tokens and $0 per million output tokens. Check the live provider details before estimating a production bill. Felo model page
At that input rate, 10 million billable input tokens would cost $1 for the input-token component. This is arithmetic based on the listed rate, not a forecast of how much traffic your application can process for $1. Input length and question definitions determine consumption.
Confidence gives you a way to manage ambiguity. Choose an initial threshold, then test it on labeled examples. Compare the cost of a wrong automatic route with the cost of sending another case for review. A support queue and a document quality check may need different thresholds even if they use the same model.
Where Gemini Decision 1 fits in a workflow
The following are application designs to try, rather than measured customer results.
Agent tool and model routing
An agent can first classify whether a request needs fresh information, internal records, or document analysis. Your application then selects an available tool. Keep a clarification route for requests that omit essential details.
You can also test routing by task difficulty. Define what qualifies a request for a more capable model and compare the resulting workflow against sending every request to that model. Track total cost per successful task, including mistakes that require retries.
Tool selection still needs application code. Selecting a tool name does not execute that tool or construct a validated set of arguments. Keep those steps explicit so that routing quality can be assessed independently of tool failures.
Customer support triage
Evaluate department, urgency, and sentiment against one customer message. Use your own rules to turn those results into a queue and priority. For example, a payment failure might need billing support even if the customer describes it calmly.
This is a useful starting project because teams often already have historical tickets and assigned queues. Review disagreements with support staff, update ambiguous category descriptions, and preserve the revised evaluation set for later changes.
Retrieval and document quality
A retrieval application could score candidate passages against a relevance rubric before a writing model prepares an answer. Keep source identifiers attached to the passages so the next stage can trace its evidence.
For document intake, turn a checklist into separate questions: required section present, date readable, supporting attachment included. Route incomplete submissions with a specific reason. If your product also needs a written explanation, use the decision results as input to a separate generation step.
Multimodal review
Delivery photos or recorded calls are possible inputs for bounded checks. For a delivery photo, a checklist might ask whether a parcel is visible and whether its placement matches instructions. For a call, it might check whether a required disclosure was given.
Before implementing these examples on Felo, verify the accepted media representation for the route. Model-level multimodal support and the exact JSON needed to submit a file are separate integration details.
Call Gemini Decision 1 through Felo OpenAPI
Felo's model page documents a non-streaming Decisions route:
POST https://openapi.felo.ai/api/v1/decisions
Use the model ID gemini-decision-1, a shared state, and a questions map. This is a dedicated endpoint, separate from Chat Completions, Messages, and Responses. Felo model quickstart
1. Set up your Felo account
Create a key in the API key console. Felo uses USD-denominated service credits, with top-ups from $1 and no required subscription. Check your balance before sending paid requests. Felo getting started
Store the key in a server-side environment variable:
export FELO_API_KEY="YOUR_FELO_API_KEY"
2. Understand the request fields
| Field | What to provide |
|---|---|
model | Use gemini-decision-1 to select this model. |
state | Shared evidence to evaluate. The text example below sends a customer message as a string. |
questions | An object whose keys are names you choose, such as is_urgent and department. |
questions.<name>.type | Choose noul, choice, or score. |
questions.<name>.instructions | Describe one specific decision the model should make. |
questions.<name>.criteria | For noul, optional true/false descriptions in Felo's example format; for choice, a map of option IDs to descriptions; for score, an ordered array of rubric descriptions. |
Send JSON with Content-Type: application/json and authenticate with Authorization: Bearer YOUR_FELO_API_KEY. The route returns a complete non-streaming response. Each question evaluates the shared input independently; a question cannot use another question's answer from the same request.
3. Send a support triage request
The following request follows Felo's documented state/questions format and demonstrates all three question types. The categories and rubric are illustrative; adapt them to your own support process.
curl -sS https://openapi.felo.ai/api/v1/decisions \
-H "Authorization: Bearer $FELO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gemini-decision-1",
"state": "Help! My payouts have been failing for 3 days.",
"questions": {
"is_urgent": {
"type": "noul",
"instructions": "Does this message convey urgency?",
"criteria": {
"true": "Time-sensitive",
"false": "No urgency"
}
},
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, invoicing, refunds",
"technical": "Bugs, outages, integrations",
"sales": "Pricing, upgrades, new accounts",
"other": "Requests outside these categories"
}
},
"frustration": {
"type": "score",
"instructions": "How frustrated is the customer?",
"criteria": ["Calm", "Frustrated", "Very angry"]
}
}
}'
The example uses Felo's documented request format. Replace the sample message and category descriptions with your own data.
4. Call the same endpoint from Python
Install the HTTP client once:
pip install requests
This standalone example selects a support department. It uses the same environment variable, endpoint, and request structure as the cURL example:
import json
import os
import requests
payload = {
"model": "gemini-decision-1",
"state": "I was charged twice for my order.",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, invoicing, refunds",
"technical": "Bugs, outages, integrations",
"sales": "Pricing, upgrades, new accounts",
"other": "Requests outside these categories",
},
}
},
}
response = requests.post(
"https://openapi.felo.ai/api/v1/decisions",
headers={
"Authorization": f"Bearer {os.environ['FELO_API_KEY']}",
"Content-Type": "application/json",
},
json=payload,
timeout=30,
)
response.raise_for_status()
result = response.json()
print(json.dumps(result, indent=2, ensure_ascii=False))
raise_for_status() reports HTTP errors before the script processes the response. The final line displays the actual returned JSON so you can inspect your route's answer and usage fields before connecting application logic.
5. Read the decisions and connect your rules
| Question type | How to interpret the decision |
|---|---|
noul | Read the probability that the answer is yes. Compare it with your yes/no threshold. |
choice | Read the selected option and the distribution across candidates. Use confidence to decide whether to route automatically. |
score | Read the weighted rubric score and per-level probabilities. Fractional scores can fall between your rubric levels. |
Confidence expresses certainty about the leading outcome. It does not indicate whether an outcome is desirable: a confident rejection and a confident approval can both have high confidence. Your application decides which actions follow.
Save the actual response from your first request and inspect the answer for each question. Use the department choice to propose a queue, then apply your escalation rules. Preserve the probabilities alongside the chosen action for later evaluation.
Start with a reviewable workflow. Run historical tickets through the endpoint, compare proposed queues with known assignments, and inspect cases that cross your confidence threshold incorrectly. Include unclear messages and requests outside the defined categories.
Keep error handling separate from uncertainty handling. A failed HTTP request needs a retry or operational fallback; a successful response with an ambiguous decision needs your application's review policy. Record both so that reliability problems do not get mistaken for model judgment problems.
Build your first decision layer with Felo
Felo OpenAPI brings Gemini Decision 1 into the same platform developers use for other model APIs. One Felo key and platform balance provide a practical starting point for combining a decision stage with the models and tools your application needs. Each model still uses its supported protocol. Felo Model API overview
Choose one bounded problem first: route a support ticket, grade a retrieved passage, or check a document against a short rubric. Define the options, collect examples, and decide how ambiguous results should be handled. That gives you a useful basis for evaluating Gemini Decision 1 before expanding the workflow.