Gemini Decision 1 बनाम Jev: कीमत, लेटेंसी और Python सेटअप

मल्टीमोडल रूटिंग और एक ही इनपुट पर कई स्वतंत्र जाँचों के लिए Gemini Decision 1 आज़माएँ। जब कीमत और लेटेंसी सबसे ज़रूरी हों, तो टेक्स्ट रूटिंग में तुलना की शुरुआत Jev से करें। कोड, व्याख्या, इनपुट से निकाले गए मनचाहे मान या टूल के आर्ग्युमेंट चाहिए हों, तो जनरेटिव मॉडल इस्तेमाल करें।

Google ने 11 नवंबर 2026 को Gemini Decision 1 लॉन्च किया। 2026-11-13 तक Decisions API, Gemini API के ज़रिए उपलब्ध है। Python के लिए इसका समर्थन google-genai 3.2.0 और बाद के संस्करणों में है। यह निर्णय लेने का एंडपॉइंट है, कोडिंग चैट में इस्तेमाल होने वाले मॉडल का विकल्प नहीं।

Gemini Decision 1 क्या लौटाता है?

Gemini Decision 1 टोकन-दर-टोकन उत्तर लिखने के बजाय पहले से तय विकल्पों का आकलन करता है। आप साझा इनपुट और अधिकतम 1,000 स्वतंत्र प्रश्न देते हैं। संदर्भ विंडो 262,144 tokens की है, जिसे आम तौर पर 256K कहा जाता है। इनपुट और प्रश्नों को मिलाकर इसी सीमा में रखें।

Decisions API की गाइड में तीन प्रकार के प्रश्न दिए गए हैं:

प्रकार	अनुरोध में क्या तय करें	उत्तर से क्या पढ़ें
noul	हाँ/नहीं वाला प्रश्न; वैकल्पिक मानदंड दोनों परिणामों का अर्थ स्पष्ट करते हैं।	noul, यानी हाँ की संभावना, और confidence।
choice	विवरण के साथ 2 से 255 नाम वाले विकल्प।	चुना गया choice, सामान्यीकृत probabilities और confidence।
score	क्रमबद्ध मूल्यांकन पैमाना, जिसके पहले स्तर का इंडेक्स 0 हो।	संभावनाओं के आधार पर भारित score, हर स्तर की probabilities और confidence।

कोडिंग एजेंट में ये अलग-अलग सवालों का उत्तर दे सकते हैं। क्या काम के लिए रिपॉज़िटरी का संदर्भ चाहिए? अगला टूल कौन-सा होना चाहिए? काम की जाँच में कितना प्रयास लगेगा?

प्रश्न एक-दूसरे से स्वतंत्र हैं। एक ही अनुरोध में कोई प्रश्न दूसरे प्रश्न का उत्तर इस्तेमाल नहीं कर सकता। परिणामों को अपने ऐप्लिकेशन के कोड में जोड़ें। अगले निर्णय के लिए पहले उत्तर की ज़रूरत हो, तो अलग अनुरोध भेजें।

noul का ऊँचा विश्वास स्तर हमेशा “हाँ” नहीं दर्शाता। SDK में noul 0.01 से 0.99 के बीच की संभावना है। उसका विश्वास स्तर max(noul, 1 - noul) होता है। इसलिए noul = 0.03 का अर्थ 0.97 विश्वास स्तर के साथ “नहीं” है।

score का मान पैमाने के दो स्तरों के बीच भी आ सकता है। उसका विश्वास स्तर किसी एक स्तर की सबसे ऊँची संभावना है। यह इस बात की संभावना नहीं है कि लगातार बदल सकने वाला औसत मान बिल्कुल सही है। कोड में सीमाएँ तय करते समय यह अंतर ध्यान में रखें।

Jev से परिचित पाठक इन प्रकारों को Jev निर्णय मॉडल के उपयोगों वाली हमारी गाइड के उदाहरणों से जोड़ सकते हैं। मिलती-जुलती अवधारणाओं का अर्थ यह नहीं कि दोनों प्रदाताओं के अनुरोध प्रारूप एक-दूसरे की जगह इस्तेमाल हो सकते हैं।

Gemini Decision 1 बनाम Jev: माप क्या बताते हैं?

सिर्फ टेक्स्ट वाले राउटर के लिए Jev से शुरुआत करें, बशर्ते आपके अपने परीक्षण में दोनों का गुणवत्ता स्तर तुलनीय हो। अलग-अलग माध्यमों के इनपुट का सीधा समर्थन काम बदलता हो, तो Gemini को अलग से आज़माएँ।

