Chrome Prompt API

• Chrome में बिल्ट-इन Gemini Nano मॉडल को natural language अनुरोध भेजने के लिए browser-native API, जो server round-trip के बिना on-device AI inference करता है
• AI-आधारित search, news classification के जरिए personalized feed, content filtering, calendar schedule creation, contact extraction आदि जैसे कई उपयोग संभव
• prompt() से एक बार में response या promptStreaming() से ReadableStream-आधारित streaming response चुना जा सकता है
• session-आधारित context management, streaming response, session clone आदि जैसे सूक्ष्म session control features प्रदान करता है
• server round-trip के बिना browser के भीतर AI inference होने से privacy protection और response latency को न्यूनतम करने में लाभदायक
• text के साथ-साथ image और audio input को सपोर्ट करने वाली multimodal capability बिल्ट-इन है
  • audio: AudioBuffer, ArrayBuffer, Blob आदि
  • image: HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob आदि
• responseConstraint फ़ील्ड में JSON schema देकर मॉडल के output format को boolean, किसी विशेष JSON structure आदि तक सीमित किया जा सकता है
• initialPrompts से system prompt और पिछले conversation context को inject किया जा सकता है, और append() से session बनने के बाद भी अतिरिक्त context को पहले से भेजना संभव है
• बाद में आने वाले assistant message में prefix: true जोड़ने पर मॉडल को किसी विशेष format में response शुरू करने के लिए प्रेरित किया जा सकता है
• हर session के लिए context window management समर्थित है: contextUsage/contextWindow से token usage देखा जा सकता है, और overflow होने पर शुरुआती conversation अपने-आप हट जाती है (system prompt बना रहता है)
• clone() से session fork, destroy() से resource release, और AbortSignal से session तथा prompt को बीच में cancel किया जा सकता है
• expectedInputs/expectedOutputs से input-output format और language सेट की जा सकती है (फ़िलहाल en, ja, es समर्थित)
• hardware requirements: Windows 10+/macOS 13+/Linux/ChromeOS, कम-से-कम 22GB storage, GPU VRAM 4GB से अधिक या CPU RAM 16GB से अधिक + कम-से-कम 4 cores
• cross-origin iframe में allow="language-model" attribute के जरिए access delegate किया जा सकता है, web worker में फिलहाल unsupported
• Chrome 138 से origin trial के रूप में उपलब्ध

[GN⁺]

Hacker News की राय

