MSO फाउंडेशन्स

स्क्रीन 1: अंत तक आप क्या कर सकेंगे

मॉड्यूल 1 ओरिएंटेशन · 2 मिनट अंत तक आप क्या कर सकेंगे

Claude के विरुद्ध कोड की एक पंक्ति लिखने से पहले, यह जानना मददगार है कि शब्दों का क्या अर्थ है।

यह मॉड्यूल मॉडल फाउंडेशन्स और तकनीकी आधार का परिचय देता है जो बाकी डेवलपर कोर्स मानता है कि आप पहले से जानते हैं।

इस मॉड्यूल के अंत तक, आप सक्षम होंगे: 1 समझाएं कि token क्या है, context window कैसे एक निश्चित बजट के रूप में काम करता है, sampling आउटपुट को क्यों भिन्न बनाता है, और non-determinism का परीक्षण और evals के लिए क्या अर्थ है। 2 Claude मॉडल परिवार और इसके क्षमता स्तरों का वर्णन करें, और एक मॉडल चुनने को extended thinking जैसे reasoning mode को सक्षम करने से अलग करें। 3 zero-shot, one-shot, और multi-shot prompting के बीच चुनें, और उदाहरण जोड़ने के लागत और गुणवत्ता व्यापार-बंद को तौलें। 4 वर्णन करें कि एक डेवलपर Claude तक कैसे पहुंचता है: SDK बनाम raw REST, synchronous बनाम streaming responses, और उच्च-मात्रा कार्य के लिए asynchronous पैटर्न। अस्वीकरण / शैक्षणिक सामग्री के लिए नोटिस

हमने यह डेवलपर कोर्स मॉड्यूल 1: MSO फाउंडेशन्स Claude के साथ वास्तविक कार्य करने में आपकी मदद करने के लिए बनाया है। इसे शैक्षणिक सामग्री के रूप में मानें। यह कानूनी, वित्तीय, या अन्य व्यावसायिक सलाह का गठन नहीं करता है, इसलिए जो आप सीखते हैं उसे अपनी स्थिति के अनुसार अनुकूलित करें। हमारे उत्पाद और सेवाएं तेजी से विकसित होती हैं, इसलिए कुछ सामग्री में त्रुटियां हो सकती हैं या पुरानी हो सकती हैं; Anthropic की वेबसाइट या दस्तावेज़ों पर सत्यापित करना याद रखें। कोर्स में उपयोग किए गए उदाहरण और परिदृश्य चित्रात्मक हैं और अक्सर काल्पनिक हैं। यदि कोर्स सामग्री किसी कंपनी या उत्पाद का उल्लेख करती है, तो इसका मतलब यह नहीं है कि Anthropic उनका समर्थन करता है, वे Anthropic का समर्थन करते हैं, या कि हम संबद्ध हैं। यह भी ध्यान दें कि Anthropic उत्पादों और सेवाओं का आपका उपयोग हमारी शर्तों, नीतियों और दस्तावेज़ों द्वारा कवर किया गया है; यदि इस कोर्स में कुछ उनके साथ विरोध करता है, तो वे नियंत्रण करते हैं।

स्क्रीन 2: LLM कैसे व्यवहार करते हैं: tokens, context, sampling, non-determinism

शिक्षणLLM व्यवहार कैसे करते हैं·12 मिनट LLM कैसे व्यवहार करते हैं: tokens, context, sampling, non-determinism

Tokens Context Window Sampling Non-determinism

