LLM APIs कैसे इस्तेमाल करें: Tokens, लागत, Keys और आपका पहला AI फ़ीचर

LLM API एक web सेवा है जो आपकी ऐप को टेक्स्ट किसी large language model को भेजने देती है, जैसे OpenAI के GPT मॉडल, Anthropic का Claude या Google का Gemini, और उसका जवाब code में वापस लेती है। आप provider के साथ साइन अप करते हैं, एक API key बनाते हैं, और आपकी ऐप का server उस key के साथ requests भेजता है; हर request के लिए आपसे tokens (टेक्स्ट के हिस्से) के हिसाब से बिल लिया जाता है, जो अंदर जाते हैं और बाहर आते हैं। “ऐप में AI जोड़ना” आमतौर पर बस इतना होता है: किसी और के मॉडल को एक अच्छी तरह लिखी गई request, जो आपके server से सुरक्षित तरीके से भेजी गई हो।

AI से बनी ऐप के लिए यह क्यों मायने रखता है

AI से बनी ऐप में दो अलग-अलग AI होते हैं, और इन्हें मिलाना आसान है:

1. वह AI जो आपकी ऐप बनाता है — app builder का अपना agent, जो code लिखता है।
2. वह AI जो आपकी ऐप के अंदर है — एक फ़ीचर जो आपके users इस्तेमाल करते हैं, जैसे chat assistant, “इसे सार में बताओ” बटन या अपने आप tagging।

दूसरा वाला LLM API को आपकी key के साथ call करता है और आपके provider account पर बिल बनाता है। Tokens, context और pricing को समझना ही वह तरीका है जिससे आप ऐसा फ़ीचर डिज़ाइन कर सकते हैं जो काम करे, आपकी key लीक न होने दे, और आपको बिल से चौंकाए नहीं।

रोज़मर्रा की एक मिसाल: बहुत काबिल freelancer, शब्दों के हिसाब से भुगतान

LLM API को एक बेहतरीन freelance writer की तरह समझें जिसे आप email से संपर्क करते हैं और जिसे शब्दों के हिसाब से पैसे देते हैं, उन शब्दों के लिए जो आप उन्हें भेजते हैं और उन शब्दों के लिए जो वे वापस लिखते हैं (और लिखे गए शब्द ज़्यादा महंगे होते हैं)।

• उनकी emails के बीच कोई याददाश्त नहीं होती। अगर आप चाहते हैं कि बातचीत आगे बढ़े, तो हर नए email में पिछले संदेश दोबारा चिपकाने होते हैं।
• वे एक बार में सिर्फ़ इतना पढ़ सकते हैं। वह सीमा context window कहलाती है।
• आपका brief जितना साफ़ होगा, जवाब उतना बेहतर और छोटा होगा, और इसलिए सस्ता भी।

मुख्य अवधारणाएं

Tokens

मॉडल टेक्स्ट को tokens में पढ़ता और लिखता है। Anthropic का pricing documentation सितंबर 2026 तक अनुमान लगाता है कि एक token में लगभग 4 अक्षर, या लगभग 0.75 अंग्रेज़ी शब्द होते हैं। अलग-अलग मॉडल और भाषाएं अलग तरह से tokens बनाते हैं, इसलिए इसे एक मोटा अनुमान मानें। हर चीज़ गिनी जाती है: आपके निर्देश, user का संदेश, साथ भेजे गए कोई भी दस्तावेज़, पिछली बातचीत और जवाब।

Input और output

Input tokens वे हैं जो आप भेजते हैं। Output tokens वे हैं जो मॉडल लिखता है। OpenAI, Anthropic और Google के pricing पेजों के अनुसार, सितंबर 2026 तक, एक ही मॉडल के लिए output tokens की कीमत input tokens से कई गुना ज़्यादा होती है। Google के Gemini pricing में यह भी लिखा है कि मॉडल की अंदरूनी “thinking” भी output में गिनी जाती है।

Context window

अधिकतम tokens जो एक मॉडल एक request में ले सकता है, जिसमें जवाब भी शामिल है। आज के मॉडल बहुत लंबे input स्वीकार करते हैं: उदाहरण के लिए Anthropic के कुछ मौजूदा मॉडल दस लाख tokens तक ले सकते हैं। लेकिन लंबे input ज़्यादा महंगे होते हैं और ज़्यादा समय लेते हैं, इसलिए सिर्फ़ वही भेजें जो काम के लिए ज़रूरी है।