• यह API मेरे लंबे समय से सोचे जा रहे de-snarkifier आइडिया के लिए बिल्कुल सही लगती है
  सोशल मीडिया बौद्धिक रूप से उत्तेजक हो सकता है और उससे बहुत कुछ सीखा भी जा सकता है, लेकिन चाहें या न चाहें, विचारधारात्मक बहसों और फ्लेमवार में खिंच जाना बहुत आसान है। इंटरनेट पर अजनबियों से भावनात्मक ऊर्जा खर्च करके लड़ना लगभग मानवीय पूंजी की बर्बादी जैसा है
  अगर ऐसी API हो, तो ब्राउज़र एक्सटेंशन के ज़रिए किसी पोस्ट को दिखाने से पहले सिर्फ आक्रामक या तंजभरे वाक्यांशों को नरम किया जा सकता है, जबकि तथ्यात्मक जानकारी जस की तस रखी जा सकती है। इससे भी आगे बढ़कर, जितना अधिक आक्रामक टोन हो, उसे उतना ही हास्यास्पद या अयोग्य सुनाई देने वाला बनाया जा सकता है
  तब पढ़ने वाले लोग अजनबियों के व्यक्तिगत हमलों से बचे रहेंगे, और लिखने वालों की भी बदतमीज़ी से पेश आने की प्रेरणा कम हो जाएगी। अगर सब ऐसे फ़िल्टर इस्तेमाल करें, तो कौन ज़्यादा घटिया व्यवहार करता है इसकी होड़ भी खत्म हो जाएगी

  • यह लिखित संचार का Soylent जैसा है
    पोषण तो पूरा है, लेकिन स्वाद में कुछ खास नहीं
  • ऐसे टूल का मुझे सच में इंतज़ार है। यह इंटरनेट की empty calories हटाकर आज के लोकप्रिय प्लेटफ़ॉर्म्स का इस्तेमाल काफ़ी कम कर सकता है
    मुझे तो बस इतना चाहिए कि सारे clickbait titles और विज्ञापन हट जाएँ, और सिर्फ सूखे, तथ्यात्मक शीर्षक दिखें
    किसी भी विषय पर एक मुख्य लेख और कुछ सार्थक टिप्पणियाँ काफी हैं, बाकी ज़्यादातर ऐसा शोर है जिसे मैं देखना ही नहीं चाहता
    सोशल मीडिया की हालत अभी इतनी खराब है कि मैं लगभग इसका इस्तेमाल नहीं करता, सिर्फ HN अपवाद था, लेकिन अब यहाँ भी AI की भरमार के साथ वही दिशा दिख रही है। फिर भी हर दो हफ़्ते में कुछ घंटे बर्बाद कर ही देता हूँ, और वह भी पूरी तरह छोड़ देना चाहता हूँ
    आदर्श रूप से मैं चाहता हूँ कि 98% कंटेंट फ़िल्टर या समरी होकर गायब हो जाए, और समय के साथ इंटरनेट सिर्फ तब इस्तेमाल हो जब मैं जानबूझकर कुछ खोज रहा हूँ। मूल रूप से मैं इंटरनेट के मनोरंजन पहलू का अधिकांश हिस्सा हटाना चाहता हूँ ताकि समय और ऊर्जा को वास्तविक दुनिया और किताबों जैसे उच्च-गुणवत्ता स्रोतों की ओर मोड़ा जा सके
  • YouTube पर ऐसा कुछ पहले से है, और मैं DeArrow इस्तेमाल करता हूँ
    यह एक्सटेंशन क्राउडसोर्सिंग के ज़रिए सनसनीखेज़ी कम करने की कोशिश करता है, हालांकि मुझे लगता है कि इसके कुछ टॉप योगदानकर्ता LLM bots भी हो सकते हैं
  • दिलचस्प आइडिया है, खोजबीन करने लायक लगता है
    बस ऐसी चीज़ें जब वास्तविक दुनिया से टकराती हैं तो परिणाम अनिश्चित होते हैं, और अगर यह काम भी करे तो शायद वैसा नहीं करेगी जैसा शुरुआत में सोचा गया था
  • मैं Chrome की built-in AI APIs का PM हूँ, और यह de-snarkifier आइडिया मुझे वाकई बहुत पसंद आया, साथ ही इसमें व्यापक रुचि भी दिख रही है
    मैं खुद को रोक नहीं पाया और जल्दी में Snarknada का एक प्रोटोटाइप बना डाला, ताकि low-latency patterns और accuracy की संभावनाओं को साथ में देख सकूँ
    ऐसे use case में on-device सही क्यों है, इसकी वजह यही है। अगर पूरे infinite scroll feed को cloud API से नरम बनाना हो, तो token cost डेवलपर के लिए असहनीय हो जाएगी। ऊपर से यह भी स्वाभाविक है कि लोग अपने निजी feed या DM को tone साफ़ करने के लिए किसी third-party server पर भेजना नहीं चाहेंगे
    इसे डिवाइस के अंदर ले आने से high-frequency Semantic Mutation पहली बार लागत और तकनीकी दृष्टि से व्यावहारिक हो सकती है। अगर कोई इसे मेरे खिलौना-जैसे PM prototype से ज़्यादा गंभीरता से बनाता है और कहीं ठोस friction point सामने आता है, तो मैं ज़रूर सुनना चाहूँगा। इससे roadmap prioritization में मदद मिलेगी
    [1]: अगर आप coding agents (Cursor, Claude Code आदि) इस्तेमाल करते हैं, तो https://www.npmjs.com/package/built-in-ai-skills-md-agent-md की ओर इशारा करने की सलाह दूँगा। बहुत से models अब पुराने हो चुके window.ai namespace पर train हुए हैं, इसलिए यह skill file उन्हें मौजूदा API सही ढंग से इस्तेमाल करने में मदद करती है

• मैंने इस API design के काम का नेतृत्व किया था, और retirement से पहले इससे जुड़ी design considerations पर एक लेख भी लिखा था
  https://domenic.me/builtin-ai-api-design/

  • अल्पकाल और दीर्घकाल में आप इस API के target use cases को कैसे देखते हैं, यह जानने की जिज्ञासा है
    और यह भी कि ऐसी चीज़ बनाते समय browsers आपस में W3C स्तर पर नहीं, बल्कि व्यावहारिक तौर पर कुछ साझा बिंदुओं पर तालमेल बैठाने की कोशिश करते हैं या नहीं। आखिर यह उद्योग काफ़ी छोटा है
  • retirement की बधाई