नीचे सीधे API की दरें Google की कीमतों वाले पृष्ठ और TypeSafe की कीमत संबंधी जानकारी से ली गई हैं। बेंचमार्क आँकड़े Artificial Analysis की Gemini Decision 1 प्रोफ़ाइल और Jev 1.14 प्रोफ़ाइल से हैं। इन सभी स्रोतों की जाँच 2026-11-13 को हुई थी।

माप	Gemini Decision 1	Jev 1.14
सीधे API का मॉडल ID	gemini-decision-1	jev-1.14.0
सीधे API की इनपुट कीमत, प्रति 1M tokens USD में	$0.10	$0.042
सीधे API का आउटपुट-टोकन शुल्क	$0	$0
Artificial Analysis Decision Index	66	66
AA के प्रति 1M बेंचमार्क कार्यों की लागत, USD में	$345	$156
AA Time per Task	211 ms	92 ms

पूर्णांक में दिखाए गए इंडेक्स स्कोर समान होने पर AA के आँकड़े कीमत और समय के हिसाब से Jev के पक्ष में हैं। वे आपके टूल-चयन वाले प्रश्नों पर समान सटीकता साबित नहीं करते। बेंचमार्क कार्य HTTP अनुरोधों से भी अलग हैं। अपने अनुरोधों की संख्या से इन आँकड़ों को गुणा करके बिल न निकालें।

Google अपने लॉन्च बेंचमार्क समूह में बढ़त का दावा करता है। साझा बेंचमार्क पर वह Interactions API वाले Gemini 3.5 Flash-Lite के मुकाबले लगभग 5x कम लागत भी बताता है। यह AA के इंडेक्स से अलग तुलना है। इससे हर काम में Jev पर बढ़त साबित नहीं होती।

12 नवंबर के लॉन्च विश्लेषण में Artificial Analysis ने Gemini का Brier score 0.18 और Jev का 0.19 बताया। संभावनाओं की त्रुटि मापने वाले इस पैमाने में कम मान बेहतर है। कुल स्कोर का यह छोटा अंतर आपके ऐप्लिकेशन के लिए सुरक्षित विश्वास-सीमा तय नहीं करता।

Google का लेटेंसी दावा भी खास परिस्थितियों तक सीमित है। मॉडल की गणना का माध्यिका समय 50–100 ms और शुरू से अंत तक का समय 150–250 ms बताया गया है। यह 16K tokens तक के संदर्भ पर लागू है। 1 से 100 प्रश्नों के बीच लेटेंसी लगभग समान रहती है। यह दावा 1,000 प्रश्नों या पूरे 256K संदर्भ पर लागू न मानें।

मल्टीमोडल काम में अंतर अधिक स्पष्ट है। Google टेक्स्ट, चित्र, ऑडियो, वीडियो और PDF इनपुट के सीधे समर्थन का दस्तावेज़ देता है। TypeSafe का मॉडल संदर्भ टेक्स्ट और चित्रों को सूचीबद्ध करता है, लेकिन ऑडियो या वीडियो का सीधा समर्थन नहीं बताता। Jev 1.14 के ऐलान में TypeSafe ने चित्रों से जुड़ी सुविधाओं को प्रयोगात्मक भी कहा है।

रिकॉर्डिंग, वीडियो या PDF पर निर्णय लेने के लिए Gemini से शुरुआत करें। मौजूदा टेक्स्ट राउटर के लिए पहले Jev आज़माएँ। किसी भी चुनाव को बदलें, यदि लेबल किए गए डेटा पर परीक्षण कम त्रुटियाँ, स्वीकार्य लेटेंसी और पूरी प्रक्रिया की कम लागत दिखाए।

साझा इनपुट से बिल कैसे बदलता है?

एक ही इनपुट की जाँच करने वाले संबंधित प्रश्न साथ भेजें। Google हर अनुरोध में साझा इनपुट का शुल्क केवल एक बार लेता है। हर प्रश्न फिर भी अपने निर्देशों, मानदंडों और फ़ॉर्मैटिंग के टोकन जोड़ता है।

2026-11-13 को जाँची गई सीधे भुगतान वाली दर पर:

request cost in USD =
(shared input tokens + all question tokens) × $0.10 / 1,000,000

एक अनुमान लें, जिसमें साझा इनपुट 10,000 tokens का है और 100 प्रश्न हैं। मान लें कि फ़ॉर्मैटिंग सहित हर प्रश्न 80 भुगतान योग्य टोकन जोड़ता है।