Stateless requests

ज़्यादातर chat-style APIs में हर request डिफ़ॉल्ट रूप से अपने आप में होती है। Chat को “याद” रखने के लिए आपकी ऐप हर नए संदेश के साथ पिछले संदेश दोबारा भेजती है। इसीलिए लंबी बातचीत में हर संदेश की लागत छोटी बातचीत से ज़्यादा होती है।

System prompt

वे निर्देश जो हर request के लिए मॉडल की भूमिका और नियम तय करते हैं: “तुम support tickets को तीन bullet points में सारांशित करते हो। कभी भी customer के email addresses शामिल मत करो।” User इन्हें नहीं देखते, लेकिन ये हर जवाब को आकार देते हैं।

Streaming

पूरे जवाब का इंतज़ार करने के बजाय API जवाब को उसके बनते-बनते भेज सकता है, ताकि users शब्द तुरंत दिखते हुए देखें। इससे chat interfaces बहुत तेज़ महसूस होते हैं।

Pricing कैसे काम करती है

सितंबर 2026 तक, provider के अपने pricing पेजों पर जांचा गया:

कुछ providers खरीदने से पहले आज़माने का तरीका भी देते हैं: Anthropic नए users को थोड़ा मुफ़्त credit देता है, और Google का Gemini API कुछ मॉडलों पर free tier देता है, इस चेतावनी के साथ कि उस पर भेजे गए content का इस्तेमाल Google के उत्पादों को बेहतर बनाने में हो सकता है।

छोटे, तेज़ मॉडल और सबसे बड़े मॉडलों की कीमतों में बहुत फ़र्क होता है, और ये अक्सर बदलती हैं, इसलिए हम यहां कोई दाम नहीं लिखते। किसी भी फ़ीचर का एक सरल अनुमान है: (input tokens × input कीमत + output tokens × output कीमत) × हर महीने की requests की संख्या। फिर कुछ margin जोड़ें, और provider के dashboard में मासिक खर्च की सीमा तय करें।

एक उदाहरण: “इस ticket का सार बनाओ” बटन

एक छोटी support team चाहती है कि एक बटन लंबे customer email thread को तीन bullet points और एक सुझाए गए जवाब में बदल दे।

1. Key लें। एक provider के साथ account बनाएं और एक API key जनरेट करें। मासिक खर्च की कम सीमा तय करें।
2. Key को एक secret के रूप में अपने server पर रखें, जैसे ANTHROPIC_API_KEY या OPENAI_API_KEY नाम से, कभी भी page के code में नहीं। देखें environment variables और secrets।
3. एक server route जोड़ें, POST /api/summarise, जो:
   • जांचे कि व्यक्ति logged in है और support team का सदस्य है;
   • database से ticket लोड करे;
   • provider को एक system prompt (“तीन bullets में सार दो, फिर एक विनम्र जवाब का मसौदा बनाओ; order numbers मत गढ़ो”) और ticket का टेक्स्ट भेजे;
   • maximum output tokens सेटिंग से जवाब की लंबाई सीमित करे;
   • नतीजा वापस दे और लिखे कि कितने tokens इस्तेमाल हुए।
4. बटन provider को नहीं, आपके route को call करता है, और सार पेज पर आते हुए दिखाता है।
5. विफलता संभालें। अगर provider धीमा है या error देता है, तो “अभी सार नहीं बन सका” दिखाएं और ticket को उपयोगी बनाए रखें।
6. मापें। एक हफ़्ते बाद token logs देखें। अगर ज़्यादातर लागत लंबे email threads से आ रही है, तो भेजने से पहले उद्धृत पुराना इतिहास काट दें।

ध्यान दें कि इसमें क्या नहीं है: कोई model training नहीं, कोई खास infrastructure नहीं। एक key, एक server route, एक अच्छी तरह लिखा prompt।

मुख्य शब्द