• यह सच में काम करता है, और मैं इसे local inference के लिए पहले ही ship कर चुका हूँ
  search जैसी low-end LLM tasks में यह गरीब आदमी के ollama जैसा काम कर सकता था। सबसे बड़ा फायदा यह है कि यह मुफ़्त है, privacy बनाए रखता है, और user को लगभग कुछ भी नहीं करना पड़ता, इसलिए non-technical users तक local inference पहुँचाने के लिए अच्छा है
  लेकिन वास्तविक user experience अच्छा नहीं है। model download का आकार browser से ही कई गुना बड़ा है, और first token मिलने से पहले यह पूरा process खत्म होना पड़ता है
  जब तक operating system स्थिर रूप से pre-baked models उपलब्ध नहीं कराता और ऐसी APIs उनसे जुड़ नहीं पातीं, तब तक इसका समाधान मुश्किल लगता है

  • यह Prompt API इस्तेमाल करने वाली सभी sites के बीच साझा होने वाला one-time download है
    बड़ी समस्या यह है कि ज़्यादातर सामान्य PCs पर model बहुत छोटा और धीमा है। मैंने infocom text adventure के वाक्यों को real time में बदलने की कोशिश की थी, लेकिन अभी कई PCs पर यह इतना धीमा है कि व्यावहारिक नहीं है
  • अगला बड़ा रुझान शायद ऐसा software subscription premium हो सकता है जिसमें कई 5090 लगाकर बेचे जाएँ
  • अगर यह MoE model हो, तो expert layers को ज़रूरत पड़ने पर network से HTTP range query के ज़रिए लाया जा सकता है
    यह कुछ वैसा ही है जैसे bittorrent अलग-अलग hosts से file pieces लाता है। shared layers तो फिर भी डाउनलोड करनी होंगी, लेकिन time-to-first-token को कुल size के बजाय active size के अनुपात में रखा जा सकता है
    बेशक तब यह पूरी तरह offline inference नहीं रहेगा, लेकिन browser web feature के लिए शायद यह निर्णायक चिंता न हो
  • उम्मीद है कि दुनिया ऐसी न बने जहाँ operating system भरोसेमंद तरीके से preinstalled models डालने लगे
  • यह वाकई अच्छा है
    लेकिन अगर model browser से बहुत बड़ा है और first token से पहले डाउनलोड ज़रूरी है, तो क्या इसका मतलब lazy download है? अगर पहली बार call करने वाले users को उसी समय download पूरा होने तक इंतज़ार करना पड़े, तो user experience काफ़ी भयानक लगेगा
    यह भी जानना चाहूँगा कि क्या Chrome confusion कम करने के लिए download status dialog जैसा कुछ दिखाता है, और disk usage लगभग कितना होता है

• ऊपर-ऊपर से तो लगता है कि यह Gemini Nano इस्तेमाल कर रहा है, लेकिन नवीनतम Gemma 4 E2B/E4B कहीं बेहतर दिखते हैं, इसलिए फिलहाल quantized version को extension के रूप में वितरित करना ज़्यादा अच्छा हो सकता है

  • Gemini Nano-1: 46% MMLU, 1.8B
  • Gemini Nano-2: 56% MMLU, 3.25B
  • Gemma4 E2B: 60.0% MMLU, 2.3B
  • Gemma4 E4B: 69.4% MMLU, 4.5B
    स्रोत:
  • https://huggingface.co/google/gemma-4-E2B-it
  • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
  • अभी अंदरूनी स्थिति तो नहीं जानता, लेकिन जब मैं इस टीम में था, तब नवीनतम छोटे Google models को Chrome में बहुत तेज़ी से लाया जाता था
    अगर Gemma 4 या उसके अनुरूप Gemini Nano अभी Chrome में नहीं है, तो मेरा अनुमान है कि जल्द आ जाएगा
    और यह लेख 2025-09-21 को आख़िरी बार अपडेट हुआ था, और उस समय तक यह पहले ही Gemini Nano 3 था
  • हाँ
    इसमें लिखा है कि Prompt API browser के भीतर मौजूद Gemini Nano को natural language requests भेजने का तरीका है
  • Prompt API browser में उपलब्ध model का इस्तेमाल करती है
    Edge में शायद यह Phi4 होगा

