Apple Foundation Models में Claude जोड़ना

 (platform.claude.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple के Foundation Models framework में Claude को server-side model के रूप में जोड़ने वाला Swift package, जिससे डेवलपर्स Apple on-device model के ठीक उसी code path से Claude को कॉल कर सकते हैं
  • WWDC 2026 में Apple द्वारा पेश किए गए LanguageModel protocol की बदौलत, on-device model पर prototyping करने के बाद केवल जटिल कामों को cloud model तक भेजने वाली hybrid संरचना अब एक ही standard API से संभव हो गई है
  • इसकी सबसे अहम बात है provider को बदल पाने की क्षमता — session logic को छुए बिना सिर्फ Swift Package dependency बदलकर Apple·Claude·Gemini के बीच स्विच किया जा सकता है
  • Anthropic ने Apache 2.0 के तहत जारी किया गया यह package उस विचार का पहला वास्तविक काम करने वाला उदाहरण है कि "किसी भी backend को जोड़ा जा सकता है"
  • requests सीधे app से Claude API तक जाती हैं और Apple इस रास्ते में शामिल नहीं है, इसलिए वह prompt या response नहीं देख सकता, और लागत भी सीधे Anthropic account पर बिल होती है

यह क्यों महत्वपूर्ण है

  • iOS apps में language model जोड़ने के लिए अब तक अलग cloud API signup, key management, per-token billing, और हर prompt को device के बाहर भेजना जरूरी था, लेकिन WWDC 2026 में Apple ने इस लंबे समय की असुविधा को हल किया
  • Foundation Models framework को इस तरह विस्तारित किया गया है कि Apple Intelligence के on-device model, Private Cloud Compute, और Claude·Gemini जैसे third-party cloud — सभी को एक ही native Swift API से कॉल किया जा सके
  • Anthropic ने इस नए protocol को implement करने वाला Swift package जारी किया है। इसका उपयोग Claude को Apple on-device model से handoff करके ज़्यादा जटिल workflows संभालने के लिए कॉल करने में होता है

डेवलपर्स के लिए क्या बदलता है

  • code बदले बिना provider switching

    • Apple on-device model पर app का prototype बनाने के बाद, जटिल queries को Google Gemini या Anthropic Claude की ओर route करना या उनके बीच switch करना अब सिर्फ Swift Package Manager dependency अपडेट करके किया जा सकता है, बिना session logic या बाकी app code बदले
    • on-device model तेज़ और local tasks जैसे summarization·extraction के लिए, और multi-step reasoning·code generation·web search·code execution की ज़रूरत पड़ने पर ही Claude को handoff
    • दोनों ही मामलों में वही LanguageModelSession API इस्तेमाल होती है, इसलिए सिर्फ model: argument बदलकर switch किया जा सकता है

  • type-आधारित handoff

    • इसे project में जोड़ने और Anthropic API key से login करने के बाद, Apple on-device model के typed output को Claude request में पास किया जा सकता है, और package streaming·tool calling·structured responses को फिर से SwiftUI view में संभाल लेता है
    • guide generation के ज़रिए सिर्फ तीन lines of code में typed Swift values लौटाने जितना इसका उपयोग आसान है

privacy और cost संरचना

  • requests सीधे app से Claude API तक भेजी जाती हैं, इसलिए Apple request path में नहीं होता और prompt या response नहीं देखता
  • usage का बिल standard API pricing के अनुसार सीधे Anthropic account पर किया जाता है
  • app हर session के लिए खुद तय कर सकती है कि Claude इस्तेमाल करना है या Apple on-device model

बड़ा परिदृश्य

  • Apple ने 2025 में जारी किए गए on-device models के native Swift API, Foundation Models framework, को इस गर्मियों में open source करने की योजना बनाई है, और नए LanguageModel protocol के साथ Apple के अपने models हों या remote providers, लगभग सभी models एक single Swift API के पीछे LanguageModelSession चला सकते हैं
  • "किसी भी backend को जोड़ा जा सकता है" के उदाहरण के रूप में Anthropic का ClaudeForFoundationModels adapter pattern को ठोस रूप देता है
  • Apple, Dynamic Profiles system के ज़रिए apps को session के बीच model·tool·instructions बदलने की अनुमति देता है, और इसे multi-agent workflows की नींव के रूप में पेश कर रहा है
  • हालांकि, यह integration अभी beta चरण में है और iOS·iPadOS·macOS·visionOS·watchOS 27 तथा Xcode 27 की आवश्यकता रखता है, इसलिए औपचारिक रिलीज़ से पहले API बदल सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • Apple user experience पर नियंत्रण रखते हुए LLM को commodity बना रहा है
    एक hardware कंपनी के तौर पर यह रणनीति लगती है कि AI इस्तेमाल करने के लिए सबसे अच्छी मशीनें वही बेचता रहे, और यह सही फैसला लगता है

    • हो सकता है Benedict Evans आख़िरकार सही रहे हों। frontier models धीरे-धीरे 90 के दशक की telecom कंपनियों जैसे दिख रहे हैं
      वे infrastructure में अरबों डॉलर लगाते हैं, लेकिन value ऊपर की layers में मौजूद दूसरी कंपनियाँ ले जाती हैं
    • यह बात user experience control वाली बात से थोड़ी अलग है, लेकिन AI का यह नतीजा मुझे सबसे ज़्यादा पसंद है। दशकों तक कंपनियों ने अपनी services को दीवारों से घेरकर रखा और घटिया UI थोपे, लेकिन पिछले 12 महीनों में अचानक हर चीज़ के लिए MCP आ गया और उन्हें command-line chat interface से इस्तेमाल किया जा सकता है
      जो कंपनियाँ adapt नहीं करेंगी, वे लोगों द्वारा बनाए गए AI-आधारित DIY web scrapers से पिटती रहेंगी और आख़िरकार झुकना पड़ेगा
    • यहाँ AI इस्तेमाल करने के लिए सबसे अच्छी मशीन कहना सही है या नहीं, पता नहीं। ये models अभी भी server side पर ही नहीं चलते क्या
    • यह कई सालों से साफ़ था कि AI आख़िरकार operating system level पर embed होगा। Apple भी जब Apple Intelligence पहली बार लाया था, तब यह बात समझ रहा था
      LLM को commodity बनाना जैसी बात सही हो सकती है, लेकिन यह तो कई सालों से निखारी जा रही user-facing functionality है
    • अब बस hardware को भी commodity बनाना बाकी है

  • Apple's Foundation Models framework में Claude को server-side language model की तरह इस्तेमाल करने देने वाला Swift package है, जबकि मैं उलटी दिशा की उम्मीद कर रहा था। मैं चाहता था कि Claude Code की मौजूदा capabilities somehow मेरे laptop के Neural Engine पर locally चलें
    M2 और 8GB RAM के साथ यह बेकार सपना है, लेकिन एक पल के लिए उम्मीद जगी थी

    • यह WWDC session देखिए। जाहिर है यह frontier models से compete नहीं करेगा और 8GB भी बहुत कम है, लेकिन Apple ने MLX + OpenCode का demo दिया था
      https://developer.apple.com/videos/play/wwdc2026/232/
      https://www.youtube.com/watch?v=wykPErJ8M-8
    • अगर OpenCode या Pi को SSD streaming के साथ इस्तेमाल किया जाए, तो तकनीकी रूप से सारी functionality मिल सकती है। बस यह असहनीय रूप से धीमा होगा
    • ज़्यादातर frontier coding models को अपनी पूरी क्षमता में इस्तेमाल करने के लिए शायद 300GB से 1TB तक चाहिए होता है
    • Claude Code को environment variables के ज़रिए literally किसी भी endpoint पर query करने के लिए सेट किया जा सकता है, बस compatible API होना चाहिए
    • अगर cloud वास्तव में user का private iCloud हो, तो यह ठीक लग सकता है। अगर user पैसे दे और यह उन Apple servers के पास चले जहाँ पहले से iPhotos stored हैं, तो यह बहुत elegant हल हो सकता है
      लेकिन असल में आपको Claude मिलता है, जो कहाँ host हो रहा है यह भी पता नहीं। वह X-AI data center में हो सकता है, Amazon के कहीं हो सकता है, किसी को नहीं पता

  • यह सिर्फ Claude के लिए नहीं है। developers Google के server-based Gemini models को call करने वाले apps भी बना सकते हैं
    WWDC में Apple ने घोषणा की कि वह Foundation Models framework को third-party cloud model providers के लिए खोलेगा। iOS 27, macOS 27, iPadOS 27, visionOS 27, watchOS 27 से model providers नया public LanguageModel protocol implement करके model inference के लिए common interface दे सकेंगे। Google ने Firebase Apple SDK के ज़रिए Gemini models को Foundation Models framework में इस्तेमाल करने योग्य बना दिया है
    इससे पूरी तरह native development experience संभव हो जाता है। cloud-hosted Gemini models उसी API के ज़रिए सीधे Foundation Models framework से जुड़ सकते हैं, और on-device Apple models तथा cloud-hosted Gemini models एक common API surface के पीछे रखे जा सकते हैं, इसलिए use case के हिसाब से local inference और cloud inference के बीच आसानी से स्विच किया जा सकता है
    https://blog.google/innovation-and-ai/technology/developers-...

    • असली बात यह है कि Apple ने OpenAI-compatible API का नाम बदलकर language model protocol रख दिया है, और उस भयानक लंबे नाम से सबके शापित होने से पहले हम सबको जल्दी से इसी तरफ़ एकजुट हो जाना चाहिए

  • Apple ने इस तरह का abstraction पेश किया, यह अच्छी बात है, लेकिन मेरी मुख्य चिंता local model को लेकर है
    उदाहरण के लिए, मान लें कि आप Gemma4 इस्तेमाल करना चाहते हैं। यूज़र के नज़रिए से अगर 10 ऐप्स एक ही मॉडल को अलग-अलग डाउनलोड करें, तो फ़ोन बेवजह फूला हुआ हो जाएगा
    अभी तक मैं यह नहीं समझ पाया हूँ कि क्या Apple ने ऐसा कोई तरीका दिया है जिससे कई ऐप्स एक ही डिवाइस-आधारित मॉडल को इस्तेमाल कर सकें। यह किसी पेचीदा namespace या permission वाली चालबाज़ी के बिना संभव होना चाहिए
    मुझे ऐसा संकेत देने वाली कोई बात नहीं दिखी

    • मेरा मानना है कि Apple ठीक इसी चीज़ से बचना चाहता है। अगर on-device intelligence चाहिए, तो उनका सुझाव यही है कि “जो मॉडल पहले से डिवाइस में है वही सबसे अच्छा है”, और अगर कुछ ज़्यादा specific चाहिए तो adapter, यानी fine-tuning/LoRA, सबसे अच्छा रास्ता है
      जब on-device model काफ़ी पीछे था तब यह ग़लत था, लेकिन लंबी अवधि में यह अब भी सही हो सकता है
      जिन कई ऐप्स का मैं इस्तेमाल करता हूँ उन्हें Gemma 4 E4B चाहिए हो सकता है, लेकिन मैं दर्जनों ऐप्स इस्तेमाल करता हूँ और डेवलपर्स सैकड़ों मॉडलों में से चुन सकते हैं। shared cache में overlap होने पर थोड़ा storage बच सकता है, लेकिन मूल समस्या बनी रहती है। अगर हर ऐप अपना मॉडल चुने, तो disk और memory swapping बेकाबू हो जाएगी
      यह ज़्यादा बेहतर हो सकता है कि डिवाइस निर्माता एक default पहले से embed करे। बात दूसरे मॉडल रोकने की नहीं है, लेकिन एक shared default शायद 99% ऐप्स के लिए डेवलपर और यूज़र अनुभव, दोनों के लिहाज़ से सबसे अच्छा हो
      जो चीज़ पहले से memory में loaded है, वही सबसे बड़ा performance boost देती है, और default model के warm बने रहने की संभावना कहीं ज़्यादा है
      “सबसे अच्छा model” आम तौर पर RAM और compute को ध्यान में रखते हुए “इस डिवाइस के लिए सबसे अच्छा model” होता है। डेवलपर हर डिवाइस को test नहीं कर सकते, लेकिन Apple कर सकता है और करेगा
      हर model को hardware के हिसाब से optimize किया जाना चाहिए। ANE, Metal, CPU में से कहाँ क्या चल रहा है, यह मायने रखता है, और default model optimize किया हुआ होगा
      अगर custom model चाहिए, तो शायद LoRA सबसे अच्छा विकल्प है। यह लगभग 30MB का होता है और ऊपर बताए गए सारे फ़ायदे देता है
      आप कह सकते हैं कि default को replace करने लायक बनाना चाहिए, लेकिन वह Apple से ज़्यादा Linux जैसी सोच है, इसलिए यह वास्तव में देखने को मिलेगा या नहीं, कहना मुश्किल है। ऊपर से इसके असली नुकसान भी हैं। चाहे जानबूझकर हो या नहीं, prompt आम तौर पर target model के हिसाब से optimize किए जाते हैं, इसलिए अगर default system model बदल दिया जाए, तो सभी ऐप्स की quality खराब हो सकती है
    • यह Apple के लिए universal unique model ID protocol और shared storage देने का अच्छा मौका है, ताकि डेवलपर्स मॉडल register कर सकें
    • “Bring an LLM provider to the Foundation Models framework” देखें
      https://developer.apple.com/videos/play/wwdc2026/339
    • ऐप्स एक ही framework और API के ज़रिए system द्वारा दिए गए on-device model का इस्तेमाल कर सकते हैं। लेकिन ऐप्स के बीच custom model duplication हटाने का कोई तंत्र नहीं है
    • वही तो foundation models है। Android का AICore भी इसी तरह अंदर से Gemma इस्तेमाल करता है, और ऐप्स अपने मॉडल bundle करने के बजाय LLM से query करके response लेते हैं

  • मुझे लगता है Apple डेवलपर्स को अपने API abstraction layer के ज़रिए LLM इस्तेमाल करने के लिए प्रेरित कर रहा है। हो सकता है कि बाद में जब वह अपना LLM जारी करे, तो डेवलपर्स आसानी से उस पर switch कर सकें
    मुझे लगता है मैंने सुना है कि Apple training पर बहुत पैसा ख़र्च कर रहा है और इसका Siri या मौजूदा Apple AI से somehow संबंध हो सकता है। या फिर यह सिर्फ़ डेवलपर सुविधा के लिए है, या इसके पीछे कोई और इरादा है, यह जानने की उत्सुकता है

    • यूज़र डेटा की सुरक्षा के लिए Apple के पास कुछ काफ़ी चतुर इंतज़ाम हैं। हाल ही में मुझे app tracking से जुड़ा काम करना पड़ा, और third-party platform को tracking events report करने से पहले SKAN और differential privacy के ज़रिए anonymized cohort के भीतर यूज़र डिटेल्स छिपाने का जो तरीका था, वह उम्मीद से बेहतर डिज़ाइन किया गया लगा
      अगर आप privacy को अहम मानते हैं, तो बीच में Apple का होना क़ीमती है
    • यह reality/mac/iPad/watch/tv/iOS 27 में शामिल होने वाले नए framework support के बारे में है। उन्होंने कहा है कि इसे इस साल के अंत में open source किया जाएगा, इसलिए अगर आप backend पर Swift deploy करते हैं, तो वहाँ भी इसका उपयोग संभव दिखता है
      इस framework की खास बात यह है कि एक ही API से on-device built-in model, Apple-hosted online model Private Cloud Computer, या किसी मनचाहे hosted online model को कॉल करने वाले अपने shim—इन सबको target किया जा सकता है
      इससे “यह local model से करना है, वह Claude से” जैसी अपनी abstraction layer बनाने या Anthropic/OpenAI API integration सीधे जोड़ने की ज़रूरत नहीं रहती, बल्कि system API के साथ calls को अलग-अलग model/provider प्रकारों की ओर dynamically route किया जा सकता है
      tool calling जैसी चीज़ों को एक जगह abstract करना, और session के दौरान provider या model को dynamically बदलने पर भी वही transcript जारी रखना—ऐसी कई सुविधाएँ और दिलचस्प बारीकियाँ हैं
    • निंदक नज़रिए से, या कहें वास्तविक रूप से, यह abstraction layer Apple का ऐसा तरीका लग सकती है जिसमें असली LLM कोई दूसरी कंपनी दे रही हो, फिर भी यूज़र उस क्षमता का श्रेय Apple Intelligence को दें
    • यह थोड़ा अँधेरा interpretation है, लेकिन पूरी तरह ग़लत भी नहीं। इससे Apple के लिए दूसरी कंपनियों के दिए मॉडल पर payment लेना आसान हो सकता है, और अगर वह चाहे तो यूज़र third-party model कैसे इस्तेमाल करते हैं, उससे डेटा इकट्ठा करके अपने मॉडल training के लिए dataset भी बना सकता है
      क्योंकि यह API सिर्फ़ Apple devices पर ही इस्तेमाल होगी, इसलिए iOS पर ठीक से काम कराने के लिए डेवलपर्स को यही सिस्टम अपनाना पड़ेगा, जिससे बाज़ार और बँट सकता है और यूज़र्स को और मज़बूती से बाँधकर रखा जा सकता है
    • इस framework के ज़रिए डेवलपर्स के लिए पहले से इस्तेमाल करने लायक on-device model मौजूद है। Claude बस उसमें जुड़ने वाला एक अतिरिक्त model है

  • ऐसा लगता है कि Apple इस संभावना के लिए तैयारी कर रहा है कि उसके अपने on-device models बेहतर हो जाएंगे, और यह सोचें तो बात समझ में आती है कि Gemini तक पहुंच मिल चुकी है
    अगर डेवलपर्स बाहरी LLM calls का सारा कोड इसी से लिखें, तो जब Apple models ज्यादा सक्षम हो जाएं और ज्यादा use cases कवर करने लगें, तब हर अलग call site पर आसानी से बदलाव किया जा सकेगा। इससे app user experience बेहतर होगा, और डेवलपर billing cost भी घटेगी जिस पर Apple कोई fee नहीं ले पाता

    • दूसरे शब्दों में, इससे पैसा नहीं बनेगा, इसलिए इसके होने की संभावना कम है। Apple के लिए बेहतर यह होगा कि वह नए AI और AI-lite plans बनाए जिनकी लोग subscription ले सकें
      Apple एक कंपनी है, और हम सब जानते हैं कि कंपनियां किस बात की परवाह करती हैं, इसलिए यह संभावना कम लगती है कि हम किसी ऐसे यूटोपिया में पहुंचेंगे जहां phone पर local models चलें
    • समझ नहीं आ रहा कि Gemini इस्तेमाल करने से on-device models कैसे बेहतर हो जाएंगे
    • user experience ecosystem बनाने का ही दूसरा नाम है, और यही काम Apple अपने competitors से सबसे बेहतर करता है। उसके साथ matching hardware होना भी नुकसान की बात नहीं है
      Microsoft और Nvidia यूं ही साथ नहीं आए हैं

  • जिज्ञासा है कि इसे वास्तव में उस software में कैसे इस्तेमाल किया जाएगा जिसे users तक ship किया जाना है। users से सीधे API key बनवाकर उसे enter करने को कहना, अच्छे user experience के लिए बहुत बड़ी रुकावट है

    • इससे भी बड़ी रुकावट यह है कि आम users, यानी non-developers, को token-based pricing समझाना और स्वीकार करवाना
      “एक सवाल पर कितना खर्च आएगा, यह पता नहीं; पैसे देने के बाद भी मनचाहा जवाब न मिले; और ज्यादा इस्तेमाल करना हो तो और पैसे दो” — यह ढांचा जुआरी न होने वाले ज्यादातर लोगों को आकर्षक नहीं लगेगा। लंबी बातचीत के अंत में एक “thanks” भी context की वजह से महंगा पड़ सकता है, यह बात औसत user को समझाना और भी मुश्किल है
      token cost का yo-yo की तरह ऊपर-नीचे होना भी मदद नहीं करता। आम users को fixed cost चाहिए, और वे AI की बदलती दुनिया को लगातार track करने में अपनी energy खर्च नहीं करना चाहते। “पिछले महीने मेरा subscription इससे कहीं ज्यादा चला था” जैसी समस्याएं भी अच्छी दिशा नहीं हैं
      ज्यादातर मामलों में Apple का यह आकलन सही लगता है कि local LLM ही भविष्य है
    • बिल्कुल सही। मैं allihat.com चला रहा हूं, और लगता है कि यह अब भी Claude से बात करने वाला इकलौता Safari extension है, और इसकी demand भी ठीक-ठाक है। लेकिन users को खुद अपनी कमबख्त Claude API key डालनी पड़ती है
      Anthropic की terms भी अब तक पूरी तरह समझ नहीं आई हैं। setup-token Set up a long-lived authentication token (requires Claude subscription) जैसी चीज़ input की जा सकती है, लेकिन यह किसी trap जैसा लगता है। पता नहीं कौन इसका इस्तेमाल करता है, और यह भी लगता है कि इसे कहीं भी इस्तेमाल करो तो तुरंत terms violation हो जाएगी
      अभी allihat.com पर अगर कोई Claude key इस्तेमाल नहीं करना चाहता, तो हम उसे local Apple model इस्तेमाल करने देते हैं, और paid users में conversion rate करीब 3 गुना बढ़ गया है। लेकिन जाहिर है कि यह Claude का विकल्प नहीं है। उम्मीद थी कि Apple कोई ऐसा इंतजाम करेगा जिससे Claude proxying वही संभाल ले। यानी Claude API usage manage करने के लिए मुझे अपने server से proxy न करना पड़े
    • production में requests को .proxied के जरिए अपने backend से route करने के लिए कहा गया है
      Apple 20 लाख से कम downloads वाले डेवलपर्स को अपने servers के जरिए मुफ्त AI models दे रहा है https://techcrunch.com/2026/06/08/apple-bets-cheaper-ai-will...
    • पहले की तरह ही, requests को अपने backend से proxy कर दो
    • user API key नहीं देता। docs में backend proxy सेट करने का तरीका दिया हुआ है

  • यह बात समझ में आती है कि “requests app से सीधे Claude API तक जाती हैं, Apple request path में नहीं है, और prompts या responses नहीं देखता” — यह पंक्ति डेवलपर के नजरिए से लिखी गई है
    लेकिन consumer के नजरिए से यह बस हास्यास्पद लगती है

    • क्यों?

  • Microsoft ने सबसे पहले Copilot terms में यह डालकर खेल खराब कर दिया कि “Copilot केवल मनोरंजन उद्देश्यों के लिए उपलब्ध कराया जाता है”, और Excel के Copilot में भी यह चेतावनी डाल दी कि “जिन कामों में accuracy या reproducibility चाहिए, या जिन पर legal, regulatory, या compliance असर हो, उनमें COPILOT के इस्तेमाल से बचें”
    इसके बाद Apple प्रतिस्पर्धी LLM बनाने के लिए अरबों से लेकर सैकड़ों अरब डॉलर झोंकने के बजाय चुपचाप इसमें पूरी तरह शामिल होने से इनकार करता दिख रहा है। हां, भोले लोगों के लिए वह Claude को resell कर सकता है या Gemini का इस्तेमाल कर सकता है, लेकिन Apple स्थिति को समझता है
    https://www.microsoft.com/en-us/microsoft-copilot/for-indivi...
    https://support.microsoft.com/en-US/Excel/copilot-function

  • coding agents खुद ही पहले से एक जबरन चढ़ाई गई layer हैं, तो अब क्या हम एक और layer जोड़ रहे हैं? coding agents कई बार 90 के दशक की staffing agencies के vendor managers जैसे लगते हैं
    वे ग्राहक से आसमान के नीचे सब कुछ वादा कर देते हैं, और फिर बेचारे contractor को डिलीवरी के लिए धकियाते हैं। coding agents tokens भी वैसे ही 10 गुना ज्यादा खा जाते हैं जैसे staffing agency ग्राहक से जितना बिल करती है और contractor को जितना देती है, उसके बीच का अंतर। एक आसान test में, coding agent के जरिए वही काम context length पार कर जाता है, जबकि model को सीधे prompt करो तो ठीक चलता है
    layers एक विलासिता हैं, और वे control और transparency दोनों खत्म कर देती हैं

    • coding agent बनाते समय मैं इसका इस्तेमाल नहीं करूंगा