अनुरोध का तरीका	अनुमानित भुगतान योग्य इनपुट	सीधे API की अनुमानित लागत
100 प्रश्नों वाला एक अनुरोध	10,000 + 100 × 80 = 18,000 tokens	$0.0018
वही इनपुट दोहराने वाले 100 अलग अनुरोध	100 × (10,000 + 80) = 1,008,000 tokens	$0.1008

यह Gemini को अनुरोध भेजने के दो तरीकों की तुलना है। इससे यह दावा नहीं किया जाता कि साझा इनपुट पर मूल्यांकन केवल Google में संभव है।

इस अनुमान में दोबारा कोशिशें, बाद में होने वाले मॉडल कॉल और गेटवे शुल्क शामिल नहीं हैं। इसमें किसी छूट या मुफ्त कोटे को नहीं माना गया है। अनुमानित टोकन संख्या की जगह वास्तविक खपत लेने के लिए result.usage.total_input_tokens इस्तेमाल करें।

एक इंटरैक्टिव अनुरोध में कई प्रश्न जोड़ना, असिंक्रोनस बैच जॉब भेजने से अलग है। Google के कीमतों वाले पृष्ठ के अनुसार Gemini Decision 1, Batch API का समर्थन नहीं करता।

Python में टूल चुनने का उदाहरण चलाएँ

पहले परीक्षण के लिए सीधे Gemini API का इस्तेमाल करें। इससे शुरुआती जाँच में गेटवे के अनुरोध प्रारूप का रूपांतरण अलग रहता है।

नीचे तय किए गए SDK संस्करण के लिए Python 3.11 या बाद का संस्करण चाहिए। Google के API कुंजी निर्देशों से कुंजी बनाएँ और समर्थित क्षेत्रों की जाँच करें।

परीक्षण के लिए कृत्रिम इनपुट इस्तेमाल करें। निजी रिपॉज़िटरी की सामग्री भेजने से पहले Gemini API की सेवा शर्तें पढ़ें।

SDK इंस्टॉल करें और कुंजी लोड करें

ये कमांड Bash में चलाएँ। कुंजी लिखते समय दिखाई नहीं देगी और उसका वास्तविक मान कमांड इतिहास में दर्ज नहीं होगा।

python3 -m venv .venv
source .venv/bin/activate
python -m pip install "google-genai==3.2.0"
read -rs GEMINI_API_KEY && export GEMINI_API_KEY

उदाहरण इस एनवायरनमेंट वैरिएबल का मान सीधे क्लाइंट को देता है। यह टेक्स्ट जनरेशन विधि के बजाय v1beta और client.decisions.create इस्तेमाल करता है। इसका सीधा REST समकक्ष POST https://generativelanguage.googleapis.com/v1beta/decisions है।

उत्तर को रूटिंग योजना में बदलें

इसे route_decision.py नाम से सहेजें। यह तीनों प्रकार के प्रश्न पूछता है, उत्तरों के प्रकार जाँचता है और मशीन द्वारा पढ़ी जा सकने वाली रूटिंग योजना निकालता है।

import json
import os

from google import genai
from google.genai.decisions import ChoiceAnswer, NoulAnswer, ScoreAnswer

api_key = os.environ.get("GEMINI_API_KEY")
if not api_key:
    raise SystemExit("Set GEMINI_API_KEY before running this script.")

client = genai.Client(
    api_key=api_key,
    http_options={"api_version": "v1beta"},
)

try:
    result = client.decisions.create(
        model="gemini-decision-1",
        input=(
            "Task: Explain why parse_config rejects an empty YAML file. "
            "Repository: Python service with src/config.py and "
            "tests/test_config.py. No file contents are provided. "
            "Start with read-only investigation."
        ),
        questions={
            "needs_repo": {
                "type": "noul",
                "instructions": "Must the next step inspect repository files?",
            },
            "next_tool": {
                "type": "choice",
                "instructions": "Choose the next read-only investigation step.",
                "criteria": {
                    "read_repo": "Inspect existing source files or tests.",
                    "read_docs": "Look up public API behavior.",
                    "no_tool": "The supplied text is sufficient.",
                    "human_review": "The task is ambiguous or outside these options.",
                },
            },
            "effort": {
                "type": "score",
                "instructions": "Rate the investigation effort this task needs.",
                "criteria": [
                    "Simple lookup or local explanation.",
                    "Investigation across source code and tests.",
                    "Architecture or security analysis with several dependencies.",
                ],
            },
        },
    )
except Exception as exc:
    raise SystemExit(
        f"Decision request failed ({type(exc).__name__}); no action selected."
    ) from None