Tokens: इनपुट, आउटपुट, और लागत की इकाई Claude सीधे वर्णों या शब्दों को नहीं पढ़ता है। यह tokens को पढ़ता है, और प्रति-token वर्ण औसत प्रश्न में मॉडल के tokenizer पर निर्भर करता है और मॉडल पीढ़ियों के बीच भिन्न होता है। किसी भी chars-per-token नियम को मॉडल-निर्भर के रूप में मानें और build time पर वर्तमान tokenizer व्यवहार की पुष्टि करें। मॉडल जो कुछ भी प्रक्रिया करता है वह tokens में गिना जाता है: आपका prompt, बातचीत का इतिहास, tool परिभाषाएं, tool परिणाम, और मॉडल द्वारा उत्पन्न प्रतिक्रिया। Tokens मूल्य निर्धारण और बजट दोनों की इकाई हैं, इसलिए जब आप अनुमान लगाते हैं कि एक सुविधा की लागत क्या है या क्या कोई इनपुट फिट बैठता है, तो आप शब्दों के बजाय tokens गिन रहे हैं। एक उपयोगी आदत tokens में सोचना है, क्योंकि यह वह इकाई है जिसमें API बिल करता है और context window मापता है।

Context window: एक निश्चित बजट Context window कुल tokens की संख्या है जो मॉडल एक एकल request के लिए ले सकता है। यह सब कुछ एक साथ रखता है: system prompt, अब तक की पूरी बातचीत, कोई भी दस्तावेज़ जो आप इंजेक्ट करते हैं, हर tool परिणाम, और मॉडल आउटपुट। यह दो अलग-अलग edge behaviors के साथ एक निश्चित बजट है। एक request जिसका इनपुट पहले से ही window से बड़ा है, generation शुरू होने से पहले एक validation error के साथ अस्वीकार कर दिया जाता है। एक request जो इनपुट पर फिट बैठता है फिर भी generation के दौरान ceiling तक पहुंच सकता है। वर्तमान मॉडल तब रुक जाते हैं और अब तक उत्पन्न आउटपुट को एक model_context_window_exceeded stop reason के साथ लौटाते हैं बजाय एक error उठाने के। किसी भी तरह से, एक लंबे session को चलाते रहने के लिए application को प्रत्येक call से पहले history को trim या summarize करने की आवश्यकता होती है। Development में, window शायद ही कभी भरता है क्योंकि test inputs छोटे होते हैं। Production में, दूसरी ओर, लंबे inputs और अधिक turns window को तेजी से भरते हैं। यह failure है जो Module 2 विस्तार से explores करता है।

Sampling: समान prompt अलग-अलग उत्तर क्यों दे सकता है एक language model एक निश्चित अगला token नहीं चुनता है। प्रत्येक step पर यह संभावित अगले tokens पर एक probability distribution उत्पन्न करता है और फिर इससे samples करता है। Settings, जैसे temperature, उस distribution को shape करती हैं: एक lower temperature सबसे संभावित tokens पर probability को concentrate करता है और आउटपुट को अधिक repeatable बनाता है, जबकि एक higher temperature इसे spread करता है और आउटपुट को अधिक varied बनाता है। क्योंकि choice sampled है fixed नहीं, समान prompt को दो बार चलाने से दोनों उत्तर सही होने पर भी अलग-अलग wording return हो सकता है। यह मॉडल कैसे generate करता है इसकी एक संपत्ति है। ध्यान दें कि sampling controls मॉडल-निर्भर हैं: newest Claude models non-default sampling parameters स्वीकार नहीं करते हैं। Temperature, top_p, या top_k सेट करने से एक 400 error return होता है, और उन मॉडलों पर behavior को prompting के माध्यम से steer किया जाता है। यहां तक कि जहां temperature स्वीकार किया जाता है, temperature 0 आउटपुट को अधिक repeatable बनाता है लेकिन calls के पार identical outputs की गारंटी नहीं देता है। Build time पर API reference में वर्तमान parameter support की पुष्टि करें।

Non-determinism: परीक्षण और evals के लिए इसका क्या अर्थ है Non-determinism sampling का प्राथमिक परिणाम है: identical inputs identical outputs की गारंटी नहीं देते हैं। यह Claude feature को परीक्षण करने के तरीके को बदलता है। एक test जो response के exact text को assert करता है वह असंगत होगा, क्योंकि मॉडल एक ही सही उत्तर को कई तरीकों से व्यक्त कर सकता है। इसके बजाय, उस property को assert करें जो hold करना चाहिए: एक required field मौजूद है, एक value range में है, structure parse करता है। जब आपको meaning के बजाय structure को judge करने की आवश्यकता हो, तो एक model-graded judge के साथ एक eval का उपयोग करें। यह है कि क्यों कोर्स evals को एक feature सही है यह जानने के लिए standard के रूप में मानता है, और क्यों Module 3 उस capability को build करता है।