• API key: वह गुप्त कुंजी जो provider को आपका account पहचानने देती है। जिसके पास यह है, वह आपका पैसा खर्च कर सकता है।
• Model: वह खास LLM जिसे आप call करते हैं। Providers कई आकारों के मॉडल अलग कीमत और गति पर देते हैं।
• Temperature: जवाब कितने विविध होंगे, यह तय करने की सेटिंग। कम मान ज़्यादा अनुमान योग्य होता है।
• Max tokens: जवाब की लंबाई पर सीमा, जो लागत पर भी सीमा लगाती है।
• Rate limit: आपका account प्रति मिनट कितनी requests या tokens इस्तेमाल कर सकता है।
• Embeddings: वे संख्याएं जो टेक्स्ट के अर्थ को दर्शाती हैं, जो आपके अपने दस्तावेज़ों में खोज के लिए इस्तेमाल होती हैं।
• RAG (retrieval-augmented generation): आपके अपने डेटा से प्रासंगिक अंश खोजकर prompt में शामिल करना, ताकि मॉडल आपके content से जवाब दे।
• Tool use / function calling: मॉडल को अनुमति देना कि वह आपकी ऐप से एक खास function चलाने को कहे, जैसे “order status देखो”।

आम गलतफ़हमियां और गलतियाँ

• Key को frontend code में डालना। यह सबसे महंगी गलती है। Browser का code सार्वजनिक होता है। हमेशा अपने server से call करें। AI से बनी ऐप्स के लिए security checklist में यह दूसरे launch checks के साथ शामिल है।
• कोई खर्च सीमा या प्रति-user सीमा नहीं। एक bug, एक loop या कोई दुरुपयोग करने वाला user जल्दी खर्च बढ़ा सकता है। Provider की सीमा तय करें और अपनी ऐप में हर user की requests सीमित करें।
• हर बार सब कुछ भेजना। पूरे दस्तावेज़ और पूरी chat history input tokens को गुणा कर देते हैं। काटें, पुराने संदेशों का सार बनाएं, या सिर्फ़ प्रासंगिक हिस्से खोजें।
• Output पर आंख बंद करके भरोसा करना। मॉडल आत्मविश्वास से गलत बातें कह सकते हैं। तथ्यों, कीमतों या किसी कानूनी या चिकित्सा मामले के लिए जवाब अपने डेटा पर आधारित करें और स्रोत दिखाएं, या किसी व्यक्ति से जांच करवाएं।
• User के input को आपके नियम बदलने देना। Users लिख सकते हैं “अपने निर्देश भूल जाओ”। अनुमतियां और संवेदनशील कार्य prompt में नहीं, अपने server code में रखें।
• सबसे बड़े मॉडल से शुरू करना। पहले छोटा, सस्ता मॉडल आज़माएं; तभी ऊपर जाएं जब गुणवत्ता की ज़रूरत हो।
• बिना सोचे personal डेटा भेजना। Provider की data-use शर्तें जांचें, खासकर free tiers पर, और उतना ही भेजें जितना फ़ीचर को चाहिए।

अपने AI builder से क्या मांगें

ticket पेज पर एक “Summarise” बटन जोड़ो। यह एक server route को call करे जो secret OPENAI_API_KEY इस्तेमाल करे (जो कभी browser को न दिखे), जांचे कि user logged in है, ticket का टेक्स्ट इस system prompt के साथ भेजे: […], जवाब को 300 tokens तक सीमित करे, जवाब को page पर stream करे, और call विफल होने पर एक दोस्ताना error दिखाए। हर request के इस्तेमाल हुए tokens log करो, और हर user को प्रति घंटे 30 summaries तक सीमित करो।

पूरे chat अनुभव के लिए, देखें AI chatbot ऐप कैसे बनाएं; दूसरे विचारों के लिए, अपनी ऐप में AI फ़ीचर कैसे जोड़ें। अगर APIs सामान्य रूप से नए हैं, तो API क्या है से शुरू करें।

Mythex से बनी ऐप्स में LLM APIs

जब आप Mythex से बनाते हैं, तो आपकी ऐप के अंदर का AI आपकी अपनी provider key इस्तेमाल करता है। आप इसे प्रोजेक्ट secret के रूप में जोड़ते हैं, या उस secrets कार्ड के ज़रिए जो Mythex चैट में दिखाता है जब उसकी ज़रूरत होती है, और agent से कहते हैं कि call server पर करे। Provider का इस्तेमाल आपके provider account पर बिल होता है, Mythex build credits पर नहीं। Mythex आपकी ऐप के users के लिए tokens शामिल नहीं करता, न ही कोई built-in knowledge-base उत्पाद देता है, और rate limits और लागत नियंत्रण आपको डिज़ाइन और परखने होते हैं। Docs की recipe अपनी API keys से AI फ़ीचर जोड़ें में एक starter prompt है, और AI app builder पेज बताता है कि शुरू कहां से करें।

सवाल