answers = result.answers or {}
repo = answers.get("needs_repo")
tool = answers.get("next_tool")
effort = answers.get("effort")
if not (
    isinstance(repo, NoulAnswer)
    and isinstance(tool, ChoiceAnswer)
    and isinstance(effort, ScoreAnswer)
    and result.usage is not None
):
    raise SystemExit("Incomplete decision response; send this task for review.")

# Illustrative thresholds. Tune them on labeled traffic before deployment.
next_tool = tool.choice if tool.confidence >= 0.85 else "human_review"
if next_tool == "read_repo" and repo.noul < 0.85:
    next_tool = "human_review"
if next_tool not in {"read_repo", "read_docs", "no_tool", "human_review"}:
    next_tool = "human_review"

model_tier = (
    "reasoning"
    if effort.score >= 1.5 or effort.confidence < 0.80
    else "small"
)

print(json.dumps({
    "next_tool": next_tool,
    "model_tier": model_tier,
    "repository_probability": repo.noul,
    "tool_confidence": tool.confidence,
    "effort_score": effort.score,
    "input_tokens": result.usage.total_input_tokens,
    "output_tokens": result.usage.total_output_tokens,
}, indent=2))

उसी Bash सत्र में इसे चलाएँ:

python route_decision.py

सफल कॉल में तीनों माँगी गई कुंजियों के अंतर्गत उत्तर आते हैं और आउटपुट टोकन की संख्या शून्य होती है। स्क्रिप्ट को टूल का लेबल, मॉडल स्तर का लेबल, संभावनाएँ और खपत दिखानी चाहिए। किसी खास संभावना या रूट को सुनिश्चित परिणाम न मानें।

0.85, 0.80 और 1.5 की सीमाएँ उदाहरण के लिए तय किए गए ऐप्लिकेशन नियम हैं, प्रदाता की सिफ़ारिशें नहीं। small और reasoning स्थानीय रूटिंग लेबल हैं, API मॉडल ID नहीं।

यह प्रोग्राम केवल योजना बनाता है। यह फ़ाइलें नहीं पढ़ता, कमांड नहीं चलाता और चुने गए स्तर का मॉडल कॉल नहीं करता। एजेंट को नियंत्रित करने वाले कोड को इन लेबलों का मिलान अनुमत टूल और तैनात मॉडलों से करना होगा। फ़ाइल सिस्टम की अनुमतियाँ और कमांड की मंज़ूरी मॉडल के निर्णय से अलग रखें।

यही अलगाव व्यावसायिक ऑटोमेशन में भी लागू होता है। हमारी Jev टिकट-रूटिंग प्रक्रिया बताती है कि वर्गीकरण को जाँच और ज़रूरत पड़ने पर मानवीय समीक्षा वाली बड़ी प्रक्रिया में कैसे जोड़ें।

मुफ्त स्तर की सीमाएँ और संभावित त्रुटियाँ क्या हैं?

लोड परीक्षण से पहले अनुरोधों और टोकन, दोनों का कोटा जाँचें। अधिक प्रश्नों की अनुमति होने से अनुरोध दर की सीमाएँ समाप्त नहीं होतीं।

2026-11-13 को जाँची गई Google की प्रकाशित Gemini Decision 1 सीमाओं में ये मान शामिल हैं:

उपयोग स्तर	प्रति मिनट अनुरोध	प्रति मिनट इनपुट टोकन	प्रतिदिन अनुरोध
Free	200	50,000	10,000
Tier 1	1,500	1,000,000	50,000

तैनाती से पहले AI Studio में अपने प्रोजेक्ट की लागू सीमाएँ देखें। Google चेतावनी देता है कि प्रकाशित सीमाएँ उपलब्ध क्षमता की गारंटी नहीं हैं। अन्य भुगतान वाले स्तर उसी संदर्भ में दिए गए हैं।

क्लाइंट में decisions एट्रिब्यूट न मिले, तो python -m pip show google-genai से इंस्टॉल किया गया पैकेज जाँचें। पैकेज को उसी वर्चुअल एनवायरनमेंट में अपडेट करें जहाँ स्क्रिप्ट चलती है। Decisions का समर्थन SDK 3.2.0 में आया था।

अनुरोध दर की सीमा से जुड़ी त्रुटियों पर दोबारा कोशिश करने से पहले अनुरोधों की आवृत्ति या इनपुट की मात्रा घटाएँ। अस्थायी त्रुटियों के लिए Google की समस्या-निवारण गाइड प्रतीक्षा समय को घातांकीय ढंग से बढ़ाने, उसमें यादृच्छिक अंतर जोड़ने और कोशिशों की संख्या सीमित रखने को कहती है। इस यादृच्छिक अंतर को jitter कहते हैं। दैनिक कोटा समाप्त हो जाए, तो उसके रीसेट होने की प्रतीक्षा करें या उसे बढ़वाएँ। लगातार तेज़ी से कोशिश करना समाधान नहीं है।