स्क्रीन 3: मॉडल विकल्प और reasoning modes

शिक्षणModels & Reasoning·10 मिनट मॉडल विकल्प और reasoning modes

मॉडल परिवार Reasoning Modes वे कैसे एक साथ काम करते हैं

Claude मॉडल परिवार Claude एक मॉडल परिवार है जो वर्तमान में चार स्तरों तक फैला है: Fable, Opus, Sonnet, और Haiku। प्रत्येक मॉडल लागत, latency, और capability के पार एक अलग tradeoff का प्रतिनिधित्व करता है। Sonnet अधिकांश production workloads के लिए संतुलित default है। Haiku उन tasks के लिए speed और cost efficiency के लिए बनाया गया है जो इसकी capability envelope में फिट होते हैं। Opus Sonnet envelope के ऊपर demanding work को संभालता है, और Fable सबसे capable tier है, सबसे demanding reasoning, coding, और agentic work के लिए बनाया गया है जहां maximum intelligence प्राथमिकता है। व्यावहारिक default Sonnet के साथ शुरू करना है, केवल तब एक tier ऊपर जाएं जब एक eval दिखाता है कि वर्तमान tier आपकी quality bar को miss कर रहा है, और केवल तब Haiku में जाएं जब एक eval दिखाता है कि quality drop task के लिए स्वीकार्य है। Build time पर platform. claude. com/docs के विरुद्ध वर्तमान मॉडल lineup और identifiers की पुष्टि करें, क्योंकि Claude परिवार विकसित हो रहा है।

Reasoning modes मॉडल choice से एक अलग setting है कौन सा मॉडल चलाना है यह एक निर्णय है। क्या मॉडल उत्तर देने से पहले reason करता है यह एक अलग निर्णय है जो आप प्रति call करते हैं। वर्तमान मॉडलों पर reasoning mode adaptive thinking है: मॉडल तय करता है कि कब और कितना सोचना है, और आप एक fixed token budget के बजाय एक effort setting के साथ depth को tune करते हैं (पुराना budget_tokens control deprecated है और, newest model generations पर, एक 400 error return करता है)। Thinking content newest models पर responses से default रूप से omitted है। जब आपको इसे दिखाने की आवश्यकता हो तो summarized display request करें। Reasoning hard, multi-step problems पर अपनी लागत अर्जित करता है और lookups और classification पर बर्बाद होता है। इस मॉड्यूल के लिए मुख्य बात यह है कि दोनों levers compose करते हैं: मॉडल choice परिवार के सदस्य को pick करता है, जबकि reasoning mode प्रति request configured है। Per-model defaults भिन्न होते हैं (कुछ newest models adaptively think करते हैं default रूप से या हमेशा), इसलिए build time पर अपने मॉडल के लिए वर्तमान thinking defaults की पुष्टि करें।

दोनों कैसे एक साथ काम करते हैं क्योंकि मॉडल choice और reasoning mode independent हैं, प्रत्येक को अलग से set किया जा सकता है। एक capable मॉडल reasoning off के साथ fast और direct है, जबकि एक smaller मॉडल reasoning on के साथ सोचने के लिए अधिक tokens खर्च करता है। सबसे demanding tasks एक capable मॉडल को एक higher effort setting के साथ pair करते हैं। Module 2 reasoning को enable करने और इसे return करने वाले thinking blocks को handle करने की mechanics सिखाता है। कौन सा मॉडल चलाना है यह निर्णय, लागत, latency, और quality के विरुद्ध तौला जाता है, Module 4 में लिया जाता है।

स्क्रीन 4: Prompting modes: zero-shot, one-shot, multi-shot