• यह कुछ हद तक ऐसा भी लगता है कि कोई दुर्भावनापूर्ण JS script अनजान visitors पर token generation का बोझ डाल सकती है
  यह भी दिलचस्प होगा कि क्या बड़े prompts को छोटे हिस्सों में बाँटकर कई browsers को भेजा जा सकता है, और हर browser सिर्फ छोटा हिस्सा process करे, ताकि subagent pattern या RLM जैसी किसी संरचना से उपयोगी distributed result बन सके

  • मेहनत के मुकाबले फायदा बहुत कम लगता है
    technical और business infrastructure भी बेहद जटिल हो जाएगा, और अगर सच में user browsers पर prompts offload करने हैं, तो शायद सीधे Chrome API का ठीक से इस्तेमाल करना बेहतर होगा। यह भी संदेह है कि ऐसे low-end models पर server-side prompts offload करना वास्तव में कितनी बार सार्थक साबित होगा
    और अगर सच में ऐसा करना हो, तो WebGPU भी काफ़ी समय से मौजूद है
  • छोटे models से token generation की लगभग कोई कीमत नहीं है

• यह एक proper Model API की दिशा में कदम जैसा लगता है, लेकिन अभी बहुत छोटा कदम है
  इससे Apple के Foundation Models भी याद आते हैं
  कई AI integrations text communication या chat style पर केंद्रित हैं, लेकिन वास्तव में बहुत-सा software non-text interfaces में भी लाभ उठा सकता है
  अंततः OS और browser को model-management APIs देनी चाहिए, ताकि apps एक सरल interface के माध्यम से on-device models और remote models तक पहुँच सकें
  अगर यह cross-platform standard बन जाए तो बहुत अच्छा होगा, और इसे mobile तक भी पहुँचना होगा, इसलिए व्यवहारिक रूप से इसे आगे बढ़ाने की सबसे अधिक क्षमता Apple और Google के पास ही लगती है। Meta पीछे से आए या उल्टा पहले कदम उठाए, यह अलग बात है
  मुख्य बात यह है कि यह किसी खास प्रचारित model तक सीमित नहीं होना चाहिए
  apps को query करके उपयुक्त model चुन पाने में सक्षम होना चाहिए
  (1) https://developer.apple.com/documentation/foundationmodels

  • Apple के Foundation Models कागज़ पर अच्छे लगते हैं, लेकिन असल में देखें तो 4k context window अटकाती है
    बेशक अभी यह शुरुआती दौर में है

• https://github.com/mozilla/standards-positions/issues/1067

  • यह भी साथ में देखने लायक है: https://github.com/mozilla/standards-positions/issues/1213

• हम इसे Hackday retrospective summary के लिए इस्तेमाल कर रहे हैं
  https://remotehack.space/previous-hacks/
  यह एक छोटा script है जो RSS feed पढ़कर body text से summary बनाता है, और static site के साथ काफ़ी अच्छी तरह फिट बैठता है। कभी आगे चलकर मैं इसे बढ़ाकर उसी content पर अलग-अलग सवाल पूछने लायक बनाना चाहूँगा

• browser से accessible local LLM privacy के लिहाज़ से अच्छा है, लेकिन अगर हर browser इस API के पीछे अलग model लगाता है, तो testing nightmare अभी से भी बदतर हो सकता है
  आखिरकार ज़्यादातर implementations शायद Gemini Nano को ध्यान में रखकर बनेंगी, तो यह भी सोचने वाली बात है कि क्या इससे users और ज़्यादा Chrome की ओर खिंचेंगे

  • testing fragmentation ही असली समस्या है
    व्यवहार में prompts model-agnostic नहीं होते, इसलिए Gemini Nano 3 v2025 के लिए बारीकी से tune किया गया prompt, Gecko पक्ष के model पर चुपचाप खराब प्रदर्शन दे सकता है। लेकिन API तो branching के लिए capability detection तक नहीं देती
    यह WebGL से भी बदतर है, जहाँ कम-से-कम extension support query किया जा सकता था। किसी feature को ऐसे ship करना कि वह browser के पीछे छिपे model की prompt quality पर निर्भर हो, जबकि उसका नाम और version भी न पता हो, वैसा है जैसे ऐसा software जारी करना जिसकी functionality user द्वारा इंस्टॉल किए गए dictionary पर निर्भर करती हो

• मुझे लगता है Gemini Nano के weights, Gemma के विपरीत, open नहीं हैं
  अगर किसी ने पहले से नहीं किया है, तो मैं model weights dump करके देखना चाहूँगा