By RamthaMedia
RamthaMedia Free eBooks · August 2026
Price: Priceless
· 15 min read
Preface
एक इमेज बनाना हो, अवतार वीडियो या अपने ऐप में जनरेशन जोड़ना हो – रास्ता एक ही जगह से गुज़रता है: Hedra का एजेंट या उसका v3 API। यह किताब वही रास्ता खोलती है जो होमपेज पर नहीं दिखता – एजेंट को सही संदर्भ कैसे दें, तीस से ज़्यादा मॉडलों में से कौन सा किस काम का है, जॉब फेल होने पर एरर कोड क्या करने को कहता है, और क्रेडिट कहाँ चुपचाप खर्च होते हैं। पढ़ने के बाद आप एक जॉब भेजना, उसका नतीजा भरोसे से पाना और अपने खर्च पर नज़र रखना – तीनों जान जाएँगे।
Chapter 1
एक एजेंट, एक कैनवस, और शुरुआत का कोई अंदाज़ा नहीं
स्क्रीन पर एक खाली कैनवस है, नीचे एक टेक्स्ट बॉक्स है, और कर्सर टिमटिमा रहा है। कोई मेन्यू नहीं जो बताए कि पहले क्या दबाना है, कोई टेम्पलेट लिस्ट नहीं जो रास्ता दिखाए – सिर्फ एक लाइन जहाँ अपना मकसद लिखना है। यही Hedra का असली रूप है, और यही वजह है कि पहला मिनट सबसे भ्रम भरा लगता है।
बाकी टूल एक फ़ीचर चुनने से शुरू होते हैं – 'इमेज बनाएँ' या 'वीडियो बनाएँ' जैसा कोई बटन। Hedra उल्टा काम करता है: पहले लक्ष्य बताओ, फिर एजेंट खुद तय करता है कि किस मॉडल और किस क्रम से वहाँ पहुँचा जाए। एक प्रोडक्ट की तस्वीर से पंद्रह-सेकंड का विज्ञापन बनाना हो, तो यही एक वाक्य काफ़ी है – बाकी काम एजेंट संभालता है, बशर्ते उसे शुरुआत में सही चीज़ें दी जाएँ।
यह भरोसा एक जगह टूटता है: एजेंट सिर्फ़ उतना ही जानता है जितना उसे बताया गया है। खाली प्रॉम्प्ट से भी वह कुछ न कुछ बना देगा, लेकिन नतीजा अनुमान पर टिका होगा। असल फ़र्क अगले अध्याय में है – एजेंट को कुछ ऐसा देना जिसे वह पकड़कर रख सके, ताकि अंदाज़ा लगाने की गुंजाइश ही न बचे।
What you can actually do here
Hedra पर तीस से ज़्यादा मॉडल नाम मिलते हैं, और हर एक किसी एक काम के लिए बना है। नीचे वही दिखाया गया है जो असल में अलग-अलग काम करता है, ताकि पहला जॉब गलत मॉडल पर बर्बाद न हो।
इमेज बनाना और बदलना
| Use | Who it fits | Where | Worth knowing |
|---|---|---|---|
| किसी मौजूदा फ़ोटो को टेक्स्ट निर्देश से बदलना | प्रोडक्ट फ़ोटो एडिट करने वाला, विज्ञापन बनाने वाला | Image टूल → मॉडल चुनें जो images इनपुट लेता है (जैसे Flux Kontext, GPT Image, Reve) → संदर्भ फ़ोटो अपलोड करें → प्रॉम्प्ट दें | एक ही सोर्स इमेज से कई बदलाव संभव हर मॉडल में इमेज की संख्या और आउटपुट फ़ॉर्मैट अलग है |
| शुरू से नई इमेज बनाना, बिना किसी संदर्भ फ़ोटो के | कॉन्सेप्ट आर्ट, मार्केटिंग विज़ुअल बनाने वाला | Image टूल → कोई भी टेक्स्ट-टू-इमेज मॉडल → aspect_ratio और resolution तय करें | कुछ मॉडल 4K तक रिज़ॉल्यूशन देते हैं हर जॉब एक ही आउटपुट देता है – num_outputs हमेशा 1 पर तय है |
वीडियो बनाना
| Use | Who it fits | Where | Worth knowing |
|---|---|---|---|
| एक स्थिर फ़ोटो को हिलती हुई वीडियो में बदलना | प्रेज़ेंटर वीडियो, प्रोडक्ट डेमो बनाने वाला | Video टूल → start_image वाला मॉडल चुनें → अवधि और aspect_ratio तय करें | साथ में ऑडियो अपने आप जनरेट हो सकता है ज़्यादातर वीडियो मॉडल में अवधि सिर्फ़ तय स्टेप्स में चुनी जा सकती है, मनचाहा सेकंड नहीं |
| किसी फ़ोटो और आवाज़ से बोलता हुआ अवतार बनाना | प्रेज़ेंटर, ट्रेनिंग वीडियो बनाने वाला | hedra-avatar मॉडल → start_image + audio दोनों दें | चेहरा और आवाज़ दोनों एक ही जॉब में मिलते हैं audio और start_image दोनों देना ज़रूरी है – एक भी छूटा तो जॉब स्वीकार नहीं होगा |
Chapter 2
एजेंट को कुछ ऐसा दीजिए जिसे वह पकड़ कर रख सके
एक ब्रांड मैनेजर हर हफ़्ते एक नया प्रोडक्ट शॉट चाहता है, लेकिन हर बार चेहरा, रंग या लोगो थोड़ा बदल जाता है – क्योंकि हर प्रॉम्प्ट एजेंट के लिए एक नई शुरुआत है, पिछले जॉब की याद नहीं। इसका हल टेक्स्ट में और तफ़सील जोड़ना नहीं है – एक 'संदर्भ' देना है।
Hedra में यह काम 'References और Elements' के ज़रिए होता है: एक फ़ोटो, एक प्रोडक्ट इमेज या एक तय स्टाइल को एक बार सेव करके एजेंट के सामने रखा जा सकता है, और वह हर आगे के जॉब में उसी पहचान को बनाए रखता है। एक Space के अंदर यह संदर्भ बना रहता है – बातचीत, कैनवस और आउटपुट तीनों एक साथ, ताकि दस दिन बाद भी उसी प्रोजेक्ट पर लौटा जा सके।
जो लोग बार-बार एक ही तरह का निर्देश देते हैं, उनके लिए एक और शॉर्टकट है – Skills। एक बार लिखा गया निर्देश ('हमेशा 9:16 में, बिना टेक्स्ट के') सेव होकर हर नए जॉब पर अपने आप लागू हो सकता है, जिससे हर बार वही बात दोहरानी नहीं पड़ती। कनेक्टर्स इसी विचार को आगे ले जाते हैं – एजेंट को बाहरी जानकारी से जोड़कर, ताकि वह सिर्फ़ प्रॉम्प्ट पर नहीं, असली संदर्भ पर काम करे।
एक जगह यह मददगार नहीं है: अवतार वीडियो बनाने के लिए सिर्फ़ फ़ोटो काफ़ी नहीं, driving audio भी अनिवार्य है – बिना आवाज़ के hedra-avatar मॉडल जॉब ही स्वीकार नहीं करता। जो लोग खुद की आवाज़ रिकॉर्ड करके अवतार को बुलवाना चाहते हैं, उनके लिए साफ़ रिकॉर्डिंग यहीं से शुरू होती है।
Chapter 3
बीसियों मॉडल, एक ही सबमिट एंडपॉइंट, और कोई एक सही जवाब नहीं
एक डेवलपर जो पहली बार v3 मॉडल कैटलॉग खोलता है, उसे तीस से ज़्यादा नाम एक लिस्ट में मिलते हैं – Nano Banana, Seedream, Flux, Veo, Kling, Qwen Image, और कई और। हर एक को POST /models/{नाम} पर सबमिट किया जाता है, यानी कोड की बनावट एक जैसी है; फ़र्क सिर्फ़ यह है कि हर मॉडल किन इनपुट्स को समझता है।
कुछ मॉडल सिर्फ़ टेक्स्ट से इमेज बनाते हैं (जैसे Sana, Flux Dev), कुछ मौजूदा इमेज को एडिट करते हैं (Flux Kontext, HiDream-O1, Reve Edit), और कुछ इमेज को हिलती वीडियो में बदलते हैं (Seedance, Veo, Kling, PixVerse)। यह फ़र्क डॉक्यूमेंटेशन के 'input' सेक्शन में साफ़ लिखा है – अगर किसी मॉडल में images फ़ील्ड 'required' है, तो वह बिना संदर्भ फ़ोटो के चलेगा ही नहीं।
resolution और quality भी हर मॉडल पर अलग तरह से काम करते हैं। कोई मॉडल सिर्फ़ 480p और 720p देता है, कोई 4K तक जाता है; कोई मॉडल क्वालिटी लेवल के तौर पर 'standard/pro' लेता है, तो कोई 'fast/standard' के बीच चुनाव देता है। एक ही मॉडल नाम को हर जगह डिफ़ॉल्ट मानना – जैसे यह सोचना कि सब 1080p सपोर्ट करते हैं – सबसे आम गलती है, और यह पहली रिक्वेस्ट के रिजेक्ट होने की सबसे बड़ी वजह भी है।
जब कोई मॉडल रिटायर हो जाता है, तो एरर कोड GONE आता है, और साथ में replaced_by फ़ील्ड नए मॉडल का नाम बता देती है – जिससे कोड में हार्डकोड किया मॉडल नाम अपने आप अगले वर्शन पर शिफ़्ट किया जा सकता है, बिना डॉक्यूमेंटेशन दोबारा पढ़े।
Chapter 4
खत्म होने वाले जॉब और नज़र रखनी पड़ने वाले जॉब के बीच का फ़र्क
हर जॉब सबमिट होते ही 202 रिस्पॉन्स के साथ चार चीज़ें लौटाता है – job_id, status, status_url और result_url। यहीं से एक फ़ैसला लेना पड़ता है: बार-बार पोल करना है, या नतीजा आने का इंतज़ार अपने सर्वर पर करना है।
पोलिंग का तरीका सीधा है – status_url पर बार-बार GET भेजते रहना, जब तक status COMPLETED या FAILED न हो जाए। लेकिन एक सर्वर जो हज़ारों जॉब एक साथ संभालता है, उसके लिए यह तरीका महँगा पड़ता है – हर जॉब के लिए अलग टाइमर, अलग रिट्राई लॉजिक।
इसका दूसरा रास्ता वेबहुक है: submit के वक़्त एक webhook URL दे दें, और Hedra खुद उस पते पर नतीजा POST कर देगा – job.completed या job.failed, दोनों में से एक, कभी दोनों नहीं। एक बार का कॉन्फ़िगर हर जॉब पर अलग URL ले सकता है; एक डिफ़ॉल्ट कॉन्फ़िगर उन सारे जॉब को कवर करता है जिन्होंने कोई अलग URL नहीं दिया। दोनों साथ चल सकते हैं – अलग URL हमेशा डिफ़ॉल्ट से आगे रहता है।
एक बात जो शुरुआत में भूल जाती है: बना हुआ मीडिया हमेशा के लिए स्टोर नहीं रहता। जॉब पूरा होने के 48 घंटे बाद तक ही outputs की लिंक काम करती है; उसके बाद वही लिंक EXPIRED दिखाएगी और url खाली मिलेगा। जो asset_id मिला है उसे एक बार सेव कर लेना ज़रूरी है, ताकि बाद में उसे किसी नए जॉब के इनपुट में संदर्भ की तरह दोबारा इस्तेमाल किया जा सके – भले ही असली फ़ाइल एक्सपायर हो चुकी हो।
You may also like:
Google Flow से आप असल में क्या बना सकते हैं
Chapter 5
जब जॉब फेल होता है, एरर बताता है कि दोबारा कोशिश करें या नहीं
एक डेवलपर जिसका जॉब अचानक FAILED लौटाता है, उसका पहला सवाल यही होता है – क्या वही रिक्वेस्ट दोबारा भेजनी है, या कुछ बदलना है। इसका जवाब error.code में छिपा है, टेक्स्ट में नहीं।
हर एरर एक तय कोड के साथ आता है – INVALID_ARGUMENT, NOT_FOUND, INSUFFICIENT_BALANCE, MODERATION_FAILED, RESOURCE_EXHAUSTED, और कुछ और। इनमें से हर एक के साथ retryable नाम की एक फ़ील्ड होती है, जो साफ़ बताती है कि दोबारा कोशिश करने से फ़र्क पड़ेगा या नहीं – सिर्फ़ error.message को पढ़कर अंदाज़ा लगाना ज़रूरी नहीं, क्योंकि टेक्स्ट बदल सकता है पर कोड नहीं बदलता।
जब retryable सच होता है, retry_after भी साथ आता है – यानी कितने सेकंड रुककर दोबारा भेजना है। यह अंदाज़ा नहीं, सर्वर का सीधा निर्देश है, और इसे नज़रअंदाज़ करना उसी जॉब को बार-बार असफल बनाता है।
बैलेंस की कमी की वजह से फेल हुए जॉब में एक अलग जानकारी मिलती है – billing नाम की फ़ील्ड, जो बताती है कि कितना बैलेंस चाहिए था, कितना है, और कहाँ पैसे जोड़े जा सकते हैं। और एक ही रिक्वेस्ट को गलती से दो बार भेजने से बचने के लिए idempotency_key का इस्तेमाल किया जा सकता है – एक ही key के साथ भेजी गई दोहरी रिक्वेस्ट नया जॉब नहीं बनाती, बल्कि पहले वाले जॉब की ही पावती लौटा देती है।
Chapter 6
जॉब को अंदर से देखना, सिर्फ नतीजे से नहीं
एक टीम जो रोज़ाना सैकड़ों जॉब भेजती है, उसके लिए सिर्फ़ 'पूरा हुआ या नहीं' काफ़ी नहीं होता – यह जानना ज़रूरी होता है कि किसी जॉब में देरी क्यों हो रही है, या किस स्टेज पर वह अटका हुआ है।
इसके लिए लॉग ड्रेन बनाया जा सकता है – एक ऐसा कनेक्शन जो हर जॉब के हर लाइफ़साइकल इवेंट (queued, started, provider.submitted, progress, completed, failed, और कुछ और) को अपने आप एक HTTPS पते पर भेज देता है। यह NDJSON के रूप में आ सकता है – एक लाइन, एक इवेंट – या OTLP के रूप में, जो सीधे किसी ऑब्ज़र्वेबिलिटी टूल जैसे OpenTelemetry Collector में चला जाता है।
हर NDJSON बैच पर एक हस्ताक्षर होता है – X-Hedra-Signature, जो ड्रेन के अपने secret से बना HMAC-SHA256 है। इसे बिना जाँचे किसी बैच पर भरोसा करना खतरनाक है, क्योंकि यही जाँच बताती है कि डेटा असल में Hedra से आया है, किसी और स्रोत से नहीं।
अगर कोई endpoint लगातार पाँच बार जवाब देने में नाकाम रहता है, तो ड्रेन खुद बंद हो जाता है – disabled_reason में इसकी वजह भी दर्ज हो जाती है। यही व्यवहार वेबहुक के साथ भी है, बस वहाँ कोशिशों की संख्या बारह है, लगभग छह घंटे तक फैली हुई – 10 सेकंड से शुरू होकर हर बार अंतराल बढ़ाते हुए, आखिर में हर घंटे एक कोशिश तक।
You may also like:
invideo के क्रेडिट असल में आपको क्या दिलाते हैं
Chapter 7
क्रेडिट, प्लान, और वह रीसेट जिसे कोई दोबारा नहीं पढ़ता
एक क्रिएटर जो महीने के आखिरी हफ़्ते में अचानक क्रेडिट खत्म पाता है, वह अक्सर यही सोचता है कि उसने ज़्यादा इस्तेमाल कर लिया। असली वजह अक्सर कुछ और होती है – यह न जानना कि क्रेडिट कब और कैसे रीसेट होते हैं।
मासिक सब्सक्रिप्शन में क्रेडिट हर महीने एक तय तारीख़ पर रीसेट होते हैं; सालाना सब्सक्रिप्शन में यह हिसाब अलग तरीके से चलता है, और दोनों का व्यवहार एक जैसा मान लेना सबसे बड़ी गलतफ़हमी है। यह फ़र्क कहीं बड़े अक्षरों में नहीं लिखा – बिलिंग सेटिंग्स के अंदर, जनरेशन हिस्ट्री के पास दबा हुआ मिलता है।
क्रेडिट पैक अलग से खरीदे जाएँ, तो उनका रोलओवर नियम सब्सक्रिप्शन के मासिक क्रेडिट से अलग होता है – यह वही जगह है जहाँ 'बचे हुए क्रेडिट अगले महीने चले जाएँगे या नहीं' का जवाब मिलता है, न कि प्लान पेज पर। डेवलपर साइड पर एक और विकल्प है – API वॉलेट का अपने आप टॉप-अप होना, ताकि किसी बड़े बैच के बीच में बैलेंस खत्म होने से जॉब अचानक रुक न जाएँ।
सब्सक्रिप्शन रद्द करने का असर तुरंत नहीं, बल्कि मौजूदा बिलिंग साइकिल के खत्म होने पर लागू होता है – यानी रद्द करने के बाद भी बचे हुए दिनों का इस्तेमाल किया जा सकता है। भुगतान का तरीका बदलना हो या प्लान अपग्रेड करना हो, दोनों एक ही जगह से होते हैं, लेकिन डाउनग्रेड और अपग्रेड का क्रेडिट-एडजस्टमेंट व्यवहार एक जैसा नहीं है – अपग्रेड से पहले यह जाँच लेना बेहतर है कि मौजूदा साइकिल के बचे हुए क्रेडिट का क्या होगा।
Chapter 8
रीयल-टाइम सहयोग, और शेयर की गई जगह का क्या होता है
एक छोटी टीम जो एक ही कैंपेन पर काम कर रही है, उसे बार-बार फ़ाइल भेजने की ज़रूरत नहीं पड़ती अगर सब एक ही Space में जुड़े हों। ईमेल से किसी को Space में जोड़ा जा सकता है, और उसे कितनी पहुँच देनी है यह भी तय किया जा सकता है – सिर्फ़ देखने की, या साथ में बनाने की।
यह सहयोग रीयल-टाइम है – एक ही कैनवस, एक ही बातचीत, एक साथ कई लोग देख और बदल सकते हैं। इसका सीधा फ़ायदा यह है कि किसी क्लाइंट को लाइव दिखाया जा सकता है कि एजेंट किस दिशा में जा रहा है, बिना स्क्रीनशॉट भेजे।
Library इसी सहयोग को व्यवस्थित रखने का ज़रिया है – जो भी मीडिया या Element किसी Space में बनाया गया है, वह वहाँ ढूँढा, समूहों में रखा, दोबारा इस्तेमाल किया और शेयर किया जा सकता है। एक टीम जो हफ़्तों तक एक ही प्रोजेक्ट पर काम करती है, उसके लिए यही जगह है जहाँ पुराना काम खो नहीं जाता।
एक बात ध्यान रखने की है – पहुँच का स्तर हर सदस्य के लिए अलग तय किया जा सकता है, इसलिए किसी नए सदस्य को Space में जोड़ने से पहले यह तय कर लेना बेहतर है कि उसे सिर्फ़ देखना है या बदलाव भी करना है, क्योंकि यह सेटिंग बाद में ढूँढना उतना आसान नहीं जितना जोड़ते वक़्त तय करना।
Chapter 9
अगला जॉब भेजने से पहले क्या तय करना है
जो कोई पहली बार यहाँ तक पहुँचा है, उसके सामने अब एक ही असली फ़ैसला बचता है – काम को ऐप के एजेंट से चलाना है, या v3 API से सीधे अपने प्रोडक्ट में जोड़ना है। दोनों एक ही जनरेशन इंजन इस्तेमाल करते हैं; फ़र्क सिर्फ़ इतना है कि नियंत्रण कहाँ रखा जाए।
जिसे बार-बार, अलग-अलग तरह का कंटेंट चाहिए और जो हर बार टाइप करके संदर्भ देना पसंद करता है, उसके लिए एजेंट वर्कस्पेस सही जगह है – खासकर तब जब References और Skills के ज़रिए एक जैसी पहचान बार-बार बनानी हो। जिसे अपने ऐप में हज़ारों जॉब अपने आप चलाने हैं, बिना किसी इंसान के हर बार क्लिक किए, उसके लिए v3 API और वेबहुक ही रास्ता है।
जो भी रास्ता चुना जाए, तीन आदतें बाद में होने वाली परेशानी बचाती हैं – जॉब पूरा होते ही उसका outputs डाउनलोड कर लेना, क्योंकि 48 घंटे बाद वही लिंक बेकार हो जाएगी; क्रेडिट के रीसेट और रोलओवर नियम बिलिंग पेज पर देखकर शुरू करना, अंदाज़े पर नहीं; और किसी भी एरर को कोड से पहचानना, संदेश के शब्दों से नहीं।
इतना तय हो जाए, तो अगला जॉब भेजना अंदाज़े का काम नहीं रह जाता – यह एक ऐसा फ़ैसला बन जाता है जिसका नतीजा पहले से मालूम है।
Questions readers actually ask
क्या मासिक और सालाना सब्सक्रिप्शन में क्रेडिट एक जैसे रीसेट होते हैं?
नहीं। दोनों का व्यवहार अलग है – सालाना सब्सक्रिप्शन के क्रेडिट की अपनी अलग व्यवस्था है, जिसे बिलिंग सेटिंग्स के अंदर अलग से समझाया गया है, न कि मासिक क्रेडिट वाले उसी नियम से।
सब्सक्रिप्शन रद्द करने के बाद क्या तुरंत एक्सेस बंद हो जाता है?
नहीं, रद्द करना मौजूदा बिलिंग साइकिल के खत्म होने पर लागू होता है, तुरंत नहीं – बचे हुए दिनों का इस्तेमाल किया जा सकता है।
क्या एक बार डिलीट किया गया अकाउंट वापस पाया जा सकता है?
अकाउंट डिलीट करने के पन्ने में इसकी शर्तें साफ़ लिखी हैं – डिलीट करने से पहले यह पढ़ना ज़रूरी है, क्योंकि यह हर मामले में वापस नहीं होता।
बना हुआ वीडियो या इमेज कितने समय तक डाउनलोड की जा सकती है?
जॉब पूरा होने के 48 घंटे बाद तक outputs की लिंक काम करती है; उसके बाद वही लिंक EXPIRED हो जाती है और url खाली दिखता है।
अगर webhook endpoint कुछ घंटों के लिए बंद रहा, तो क्या नतीजा हमेशा के लिए खो जाता है?
नहीं, जब तक रिट्राई विंडो (लगभग छह घंटे, बारह कोशिशों में) खत्म नहीं हुई। उसके बाद डिलीवरी FAILED दिखती है और मैन्युअल रीप्ले से दोबारा भेजी जा सकती है।
क्या हर मॉडल एक जैसी इमेज या वीडियो संख्या एक जॉब में देता है?
नहीं, हर जॉब सिर्फ़ एक आउटपुट देता है – num_outputs हर मॉडल में 1 पर तय है, चाहे मॉडल कोई भी हो।
क्या API वॉलेट अपने आप टॉप-अप हो सकता है?
हाँ, डेवलपर साइड पर यह विकल्प मौजूद है, ताकि बड़े बैच के बीच में बैलेंस खत्म होने से जॉब अचानक रुके नहीं।
क्या एक ही Space में जोड़े गए सभी सदस्यों की पहुँच बराबर होती है?
नहीं, हर सदस्य को अलग पहुँच स्तर दिया जा सकता है – सिर्फ़ देखने की, या साथ में बनाने की – यह जोड़ते वक़्त तय करना होता है।
Contact / More useful information from RamthaMedia
Official source links:
Hedra
डिस्क्लेमर: यह ईबुक सार्वजनिक रूप से उपलब्ध जानकारी से तैयार की गई है और लिखे जाने के समय सटीक थी। पूर्ण और नवीनतम विवरण के लिए ऊपर दी गई आधिकारिक वेबसाइट पर जाएं। इस ईबुक के आधार पर लिए गए किसी भी निर्णय के लिए RamthaMedia कोई कानूनी ज़िम्मेदारी नहीं लेता, और यहाँ दी गई जानकारी पेशेवर, वित्तीय या कानूनी सलाह नहीं है। कवर पेज पर उपयोग की गई छवि केवल उदाहरण के लिए है – Pexels से ली गई स्टॉक फोटो या AI-जनरेटेड इमेज, वर्णित साइट की वास्तविक तस्वीर नहीं।