शिक्षणPrompting Modes·8 मिनट Prompting modes: zero-shot, one-shot, multi-shot

तीन Modes लागत & गुणवत्ता व्यापार-बंद Mode & मॉडल Choice

तीन modes आप एक prompt को कैसे word करते हैं इससे अलग है कि आप मॉडल को इसके अंदर कितने worked examples देते हैं। Zero-shot instruction देता है और कोई उदाहरण नहीं: आप task का वर्णन करते हैं और result के लिए पूछते हैं। One-shot एक उदाहरण जोड़ता है input paired के साथ desired output के साथ। Multi-shot, जिसे few-shot भी कहा जाता है, कई ऐसे उदाहरण शामिल करता है। उदाहरण training data नहीं हैं; वे prompt में बैठते हैं और मॉडल को उत्तर का exact shape दिखाते हैं जो एक description अकेले अक्सर pin down करने में विफल रहता है।

लागत और गुणवत्ता व्यापार-बंद प्रत्येक उदाहरण जो आप जोड़ते हैं वह हर call पर tokens की लागत करता है और context budget को consume करता है, इसलिए choice quality को cost के विरुद्ध trade करता है। Zero-shot के लिए पहुंचें जब task सरल हो और output shape स्पष्ट हो। One-shot या multi-shot में जाएं जब output का एक specific structure, casing, या edge case हो जो एक description keep missing करता है। अक्सर एक या दो सही उदाहरण आमतौर पर instruction के एक और paragraph से तेजी से issue को fix करते हैं। सामान्य discipline, जो Module 2 reinforce करता है, सबसे छोटी मात्रा में prompt जोड़ना है जो एक reliable result produce करता है।

Mode choice मॉडल choice के साथ interact करता है Prompting mode और मॉडल choice related levers हैं। एक अधिक capable मॉडल अक्सर एक task पर zero-shot succeed करता है जहां एक smaller मॉडल structure को match करने के लिए कुछ उदाहरणों की जरूरत होती है, इसलिए उदाहरण जोड़ने से एक cheaper मॉडल को job करने दे सकता है। दोनों निर्णय एक साथ करने के लायक हैं: simplest मॉडल और fewest उदाहरणों को try करें जो आपके eval को meet करते हैं, और केवल जहां eval कहता है कि आपको उनकी जरूरत है वहां capability या उदाहरण जोड़ें।

स्क्रीन 5: तकनीकी substrate: SDKs, REST, streaming, async

शिक्षणTechnical Substrate·12 मिनट तकनीकी substrate: SDKs, REST, streaming, async

SDK बनाम REST Sync, Streaming & Real-time High-Volume Work के लिए Async

एक डेवलपर Claude तक कैसे पहुंचता है: SDK बनाम raw REST इसके core पर, Claude एक HTTP REST API पर पहुंचा जाता है: आपका code एक endpoint को आपकी API key और एक JSON body के साथ एक request भेजता है, और एक JSON response वापस पढ़ता है। आप किसी भी HTTP client के साथ सीधे उस endpoint को call कर सकते हैं। अधिक आमतौर पर आप एक official SDK का उपयोग करते हैं, Python और TypeScript के बीच अन्य के लिए उपलब्ध, जो same REST API पर एक thin convenience layer है। यह authentication, request construction, retries, और response parsing को handle करता है इसलिए आप कम boilerplate लिखते हैं। SDK और raw REST same API तक पहुंचते हैं और same मॉडल। SDK आपको requests को hand से assemble करने से बचाता है। Module 2 SDK और Messages API के विरुद्ध build करता है, जो same foundation पर बैठता है।

Synchronous, streaming, और real-time responses एक synchronous request सबसे सरल pattern है: आप request भेजते हैं और complete response को एक piece में वापस आने के लिए wait करते हैं, फिर इस पर act करते हैं। यह short responses और backend jobs के लिए ठीक है जहां कोई wait नहीं कर रहा है। जब एक response long हो या एक user watch कर रहा हो, तो streaming response को pieces में भेजता है जैसे मॉडल इसे generate करता है। Output immediately appear होता है बजाय एक blank-screen wait के, और आपका code pieces को final message में reassemble करता है। Claude same HTTP connection पर streaming को expose करता है server-sent events का उपयोग करके। Module 2 सिखाता है कि एक stream को safely कैसे consume करें और जब यह interrupted हो तो recover करें।

