Markdown संस्करण

AI-translated from English; not yet reviewed by a fluent editor.

# प्रोडक्शन API वर्कफ़्लो के लिए GPT-6 मॉडल चुनें

> GPT-6 Astra, GPT-6.1 Sol और Luna के लिए काम-आधारित मार्गदर्शिका। तैनाती से पहले गुणवत्ता, latency और लागत जाँचने हेतु मौजूदा API दरें और एक कार्यपत्रक।

By BIG CHANGE Editorial

Published: 2026-10-09T20:51:30.540Z
Updated: 2026-10-09T20:51:30.540Z
Canonical: https://bigchange.ai/blog/choose-gpt-6-model-production-api-workflow

![Conceptual charcoal illustration of blank task cards entering three equal, distinct channels that converge at an empty circular checkpoint.](https://bigchange.ai/api/media/file/gpt6-task-routing-hero-v3.png)
AI-generated conceptual editorial illustration by BIG CHANGE.

OpenAI ने 2 अक्टूबर 2026 को [GPT-6 परिवार की मार्गदर्शिका](https://openai.com/index/practical-guide-building-gpt-6/) प्रकाशित की। इसमें मॉडल चुनने, निर्देश देने, लंबे समय तक चलने वाले कार्यों और तैनाती की जाँच को एक साथ रखा गया है। सॉफ़्टवेयर टीम को फिर भी ऐसा संयोजन ढूँढ़ना होगा जो अपनी कार्य-जाँच में सफल हो और लागत तथा प्रतिक्रिया-समय की सीमाओं में रहे।

उस मार्गदर्शिका में मौजूदा परिवार के विकल्प GPT-6 Astra, GPT-6.1 Sol और GPT-6 Luna हैं। हमने 3 अक्टूबर को OpenAI के API दस्तावेज़ और कीमतें जाँचीं। नीचे दी गई चयन-विधि और कार्यपत्रक प्रस्ताव हैं; हमने मॉडल चलाए या किसी प्रोडक्शन वर्कलोड को मापा नहीं है।

## बड़ा बदलाव

- **क्या बदला:** OpenAI अब GPT-6 परिवार को अलग-अलग वर्कलोड के विकल्पों के रूप में पेश करता है, जिनमें reasoning effort को समायोजित किया जा सकता है और कई चरणों वाले काम के लिए टूल उपलब्ध हैं। टीमें एक ही मॉडल सेटिंग से हर काम कराने के बजाय वर्कफ़्लो के हर हिस्से को अलग ढंग से विन्यस्त कर सकती हैं।
- **यह क्यों अहम है:** डेवलपर माप सकता है कि केंद्रित जानकारी-निष्कर्षण के चरण में Luna पर्याप्त है या नहीं, coding या research के लिए Sol उचित है या नहीं, और Astra की अतिरिक्त क्षमता अपनी कीमत वसूल करती है या नहीं। जवाब पूरे किए गए कार्यों, latency और कुल वर्कफ़्लो लागत पर निर्भर करता है, जिसमें टूल का उपयोग और असफल प्रयास भी शामिल हैं।
- **किस पर नज़र रखें:** लंबे कार्यों के लिए स्पष्ट handoff और जाँच चाहिए। काम चलते समय steering से निर्देश बदले जा सकते हैं, जबकि asynchronous टूल-नतीजों और सौंपे गए काम को अंतिम जवाब स्वीकार करने से पहले फिर से मिलाना और सत्यापित करना पड़ता है।

## काम के आधार पर चुनें, फिर पूरे वर्कफ़्लो को मापें

वास्तविक कार्यों का प्रतिनिधि समूह और हर काम के लिए स्वीकृति-नियम तय करके शुरू करें। OpenAI मौजूदा मॉडल व्यवहार, टूल कॉल और stateful काम के लिए [Responses API](https://developers.openai.com/api/docs/guides/deployment-checklist) की सिफ़ारिश करता है। API परियोजना, credentials, billing access और उस परियोजना के लिए उपलब्ध मॉडल पहले से होना ज़रूरी है। मॉडल पृष्ठों पर free-tier सहायता सूचीबद्ध नहीं है; rate limits उपयोग-स्तर पर निर्भर हैं। विस्तार की योजना बनाने से पहले खाते की वास्तविक पहुँच और सीमाएँ जाँचें।

| मॉडल को सौंपा गया काम | शुरुआती विकल्प | शुरुआती effort | कब आगे बढ़ाएँ या बदलें |
| --- | --- | --- | --- |
| बार-बार होने वाला जानकारी-निष्कर्षण, वर्गीकरण या स्पष्ट उत्तर वाला संरचित सारांश | `gpt-6-luna` | नियमित काम के लिए Low; इसके Medium default से तुलना करें | गलतियों की दर या समीक्षा-समय टीम की सीमा से बढ़ जाए |
| Coding, research, टूल का इस्तेमाल या विशेषज्ञ निर्णय का चरण | `gpt-6.1-sol` | Medium default; कठिन मामलों के लिए High जाँचें | उचित input और निर्देशों के बावजूद प्रतिनिधि कार्य विफल हों |
| सबसे कठिन reasoning या समीक्षा का चरण, जहाँ गुणवत्ता निर्णायक हो | `gpt-6-astra` | समान मामलों पर Medium और High की तुलना करें | तभी रखें जब मापा गया लाभ अतिरिक्त लागत और समय को उचित ठहराए |

तालिका OpenAI की [मॉडल मार्गदर्शिका](https://openai.com/index/practical-guide-building-gpt-6/) और [मॉडल पृष्ठों](https://developers.openai.com/api/docs/models/compare) को मूल्यांकन शुरू करने के बिंदुओं में बदलती है। API मॉडल ID और समर्थित effort सेटिंग जाँचें: Astra और GPT-6.1 Sol में Low से Max तक विकल्प हैं; Luna में None भी है। GPT-6.1 Sol में None और Minimal उपलब्ध नहीं हैं। OpenAI कहता है कि High पर्याप्त न हो तो जहाँ समर्थित हो Extra High या Max आज़माएँ। एक ही कार्य-समूह पर effort सेटिंग की तुलना करें, क्योंकि गुणवत्ता, अवधि और token उपयोग साथ-साथ बदल सकते हैं।

Standard processing और 272,000 तक input tokens वाले prompts के लिए प्रति दस लाख tokens की मौजूदा text दरें हैं:

| मॉडल | Input | Cached input | Cache write | Output |
| --- | --- | --- | --- | --- |
| GPT-6 Luna | $0.10 | $0.01 | $0.125 | $0.50 |
| GPT-6.1 Sol | $2.00 | $0.10 | $2.50 | $10.00 |
| GPT-6 Astra | $10.00 | $1.00 | $12.50 | $50.00 |

स्रोत: [Luna](https://developers.openai.com/api/docs/models/gpt-6-luna), [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol) और [Astra](https://developers.openai.com/api/docs/models/gpt-6-astra) मॉडल पृष्ठ। 272,000 से अधिक input tokens वाले अनुरोध पर पूरे अनुरोध के लिए ऊँची दरें लागू होती हैं। अन्य processing mode, जहाँ उपलब्ध हो regional processing, और कुछ टूल बिल बदलते हैं। तीनों पृष्ठ 1,050,000-token context window और अधिकतम 128,000-token output बताते हैं; बड़ी window क्षमता की सीमा है, हर उपलब्ध दस्तावेज़ भेजने का कारण नहीं।

पूरे काम-पथ की लागत आँकें: input, cached input, cache writes, output, टूल शुल्क, दोबारा कोशिश और लंबे context का कोई अतिरिक्त शुल्क। कुल को उसी समीक्षा-नियम के तहत स्वीकार किए गए कार्यों की संख्या से भाग दें। फिर उपयोगकर्ता को दिखने वाले चरण और पूरे वर्कफ़्लो की latency की तुलना करें। केवल इकाई-दर से टीम यह नहीं जान सकती कि सफल नतीजे के लिए कौन-सा रास्ता सबसे सस्ता है।

## टूल जोड़ने से पहले काम और output तय करें

हर चरण के लिए स्पष्ट input, अपेक्षित पाठक या अगला उपयोगकर्ता, अनुमत स्रोत और टूल, सीमाएँ तथा पूरा होने की शर्त दें। OpenAI की मार्गदर्शिका यह भी कहती है कि टीम बताए कि मॉडल कौन-से निर्णय ले सकता है और किनके लिए व्यक्ति की मंज़ूरी चाहिए। परियोजना के निर्देश, skills और prompts में उन सीमाओं के बारे में एकरूपता रखें।

मशीन द्वारा पढ़े जा सकने वाले output के लिए पहले से fields और मान्य मान तय करें, फिर काम के अनुरूप schema हो तो [Structured Outputs मार्गदर्शिका](https://developers.openai.com/api/docs/guides/structured-outputs) इस्तेमाल करें। सही ढाँचे को एक जाँच मानें; field schema के अनुरूप होकर भी तथ्यात्मक रूप से ग़लत हो सकता है। यदि output किसी व्यक्ति को सौंपना है, तो नतीजा, इस्तेमाल किए गए प्रमाण, की गई जाँच और अनसुलझे मुद्दे शामिल करना अनिवार्य करें। मूल input और टीम के स्वीकृति-नियम के अनुसार नतीजे की समीक्षा करें।

 मूल्यांकन में task details बदलने से पहले स्थिर निर्देश और साझा संदर्भ-सामग्री रखें, जब आप [prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching) जाँचें। दोबारा उपयोग से नियमित input लागत घट सकती है, पर अनुमान में cache write और आगे का context भी शामिल होना चाहिए। BIG CHANGE की [पहले की prompt-cache मार्गदर्शिका](https://bigchange.ai/blog/gpt-6-prompt-caching-agent-context-costs) cache diagnostics विस्तार से देखती है।

## लंबे काम को निरीक्षण योग्य रखें

OpenAI की [2 अक्टूबर की मार्गदर्शिका](https://openai.com/index/practical-guide-building-gpt-6/) में बीच में steering, asynchronous tool call और स्वतंत्र काम के लिए समानांतर subagent का वर्णन है। Responses WebSocket API के ज़रिए भेजा गया सुधार कतार में लगता है; वह पूरे हो चुके काम वापस नहीं करता और न पहले से चल रहे टूल को रोकता है। Asynchronous टूल असंबंधित काम जारी रख सकता है, लेकिन निर्भर काम को उसके नतीजे तक रुकना होगा। Responses API में GPT-6.1 Sol के लिए multi-agent सहायता फिलहाल beta में है।

कई चरणों वाले run के लिए task ID, चुना हुआ मॉडल और effort, मौजूदा चरण, tool call और result ID, मंज़ूरियाँ तथा अंतिम जवाब के पीछे के प्रमाण सहेजें। पहले से तय करें कि timeout, विफल tool call, बदले हुए निर्देश या दोहराए गए नतीजे के बाद क्या होगा। context बढ़ने पर [compaction](https://developers.openai.com/api/docs/guides/compaction) आगे ले जाई जाने वाली सामग्री घटा सकता है; जारी run में वास्तव में क्या बचा है, जाँचें। OpenAI का [background mode](https://developers.openai.com/api/docs/guides/background) एक अनुरोध से अधिक चलने वाले कामों के लिए एक और दर्ज विकल्प है। काम की अवधि और पुनर्प्राप्ति की ज़रूरत के मुताबिक इन नियंत्रणों को चुनें।

OpenAI की मार्गदर्शिका जहाँ संभव हो सीधे API या connected tool से चरण पूरा करने और ज़रूरत पड़ने पर screen interaction लेने की सलाह देती है। BIG CHANGE की [Agents API browser-task मार्गदर्शिका](https://bigchange.ai/blog/openai-agents-api-computer-use-browser-guide) computer-use interface और उसकी निगरानी का रास्ता बताती है।

## ऐसा कार्यपत्रक जिसे टीम दोहरा सके

हर विकल्प के लिए समान मामले और समीक्षा-नियम इस्तेमाल करें। यह प्रस्तावित मूल्यांकन-विधि है; BIG CHANGE ने इसमें कोई नतीजा दर्ज या परीक्षण नहीं किया है।

| हर मामले और विकल्प के लिए दर्ज करें | रखने योग्य प्रविष्टि |
| --- | --- |
| कार्य और अपेक्षित परिणाम | वास्तविक input ID, output की ज़रूरतें, अनुमत टूल, स्वीकृति-नियम |
| विन्यास | API model ID, effort, processing mode, prompt संस्करण, schema या output अनुबंध |
| परिणाम | स्वीकृत, अस्वीकृत या समीक्षा चाहिए; विफलता का कारण; समीक्षक |
| समय | शुरू से अंत तक की अवधि और उपयोगकर्ता को दिखने वाले चरण की अवधि |
| उपयोग और शुल्क | Input, cached input, cache-write और output tokens; टूल शुल्क; दोबारा कोशिश; लंबे context या regional processing का अतिरिक्त शुल्क |
| निर्णय | प्रयास किए गए कामों में से स्वीकृत काम; प्रति स्वीकृत काम कुल शुल्क; अनसुलझे विफलता-प्रकार |

आसान और कठिन मामले, बिगड़े हुए input और बीच में रुके हुए tool चरण शामिल करें, जिनसे वास्तविक वर्कफ़्लो का सामना होता है। मॉडल की तुलना करते समय मामले स्थिर रखें, फिर prompt या टूल-अनुमति बदलने के बाद दोहराएँ। विफलताओं को प्रकार के अनुसार देखें: प्रमाण न होना, ग़लत field, tool error, छूटा निर्देश या ऐसा जवाब जिसे व्यक्ति को सुधारना पड़े। चरण को दूसरे मॉडल पर तभी ले जाएँ जब समान स्वीकृति-नियम उपयोगी लाभ दिखाए। अधिक दोबारा काम कराने वाला सस्ता मॉडल प्रति स्वीकृत काम महँगा पड़ सकता है; पृष्ठभूमि के चरण में धीमा मॉडल स्वीकार्य हो सकता है, पर interactive चरण में नहीं।

रिलीज़ से पहले परियोजना की वास्तविक rate और खर्च सीमाएँ, data नियंत्रण, timeout, retry व्यवहार, निगरानी तथा मानव-मंज़ूरी की सीमाएँ OpenAI की [तैनाती जाँच-सूची](https://developers.openai.com/api/docs/guides/deployment-checklist) से मिलाएँ। रिलीज़ के बाद नमूना-समीक्षा का रास्ता बनाए रखें और model alias, prompt, टूल या वर्कलोड बदलने पर कार्यपत्रक फिर चलाएँ। उसी task data से routing का निर्णय लें।

## स्रोत और आगे पढ़ें

- [OpenAI की 2 अक्टूबर की GPT-6 परिवार मार्गदर्शिका](https://openai.com/index/practical-guide-building-gpt-6/) में मॉडल, effort, निर्देश और लंबे समय तक चलने वाले वर्कफ़्लो पर विक्रेता की सिफ़ारिशें दी गई हैं। यह BIG CHANGE के परीक्षण-नतीजे या किसी एक टीम के वर्कलोड के लिए सर्वोत्तम मॉडल नहीं बताती।
- [GPT-6 Luna](https://developers.openai.com/api/docs/models/gpt-6-luna), [GPT-6.1 Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol) और [GPT-6 Astra](https://developers.openai.com/api/docs/models/gpt-6-astra) के दस्तावेज़ यहाँ इस्तेमाल किए गए API ID, समर्थित effort, context, कीमतें और tier-आधारित सीमाएँ बताते हैं। मौजूदा खाते की पहुँच और billing फिर भी जाँचनी होगी।
- [OpenAI की API तैनाती जाँच-सूची](https://developers.openai.com/api/docs/guides/deployment-checklist) प्रतिनिधि कार्यों का मूल्यांकन, Responses API विन्यस्त करने और प्रोडक्शन नियंत्रणों की योजना के सुझाव देती है। ऊपर का कार्यपत्रक BIG CHANGE की प्रस्तावित विधि है, विक्रेता का benchmark नहीं।
- [Structured Outputs](https://developers.openai.com/api/docs/guides/structured-outputs), [compaction](https://developers.openai.com/api/docs/guides/compaction) और [background mode](https://developers.openai.com/api/docs/guides/background) वर्कफ़्लो में बताए गए विशिष्ट interface समझाते हैं।

## Sources

- [GPT-6 परिवार के लिए मॉडल मार्गदर्शिका](https://openai.com/index/practical-guide-building-gpt-6/) — मॉडल की भूमिकाओं, reasoning effort, निर्देश और output डिज़ाइन, caching, steering, async call और beta multi-agent सहायता की प्राथमिक विक्रेता-मार्गदर्शिका। इसकी सिफ़ारिशें स्थानीय कार्य-सफलता या लागत स्थापित नहीं करतीं।
- [GPT-6 Astra मॉडल दस्तावेज़](https://developers.openai.com/api/docs/models/gpt-6-astra) — आधिकारिक model ID, समर्थित effort, context और अधिकतम output, modality, Standard token दरें, लंबे context की मूल्य-सीमा और उपयोग-स्तर की सीमाएँ। दरें बदल सकती हैं।
- [GPT-6.1 Sol मॉडल दस्तावेज़](https://developers.openai.com/api/docs/models/gpt-6.1-sol) — मौजूदा 6.1 Sol ID, default और समर्थित reasoning स्तर, Responses API tool calling, context, output, दरें, क्षेत्रीय व लंबे-context की शर्तें और tier-आधारित सीमाओं की पुष्टि करता है।
- [GPT-6 Luna मॉडल दस्तावेज़](https://developers.openai.com/api/docs/models/gpt-6-luna) — केंद्रित कार्यों के लिए स्थिति, None से Max तक effort, Responses टूल सहायता, context/output सीमाएँ, Standard दरें और उपयोग-स्तर की सीमाओं की पुष्टि करता है।
- [API तैनाती जाँच-सूची](https://developers.openai.com/api/docs/guides/deployment-checklist) — Responses, मॉडल और effort चयन, प्रतिनिधि मूल्यांकन, टूल/context नियंत्रण, विश्वसनीयता और निगरानी पर OpenAI की production सिफ़ारिशें। प्रस्तावित कार्यपत्रक को सत्यापित नहीं करती।
- [संरचित मॉडल output](https://developers.openai.com/api/docs/guides/structured-outputs) — आधिकारिक output-schema interface। ढाँचा अनुरूप होने से तथ्यात्मक शुद्धता स्थापित नहीं होती; लेख अलग समीक्षा की माँग करता है।
- [Prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching) — cache व्यवहार और स्थिर prefix पर आधिकारिक मार्गदर्शन, संक्षेप में संदर्भित। इस विषय के विस्तृत cache diagnostics पर BIG CHANGE का पिछला लेख #29 केंद्रित है।
- [Compaction](https://developers.openai.com/api/docs/guides/compaction) — लंबी बातचीत का context घटाने का आधिकारिक तरीका; लेख पूर्ण संरक्षण मान लेने के बजाय बची हुई स्थिति जाँचने की सलाह देता है।
- [Background mode](https://developers.openai.com/api/docs/guides/background) — लंबे समय तक चलने वाले काम के लिए Responses mode का दस्तावेज़; यहाँ केवल उपलब्ध निरंतरता-विकल्प के रूप में उल्लेखित।