कंटेंट मॉडरेशन में एक अतिरिक्त त्रुटि-स्थिति की योजना बनाएँ। इनपुट सुरक्षा फ़िल्टर अनुरोध को रोक दें, तो Decisions API उत्तरों के बजाय 400 Bad Request लौटा सकता है। अनुरोध रुकने का अर्थ यह नहीं कि नीति की जाँच का उत्तर “नहीं” है। ऐसे मामले को समीक्षा या किसी अन्य स्वीकृत प्रक्रिया में भेजें। उत्तर न मिलने को आगे बढ़ने की अनुमति न समझें।

क्या OpenRouter या Vercel पर वही अनुरोध चलेगा?

दोनों google/gemini-decision-1 को सूचीबद्ध करते हैं, लेकिन उनके इंटरफ़ेस Google के सीधे Python उदाहरण से अलग हैं। गेटवे को मौजूदा इंटीग्रेशन के हिसाब से चुनें। केवल बेस URL बदलना पर्याप्त नहीं है।

OpenRouter के मॉडल पृष्ठ पर यह मॉडल सूचीबद्ध है। उसका Decisions API संदर्भ POST https://openrouter.ai/api/alpha/decisions बताता है, जहाँ साझा सामग्री state में जाती है। एंडपॉइंट alpha अवस्था में है और उसकी स्कीमा बदल सकती है। मॉडल पृष्ठ यह भी कहता है कि EU क्षेत्र के भीतर रूटिंग अभी उपलब्ध नहीं है।

Vercel के लॉन्च दस्तावेज़ में वही मॉडल ID दिया गया है। PDF, ऑडियो और वीडियो इनपुट के लिए वहाँ बताया गया AI SDK 7 वाला तरीका चाहिए। उसके TypeSafe-संगत और Decisions API टेक्स्ट तथा चित्रों का समर्थन करते हैं।

Vercel के निर्णय इंटरफ़ेस के दस्तावेज़ में अलग इंटरफ़ेस के लिए अलग अनुरोध संरचनाएँ भी हैं। AI SDK में state और boolean हैं। उसके HTTP Decisions इंटरफ़ेस में input और predicate हैं। Google का noul अनुरोध दस्तावेज़ में दी गई स्कीमा के अनुसार बदले बिना इनमें न भेजें।

गेटवे पर मॉडल की सूची मौजूद होने से हर देश में पहुँच साबित नहीं होती। इससे डेटा को किसी तय क्षेत्र में रखने की शर्त भी पूरी नहीं मानी जा सकती। प्रोडक्शन ट्रैफ़िक भेजने से पहले सेवा इस्तेमाल करने की पात्रता, डेटा का प्रबंधन और गेटवे शुल्क जाँचें।

राउटर बदलने से पहले क्या मापें?

शुरुआत में नए राउटर को निर्णय सुझाने दें, लेकिन कार्रवाइयाँ नियंत्रित न करने दें। उसके सुझाए रूट की तुलना लेबल किए गए उदाहरणों और मौजूदा सिस्टम के निर्णयों से करें।

अपने-आप पूरे होने वाले कामों का अनुपात स्थिर रखकर गलत स्वचालित कार्रवाइयाँ मापें। यह भी दर्ज करें कि कितनी बार वैकल्पिक तरीका अपनाना पड़ा, पूरे अनुरोध की p50 और p95 लेटेंसी क्या रही, कितनी दोबारा कोशिशें हुईं और कुल लागत कितनी थी। मॉडल संस्करण, प्रश्न की भाषा या विकल्पों की सूची बदलने पर सीमाएँ फिर जाँचें।

निश्चित नियमों वाले काम कोड में रखें। ज्ञात एग्ज़िट कोड की जाँच या किसी सटीक अनुमति नियम का मिलान करने में निर्णय मॉडल बहुत कम लाभ देता है। पैच, व्याख्या या नए आर्ग्युमेंट वाला टूल कॉल चाहिए, तो जनरेटिव मॉडल अब भी सही विकल्प है।

कोडिंग प्रक्रिया की तुलना में काम करने के लिए चुने गए मॉडल की लागत और विफलताएँ भी जोड़ें। हमारी कोडिंग एजेंट की प्रति कार्य लागत वाली गाइड समझाती है कि सस्ता रूटिंग कॉल भी पूरे काम को महँगा क्यों बना सकता है।