High-volume work के लिए Asynchronous patterns दो patterns high-volume work को address करते हैं, और वे अलग-अलग problems को solve करते हैं। Python SDK एक async client (AsyncAnthropic) को expose करता है जो non-blocking async/await का उपयोग करके API calls को बिना आपके application thread को tie किए करता है। TypeScript SDK में standard Anthropic client Promise-based है, इसलिए आप calls को directly await करते हैं। कोई अलग async client class नहीं है। किसी भी तरह से request अभी भी real time में return होता है, लेकिन आपका application अन्य work को handle कर सकता है जबकि यह wait करता है। यह सही pattern है जब आपको blocking के बिना concurrency की जरूरत हो। Message Batches API bulk offline workloads के लिए एक अलग pattern है। आप एक large set of requests को एक call में submit करते हैं, एक identifier receive करते हैं, और completion के लिए poll करते हैं। Batch jobs completion के लिए 24 घंटे तक ले सकते हैं और उस latency के बदले में एक lower per-token cost पर run करते हैं। यह offline pipelines, evaluation runs, और bulk jobs के लिए suits करता है जहां कोई user प्रत्येक result पर wait नहीं कर रहा है और cost turnaround time से अधिक मायने रखता है।

स्क्रीन 6: मॉड्यूल quiz

QuizModule 1·5 मिनट मॉड्यूल quiz अभी try करें। यहां कुछ multiple-choice questions हैं जो अब तक कोर्स की आपकी समझ को test करने के लिए हैं। Question 1एक teammate कहता है कि दो identical prompts को identical text return करना चाहिए। सबसे सटीक response क्या है? Aयह सच है, मॉडल deterministic है।Bजरूरी नहीं, मॉडल प्रत्येक अगले token को एक probability distribution से sample करता है, इसलिए wording भिन्न हो सकता है भले ही दोनों उत्तर सही हों।Cयह केवल तभी सच है जब streaming off हो।Dयह केवल सबसे बड़े मॉडल पर सच है। Question 2कौन सा statement मॉडल choice को reasoning mode से सबसे अच्छी तरह अलग करता है? Aवे same setting हैं।BExtended thinking एक अलग मॉडल है।Cमॉडल choice परिवार के किस सदस्य को चलाना है यह pick करता है; extended thinking एक per-call setting है जो कोई भी supporting मॉडल on या off के साथ चला सकता है।Dreasoning mode account per fixed है। Question 3एक short, well-specified classification task zero-shot सही उत्तर return करता है। तीन उदाहरण जोड़ने से सबसे अधिक संभावना क्या होता है? Aaccuracy को substantially improve करता है।Bहर call पर token cost जोड़ता है little या no gain के लिए।Cउपयोग किए जा रहे मॉडल को change करता है।Dsampling को disable करता है। Question 4आपको हजारों inputs को offline सबसे कम लागत पर process करना चाहिए। कौन सा shape fit करता है? Aएक loop में synchronous calls।Bstreaming।CBatch submission polling के साथ।DAएक बड़ा context window।

Submit quiz Skip for now

स्क्रीन 7: Exercise: behavior को predict करें

ExercisePredict the Behavior·6 मिनट Exercise: behavior को predict करें अभी try करें। नीचे दिए गए प्रत्येक scenario इस मॉड्यूल के चार foundations में से एक से drawn एक configuration प्रस्तुत करता है, sampling, prompting mode, request shape, और context budget। प्रत्येक के लिए, उस answer को select करें जो सही behavior को predict करता है और कारण को identify करता है कि क्यों। Partial credit उपलब्ध है जब आप चार में से तीन को सही तरीके से answer करते हैं। Scenario 1temperature 0 पर चलाए गए एक classification task को एक high temperature पर चलाए गए same task के विरुद्ध consider करें। Predict करें कि repeated runs के पार outputs कैसे भिन्न होते हैं। Aएक low temperature पर, मॉडल सबसे संभावित tokens पर probability को concentrate करता है, इसलिए repeated runs far अधिक consistently same label return करते हैं, हालांकि कभी guaranteed determinism के साथ नहीं, temperature 0 पर भी। एक high temperature पर, distribution spread करता है, इसलिए wording और यहां तक कि chosen label भी vary कर सकता है। एक classifier के लिए आप low-temperature, repeatable behavior चाहते हैं।Bदोनों configurations हर run identical output return करते हैं, क्योंकि temperature केवल response length को affect करता है, कौन से tokens चुने जाते हैं नहीं।Cहigh-temperature run अधिक accurate है, क्योंकि distribution को spread करने से मॉडल को सही उत्तरों के अधिक पर विचार करने देता है।Dtemperature का एक classification task पर कोई प्रभाव नहीं है, क्योंकि classification हमेशा एक fixed label return करता है regardless of sampling। Scenario 2एक task को consider करें जो एक zero-shot prompt के तहत गलत structure में output return करता रहता है। Predict करें कि क्या change होता है यदि आप multi-shot में switch करते हैं। Aमulti-shot में switching मॉडल को नए structure पर retrain करता है, इसलिए change permanent है हर future call के पार एक बार examples भेजे जाने के बाद।Bदो या तीन सही input-output उदाहरण जोड़ने से मॉडल को exact structure को match करने के लिए दिखाता है, जो आमतौर पर एक structure problem को fix करता है जो अधिक instruction text नहीं करता है। Cost हर call पर extra tokens है, इसलिए fewest उदाहरण जोड़ें जो output को reliable बनाते हैं।Cmulti-shot एक structure problem में मदद नहीं करेगा; केवल temperature को raise करने से output का shape change होता है।Dmulti-shot हर call पर token cost को lower करता है, क्योंकि उदाहरण मॉडल को shorter responses produce करने देते हैं। Scenario 3एक pipeline को consider करें जिसे 50,000 documents को रात भर process करना चाहिए कोई user wait के साथ नहीं। Predict करें कि कौन सा request shape fit करता है और क्यों। Aएक synchronous loop सबसे अच्छा fit करता है, क्योंकि API को एक बार प्रति document call करना सबसे सरल pattern है और batch submit करने के overhead को avoid करता है।Bstreaming सबसे अच्छा fit करता है, क्योंकि response को pieces में भेजने से pipeline को प्रत्येक document को तेजी से process करना शुरू करने देता है।Cbatch pattern fit करता है: requests को एक batch में submit करें और completion के लिए poll करें, एक lower per-token cost के लिए longer latency को accept करते हुए। एक synchronous loop rate limits को hit करेगा और application को tie करेगा, और streaming कुछ नहीं खरीदता है क्योंकि कोई user watch नहीं कर रहा है।DAएक बड़ा context window सबसे अच्छा fit करता है, क्योंकि सभी 50,000 documents को एक request में fit करने से repeated calls को avoid करता है। Scenario 4एक long multi-turn agent session को consider करें जिसका context window keep filling हो रहा है। Predict करें कि symptoms क्या हैं और कौन सा budget fault पर है। Aमॉडल silently oldest turns को drop करता है room बनाने के लिए, इसलिए session continue होता है लेकिन quietly early context को lose करता है कोई error के बिना।Bcontext window एक fixed token budget है; जैसे history और tool results accumulate होते हैं यह fill होता है। एक input जो पहले से ही oversized है generation से पहले एक error के साथ reject किया जाता है, जबकि एक request जो input पर fit बैठता है लेकिन generation के दौरान ceiling तक पहुंचता है truncated output के साथ एक model_context_window_exceeded stop reason के साथ वापस आता है। Symptom एक session है जो testing में ठीक चला लेकिन एक बार inputs grow करने पर fail हो गया, यह है कि क्यों application को history को trim या summarize करना चाहिए।Csymptom slower sampling है, और budget fault पर temperature setting है, जिसे session grow करने के साथ lower किया जाना चाहिए।Dकोई fixed budget नहीं है; window automatically expand करता है जो भी history accumulate होता है उसे hold करने के लिए, इसलिए एक long session इस कारण के लिए कभी fail नहीं होता है।

Submit Skip for now

स्क्रीन 8: Recap: पांच takeaways

RecapFive Takeaways·2 मिनट Recap: पांच takeaways

1 Tokens इनपुट, आउटपुट, और लागत की इकाई हैं।Tokens के बजाय शब्दों में सोचें और budget करें, क्योंकि यह वह है जिसमें API meters करता है और context window measures करता है।

2 Context window एक fixed token budget है जो पूरे request को एक साथ रखता है।एक oversized input generation से पहले error करता है, जबकि generation के दौरान ceiling को hit करने से truncated output एक model_context_window_exceeded stop reason के साथ return होता है, इसलिए history को manage करना application का job है।

3 Sampling generation को non-deterministic बनाता है।समान prompt हर run पर अलग-अलग wording return कर सकता है, इसलिए exact text पर testing unreliable है। यह है कि evals किसके लिए built हैं।

4 मॉडल choice और reasoning mode अलग-अलग, composable levers हैं।सबसे छोटे मॉडल और simplest reasoning और prompting को pick करें जो आपके eval को meet करते हैं और केवल जहां eval कहता है कि आपको उनकी जरूरत है वहां capability जोड़ें।

5 एक डेवलपर एक REST API पर Claude तक पहुंचता है, आमतौर पर एक SDK के माध्यम से।Synchronous, streaming, async/await, या batch के बीच choose करें कि क्या एक user wait कर रहा है और क्या workload real-time या bulk offline है।

अगला क्या आता है: Module 2 इन foundations को prompting craft, tool schemas, streaming, context engineering, और agent construction के पार काम में डालता है।

Sources Claude 101 (Skilljar), Building with the Claude API (Skilljar), AI Fluency: Framework & Foundations (Skilljar), platform. claude. com/docs. Publish time पर product specifics को verify करें।

आप अब डेवलपर कोर्स की shared vocabulary बोल सकते हैं। Tokens, context, sampling, मॉडल tiers, prompting modes, और API के transport mechanics अब names हैं, इसलिए बाकी कोर्स सीधे उन पर build कर सकता है।

स्क्रीन 9: Congrats! आपने इस मॉड्यूल को सफलतापूर्वक पूरा किया है।

Module CompleteDeveloper Path·2 मिनट Congrats! आपने इस मॉड्यूल को सफलतापूर्वक पूरा किया है। आप अब tokens, context window, sampling, और non-determinism को समझा सकते हैं, मॉडल choice को reasoning mode से distinguish कर सकते हैं, job के लिए सही prompting mode को choose कर सकते हैं, और वर्णन कर सकते हैं कि एक डेवलपर SDKs, REST, streaming, और async patterns पर Claude तक कैसे पहुंचता है। ये foundations डेवलपर कोर्स के बाकी हिस्से पर build करने वाली shared vocabulary हैं।

0 of ? checkpoints passed

M1

MSO Foundations Tokens, context, sampling, model tiers, prompting modes, और technical substrate।

आप यहां हैं

M2

Production-Grade Prompting, Agents & Tool-use Prompting craft, extended thinking, tool schemas, streaming, context engineering, और agent construction।

अगला

M3

Claude Code, MCP & Integration Permission modes, durable project context, plugin packaging, और MCP integration बिना credentials leak किए।

M4

Production Engineering, Evals, and Security Evals, tracing, failure handling, cost और orchestration budgets, और security boundaries जो production में hold करती हैं।

M5

Accelerators and IP Contribution Package accelerators, prepare verifiable contributions, choose deployment platforms, और mark trust boundaries।

Review module Start over Start Module 2 → Return to course home

Module 1 complete.