जिस बिल से यह सब शुरू हुआ वह एक ही दोपहर के लिए $312 था। एक डेवलपर, एक Octomind सेशन, एक मॉडल हर काम करता हुआ: फ़ाइलें पढ़ना, grep चलाना, diff का सार बनाना, यह तय करना कि कॉन्टेक्स्ट कब कम्प्रेस करना है, और असल में कठिन तर्क करना। यह सब एक फ्रंटियर मॉडल पर, क्योंकि जब आप चाहते हैं कि एजेंट अच्छा हो तो यही चुनते हैं।

फिर OpenRouter एक रिफ़ैक्टरिंग के बीच में 429 लौटाने लगा, और मैंने देखा कि एजेंट एक रेट-लिमिट पर अटका रहा, ऐसा कुछ करते हुए जो दसवें दाम का मॉडल बिल्कुल सही कर देता। उसी क्षण स्पष्ट बात समझ में आई: एजेंट जो करता है उसका अधिकांश कठिन नहीं है। फ़ाइलें सूचीबद्ध करना कठिन नहीं है। एक धुँधले काम को साफ़ करना कठिन नहीं है। यह तय करना कि सेशन कम्प्रेस करने लायक बड़ा है या नहीं, कठिन नहीं है। रिसर्च के एक डंप को पढ़कर तीन प्रासंगिक फ़ाइलें निकालना कठिन नहीं है।

इनमें से किसी के लिए भी आपको अपने सबसे अच्छे मॉडल की ज़रूरत नहीं है। आपको इसकी ज़रूरत शायद दस प्रतिशत कॉल्स के लिए है — रिव्यू, पेचीदा डिज़ाइन निर्णय, वह diff जो ऑथेंटिकेशन को छूता है। बाकी नब्बे प्रतिशत भारी काम है, और भारी काम ठीक वही जगह है जहाँ सस्ते और लोकल मॉडल चमकते हैं।

यह कहानी एक ही Octomind एजेंट को कई मॉडलों में बाँटने की है, उन्हीं असली कॉन्फ़िग कीज़ पर आधारित जो यह शिप करता है। अंत तक आपके पास एक चालू मल्टी-मॉडल सेटअप होगा, मॉडल चुनने की चीट शीट होगी, और उस सवाल का साफ़ जवाब होगा जो मायने रखता है: क्या कहाँ रखना है।

एक स्ट्रिंग, कोई भी बैकएंड

Octomind हर प्रोवाइडर से एक ही लाइब्रेरी के ज़रिए बात करता है — octolib, जिसके बारे में मैंने पहले लिखा था। octolib जो देता है, जो यह सब संभव बनाता है, वह यह है कि हर मॉडल का नाम एक ही तरह रखा जाता है: एक provider:model स्ट्रिंग।

model = "anthropic:claude-sonnet-5"
model = "openai:gpt-5.5"
model = "deepseek:deepseek-chat"
model = "openrouter:google/gemini-3.5-flash"
model = "ollama:glm-5"

वही फ़ील्ड, वही आकार, जहाँ कहीं भी मॉडल कॉन्फ़िगर होता है। octolib प्रीफ़िक्स पार्स करता है, सही बैकएंड पर रूट करता है, और रिस्पॉन्स को नॉर्मलाइज़ करता है — टोकन उपयोग, लागत, स्ट्रक्चर्ड आउटपुट — ताकि बाकी Octomind को परवाह न हो कि किस वेंडर ने जवाब दिया।

मौजूदा रिलीज़ तक octolib जिन प्रोवाइडर प्रीफ़िक्सों को पहचानता है, वे हैं:

openrouter  openai      anthropic   google      amazon
cloudflare  deepseek    cerebras    groq        together
fireworks   nvidia      minimax     moonshot    zai
byteplus    featherless octohub     ollama      local

बीस नेटवर्क प्रोवाइडर, साथ ही लोकल CLI-आधारित एजेंटों के लिए एक विशेष cli मेटा-प्रोवाइडर (इस पर नीचे और)। moonshot और kimi एक ही प्रोवाइडर के उपनाम हैं। नए प्रोवाइडर octolib में आते हैं और Octomind में अपने आप उपलब्ध हो जाते हैं — Octomind के नए रिलीज़ की ज़रूरत के बिना।

वैसे, API कीज़ केवल एनवायरनमेंट से आती हैं। आप उन्हें कॉन्फ़िग फ़ाइल में नहीं रख सकते; वह सुरक्षा के लिए हटा दिया गया था। आप export OPENROUTER_API_KEY=... करते हैं (या वर्किंग डायरेक्टरी में एक .env रखते हैं), और octomind config --show आपको बताता है कि उसने कौन-सी कीज़ पकड़ीं और वे कहाँ से आईं। एक OpenRouter की एक ही प्रीफ़िक्स के ज़रिए आपको ज़्यादातर कैटलॉग देती है; विशिष्ट प्रोवाइडर कीज़ बाकी देती हैं।

मॉडल कहाँ चुना जाता है

मॉडलों में काम बाँटने से पहले, आपको वे चार जगहें जाननी होंगी जहाँ मॉडल सेट किया जा सकता है, और जब एक से ज़्यादा लागू हों तो कौन जीतता है। Octomind प्रभावी मॉडल को इस क्रम में तय करता है, सबसे ऊँची प्राथमिकता पहले:

CLI --model  >  role.model  >  config.model

साथ ही tap एजेंटों के लिए एक चौथी सीवन: एक [taps] एंट्री किसी विशिष्ट tap-एजेंट टैग के लिए config.model को ओवरराइड करती है।

  • config.model — रूट डिफ़ॉल्ट। ताज़ा जनरेट की गई कॉन्फ़िग में यह OpenRouter से रूट होने वाला Sonnet-क्लास Claude होता है — आज आप openrouter:anthropic/claude-sonnet-5 सेट करेंगे। जब इससे ज़्यादा विशिष्ट कुछ सेट नहीं होता तो सब कुछ इसी पर वापस आ जाता है।
  • role.model — प्रति-रोल ओवरराइड। यह मुख्य लीवर है। हर रोल अपना मॉडल नाम दे सकता है, और किसी रोल का मॉडल रूट डिफ़ॉल्ट के ऊपर सीधे माना जाता है।
  • [taps] ओवरराइड — tap एजेंटों के लिए (वे category:variant एजेंट जो आप किसी रजिस्ट्री से इंस्टॉल करते हैं), आप एजेंट के मेनिफ़ेस्ट को छुए बिना प्रति टैग एक मॉडल पिन कर सकते हैं:
[taps]
"developer:general" = "anthropic:claude-sonnet-5"
"octomind:assistant" = "openai:gpt-5.5"
  • CLI --model — एक रन के लिए सब पर जीतता है: octomind run -m anthropic:claude-sonnet-5। और सेशन के बीच में आप /model deepseek:deepseek-chat से लाइव बदल सकते हैं, या /effort high से रीज़निंग एफ़र्ट को थोड़ा समायोजित कर सकते हैं।

तो रणनीति सीधी है: config.model में एक समझदार डिफ़ॉल्ट चुनें, फिर वहाँ प्रति-रोल ओवरराइड करें जहाँ कोई विशिष्ट काम एक अलग मॉडल का हक़दार हो। ज़्यादातर बचत रोल लेयर से आती है।

रोल: मॉडल चुनने की इकाई

Octomind में एक रोल व्यवहार का एक नामित बंडल है: एक सिस्टम प्रॉम्प्ट, एक temperature, MCP सर्वरों और टूल अनुमतियों का एक सेट — और, वैकल्पिक रूप से, एक मॉडल। हर सेशन एक रोल के साथ चलता है। रोल तय करता है कि एजेंट क्या कर सकता है और कौन-सा मॉडल यह करता है।

शिप होने वाली कॉन्फ़िग पहले से ही वही करती है जो यह पोस्ट उपदेश देता है। यह चार सादे रोल परिभाषित करती है, और उनमें से तीन जानबूझकर मुख्य से सस्ते मॉडलों पर चलते हैं — यहाँ मॉडल स्ट्रिंग्स मौजूदा पीढ़ी के हिसाब से अपडेट करके दिखाई गई हैं:

# हल्की क्वेरी रिफ़ाइनमेंट — किसी धुँधले काम को साफ़ करना। कोई टूल नहीं।
[[roles]]
name = "task_refiner"
model = "openrouter:openai/gpt-5.4-mini"
# ...

# टोह — कॉन्टेक्स्ट जुटाना, फ़ाइलें पढ़ना, निष्कर्ष बताना।
[[roles]]
name = "task_researcher"
model = "openrouter:google/gemini-3.5-flash"
# ...

# सेशन-इतिहास कम्प्रेशन — सार बनाना और घटाना।
[[roles]]
name = "reduce"
model = "openrouter:openai/gpt-5-mini"
# ...

उन मॉडल चयनों को एक डिज़ाइन बयान की तरह पढ़ें। किसी धुँधले अनुरोध को रिफ़ाइन करना एक छोटे, तेज़ मॉडल (gpt-5.4-mini) का काम है। बहुत सारी फ़ाइलें पढ़ने वाली रिसर्च को एक बड़ा, सस्ता कॉन्टेक्स्ट विंडो चाहिए (gemini-3.5-flash)। इतिहास कम्प्रेस करना एक स्ट्रक्चर्ड समराइज़ेशन काम है जिसे एक छोटा रीज़निंग मॉडल अच्छे से संभालता है (gpt-5-mini)। इनमें से किसी को फ्रंटियर मॉडल की ज़रूरत नहीं है, और डिफ़ॉल्ट कॉन्फ़िग इन पर एक बर्बाद नहीं करती।

अपने रोल आप उसी तरह परिभाषित करते हैं। model को छोड़कर हर फ़ील्ड अनिवार्य है — system, welcome, temperature, top_p और top_k सबका मौजूद होना ज़रूरी है वरना कॉन्फ़िग पार्स नहीं होगी:

# कोडबेस को छानने के लिए सस्ता, विस्तृत कॉन्टेक्स्ट
[[roles]]
name = "researcher"
model = "openrouter:google/gemini-3.5-flash"
temperature = 0.3
top_p = 0.7
top_k = 20
system = "You gather context and report findings. You do not modify files."
welcome = ""
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view"]

# जहाँ मायने रखता है वहाँ परिशुद्धता — रिव्यू और कठिन निर्णय
[[roles]]
name = "reviewer"
model = "anthropic:claude-opus-4-8"
temperature = 0.2
top_p = 0.7
top_k = 20
system = "You review changes for correctness, security, and edge cases."
welcome = "Reviewer ready."
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view", "ast_grep"]

अब octomind run researcher रिपॉज़िटरी को एक सस्ते बड़े-कॉन्टेक्स्ट मॉडल पर छानता है, और octomind run reviewer महँगे मॉडल को केवल उस काम के लिए बाहर लाता है जो इसे कमाता है। सेशन के बीच में /role reviewer से इनके बीच बदलें। वही एजेंट, वही सेशन, दो मॉडल — काम के अनुसार चुने हुए।

लेयर: एक ही पास में मॉडलों की शृंखला

रोल आपको प्रति सेशन एक मॉडल चुनने देते हैं। लेयर सिस्टम को एक ही फ़्लो के भीतर अपने आप मॉडलों की शृंखला बनाने देते हैं।

एक लेयर एक ACP-इन्वोकेबल चरण है जो अपने command फ़ील्ड के ज़रिए एक रोल को संदर्भित करता है। रोल मॉडल, सिस्टम प्रॉम्प्ट और टूल ले जाता है; लेयर बताता है कि बातचीत उस चरण में कैसे जाती और बाहर आती है। फ़ील्ड कम हैं और सभी मोड फ़ील्ड अनिवार्य हैं:

[[layers]]
name = "analysis"
description = "Detailed analysis of code, systems, or requirements"
command = "octomind acp analysis"   # spawns the `analysis` role over ACP
input_mode = "last"                 # last | all | summary
output_mode = "append"              # none | append | replace | last | restart
output_role = "assistant"

चूँकि लेयर एक रोल की ओर इशारा करता है और रोल मॉडल ले जाता है, एक शृंखला में हर लेयर एक अलग मॉडल पर चल सकता है। एक सस्ता मॉडल कॉन्टेक्स्ट जुटाता है, अपना आउटपुट अगले चरण को सौंपता है, एक मजबूत मॉडल उस पर तर्क करता है। वही LayerConfig स्ट्रक्ट [[commands]] को भी पीछे से चलाता है — वे लेयर जिन्हें आप /run <name> से इंटरैक्टिव रूप से ट्रिगर करते हैं — इसलिए शिप होने वाला reduce कमांड स्वयं एक लेयर है जो माँग पर इतिहास कम्प्रेस करने के लिए सस्ते reduce रोल को चलाता है।

मानसिक मॉडल: रोल जवाब देते हैं "इस सेशन के लिए कौन-सा मॉडल", लेयर जवाब देते हैं "इस चरण के लिए कौन-सा मॉडल"। साथ में वे आपको ऑर्केस्ट्रेशन कोड लिखे बिना एक ही अनुरोध को सस्ते-फिर-महँगे पाइपलाइन के ज़रिए रूट करने देते हैं — यह सब TOML है।

ध्यान दें: एक [[layers]] एंट्री को [[roles]] में एक मिलान वाले रोल की ज़रूरत होती है। मॉडल रोल में रहता है, लेयर में कभी नहीं। अगर आप किसी लेयर पर मॉडल सेट करना चाह रहे हैं, तो आप रोल ढूँढ रहे हैं।

कम्प्रेशन का अपना मॉडल है — और वह सस्ता होना चाहिए

एक और मॉडल चयन है जिसे चूकना आसान है और जो तुरंत अपनी कीमत वसूल कर लेता है। Octomind लंबे सेशनों को अपने आप कम्प्रेस करता है, और कम्प्रेशन को चलाने वाला निर्णय-और-सार कॉल अपने अपने कॉन्फ़िगर किए मॉडल पर चलता है, जो आपके मुख्य से अलग है:

[compression.decision]
model = "openai:gpt-5-mini"   # डिज़ाइन से सस्ता
max_tokens = 16000
temperature = 0.3

शिप होने वाला डिफ़ॉल्ट openai:gpt-5-mini एक वजह से है: यह कॉल एक लंबे सेशन में बार-बार दागा जाता है, और आप नहीं चाहते कि एक फ्रंटियर मॉडल यह तय करे कि कम्प्रेस करना है या नहीं। अगर आप पहले से Anthropic पर हैं तो anthropic:claude-haiku-4-5 एक अच्छा विकल्प है। बात इस पूरे पोस्ट की तरह वही है — एक नियमित, स्ट्रक्चरल काम को एक नियमित, सस्ता मॉडल मिलता है, और बचत जमा होती है क्योंकि यह अक्सर चलता है।

कम्प्रेशन इंजन स्वयं लागत-जागरूक है: कम्प्रेस करने से पहले, यह प्रोवाइडर से लिए गए प्रति-मॉडल मूल्य का उपयोग करके शुद्ध लाभ की गणना करता है, और जब कम्प्रेशन बचत से ज़्यादा खर्च करवाएगा तब इसे छोड़ देता है। एक मुफ़्त/शून्य-मूल्य वाले सेशन मॉडल के लिए — मान लीजिए एक लोकल Ollama मॉडल — यह हमेशा कम्प्रेस करता है, क्योंकि लागत अप्रासंगिक है और आप केवल कॉन्टेक्स्ट को संभालने योग्य रखना चाहते हैं। जो अगली बात की ओर बढ़िया मोड़ है।

थोक काम के लिए लोकल मॉडल

हर कॉल को आपकी मशीन छोड़ने की ज़रूरत नहीं है। Octomind लोकल मॉडलों से दो तरीकों से बात करता है।

Ollama और OpenAI-संगत एंडपॉइंट ollama: और local: प्रीफ़िक्सों के ज़रिए:

model = "ollama:glm-5"
model = "local:my-finetune"   # set LOCAL_API_URL to your endpoint

ollama: आपके लोकल Ollama डेमन की ओर इशारा करता है; local: LOCAL_API_URL के ज़रिए किसी भी OpenAI-संगत सर्वर की ओर इशारा करता है। इनमें से कोई भी वही provider:model स्ट्रिंग है जो बाकी कॉन्फ़िग उपयोग करती है — इसे किसी रोल के model फ़ील्ड में डालें और वह रोल लोकल चलता है।

लोकल CLI एजेंट विशेष cli: मेटा-प्रोवाइडर के ज़रिए, जो किसी नेटवर्क API को कॉल करने के बजाय आपकी मशीन पर एक कमांड-लाइन एजेंट चलाता है:

model = "cli:codex/gpt-5.2-codex"

प्रारूप cli:<backend>/<model> है, जहाँ बैकएंड codex, claude, cursor, gemini या एक सामान्य कमांड में से एक है। चूँकि यह एक लोकल CLI के ज़रिए चलता है, किसी API की की ज़रूरत नहीं — Octomind cli: मॉडलों के लिए क्रेडेंशियल वैलिडेशन पूरी तरह छोड़ देता है। व्यवहार बैकएंड-विशिष्ट एनवायरनमेंट वैरिएबल से समायोजित होता है (codex बैकएंड के लिए, CODEX_COMMAND, CODEX_REASONING_EFFORT वगैरह)।

लोकल मॉडल कहाँ अपनी रोटी कमाते हैं: उच्च-मात्रा, कम-दाँव वाला काम जहाँ लेटेंसी और प्राइवेसी गुणवत्ता के आख़िरी कुछ अंकों से ज़्यादा मायने रखती है। थोक समराइज़ेशन, वर्गीकरण, पहली-पास रिसर्च, कुछ भी जिसे आप हज़ारों बार चलाते हैं। एक researcher रोल पर एक लोकल मॉडल रखें और टोह वाला चरण आपको प्रति टोकन कुछ नहीं पड़ता। क्लाउड मॉडल को reviewer रोल पर रखें जहाँ गुणवत्ता का अंतर वाक़ई दिखता है।

OctoHub: नीचे रूटिंग और फ़ॉलबैक

अब तक रूटिंग प्रति-रोल और प्रति-लेयर है, आपकी Octomind कॉन्फ़िग में तय। पर उसके नीचे एक लेयर है — एक असली प्रॉक्सी — और वहीं फ़ॉलबैक, लोड-बैलेंसिंग और केंद्रीकृत हिसाब-किताब रहते हैं।

OctoHub हमारा ओपन-सोर्स LLM प्रॉक्सी है। Octomind के लिए यह बस एक और प्रोवाइडर है: आप octohub:my-model जैसा मॉडल सेट करते हैं, Octomind को OctoHub एंडपॉइंट की ओर इशारा करते हैं, और Octomind की ओर से यह एक और provider:model स्ट्रिंग है। उस स्ट्रिंग के पीछे OctoHub जो करता है, वहीं यह उपयोगी होता है। इसकी कॉन्फ़िग एक छोटे मॉडल नाम को पूरी तरह योग्य provider:model लक्ष्यों की एक सूची से मैप करती है, और प्रति अनुरोध एक को बेतरतीब चुनती है:

[models]
# एक उपनाम, कई असली बैकएंड — प्रति अनुरोध बेतरतीब चयन = सरल लोड बैलेंसिंग
"fast" = ["minimax:minimax-m3", "ollama:minimax-m3"]

वह एकल मैपिंग आपको लोड-बैलेंसिंग और फ़ेलओवर का एक नरम रूप देती है: अगर एक बैकएंड रेट-लिमिटेड या डाउन है, तो सूची के बाक़ी ट्रैफ़िक सोख लेते हैं। OctoHub पूर्ण अनुरोध/प्रतिक्रिया लॉगिंग, मल्टी-टेनेंट API कीज़ (ताकि हर डेवलपर या सेवा को अपनी की मिले और उसका उपयोग अलग से ट्रैक हो) और प्रति की व समय-बकेट के अनुसार समेकित उपयोग एनालिटिक्स भी करता है। बहुत सारे एजेंट चलाने वाली टीम के लिए, यह "पिछले महीने हमने LLM पर $4k खर्च किए" और "ऑथ सेवा पर रिव्यू पाइपलाइन ने पिछले महीने $4k खर्च किए, यह रही की के अनुसार ब्रेकडाउन" के बीच का अंतर है।

श्रम का बँटवारा साफ़ है:

  • octolib वह लाइब्रेरी है जो जानती है कि हर प्रोवाइडर से कैसे बात करनी है — अनुरोध का आकार, प्रतिक्रिया पार्सिंग, लागत तालिकाएँ।
  • OctoHub वह प्रॉक्सी है जो प्रोवाइडरों के सामने बैठता है और तय करता है कि कोई अनुरोध किस पर जाता है, उसे लॉग करता है, और प्रति की मीटर करता है।
  • Octomind वह एजेंट है जो प्रति रोल और प्रति लेयर तय करता है कि सबसे पहले कौन-सी मॉडल स्ट्रिंग भेजनी है।

आप Octomind को बिना किसी प्रॉक्सी के चला सकते हैं और शुद्ध रूप से रोल और OpenRouter के ज़रिए रूट कर सकते हैं। OctoHub तब जोड़ते हैं जब आप केंद्रीकृत नियंत्रण चाहते हैं: कीज़ घुमाने, ट्रैफ़िक फिर से संतुलित करने, और यह देखने का एक स्थान कि पैसा कहाँ गया।

मॉडल चुनने की चीट शीट

यहाँ बताया है कि मैं वाक़ई हर मॉडल वर्ग को कहाँ रखूँगा। विशिष्ट मॉडल नामों को वर्तमान उदाहरणों की तरह लें, आज्ञाओं की तरह नहीं — इस तिमाही का सही मॉडल अगली तिमाही का सही मॉडल नहीं होगा, पर निर्णय का आकार टिका रहता है।

एजेंट में काम मॉडल वर्ग ठोस उदाहरण क्यों
अंतिम रिव्यू, कठिन डिज़ाइन निर्णय, ऑथ-निकटवर्ती diff फ्रंटियर anthropic:claude-opus-4-8 जिन 10% पर मायने रखता है उनकी गुणवत्ता दाम के लायक है
मुख्य विकास लूप मजबूत, कैश्ड anthropic:claude-sonnet-5 अच्छा कोडिंग + प्रॉम्प्ट कैश लागत को क़ाबू में रखते हैं
रिसर्च / कॉन्टेक्स्ट छानना बड़ा-कॉन्टेक्स्ट, सस्ता openrouter:google/gemini-3.5-flash बहुत फ़ाइलें पढ़ता है, शानदार होने की ज़रूरत नहीं
टास्क रिफ़ाइनमेंट छोटा, तेज़ openrouter:openai/gpt-5.4-mini धुँधले अनुरोध को साफ़ करना — मामूली काम
कम्प्रेशन निर्णय छोटा, सस्ता openai:gpt-5-mini लगातार दागा जाता है; यहाँ कभी फ्रंटियर मॉडल न रखें
सेशन घटाव / सार छोटा रीज़निंग openrouter:openai/gpt-5-mini स्ट्रक्चर्ड समराइज़ेशन, अक्सर चलता है
थोक / उच्च-मात्रा / निजी लोकल ollama:glm-5, cli:codex/gpt-5.2-codex लेटेंसी + प्राइवेसी + प्रति-टोकन शून्य लागत
किफ़ायती क्लाउड फ़ॉलबैक सस्ता नेटिव deepseek:deepseek-chat जब फिर भी असली API चाहिए तब सबसे कम लागत

तालिका के नीचे का नियम: कॉल्स पर इस अनुपात में खर्च करें कि आउटपुट की गुणवत्ता परिणाम को कितना बदलती है। रिव्यू या तो बग पकड़ता है या नहीं — वहाँ खर्च करें। फ़ाइल सूची किसी भी मॉडल से वही वापस आती है — मत खर्च करें।

एक पूरी मल्टी-मॉडल कॉन्फ़िग

सब जोड़ते हुए, यह रही एक कॉन्फ़िग जो काम को चार मॉडलों में बाँटती है — एक सस्ता डिफ़ॉल्ट, एक मजबूत रिव्यूअर, एक लोकल रिसर्चर, और एक सस्ता कम्प्रेशन निर्णय — साथ ही कठोर खर्च-सीमाएँ ताकि कोई बेकाबू लूप आपको चौंका न दे:

# एक OpenRouter की से रूट किया गया सस्ता, सक्षम डिफ़ॉल्ट
model = "openrouter:anthropic/claude-sonnet-5"

# कठोर सीमाएँ — लागू होती हैं, सलाहकारी नहीं
max_request_spending_threshold = 0.50   # USD प्रति अनुरोध, निष्पादन रोकता है
max_session_spending_threshold = 5.00   # USD प्रति सेशन, पूछता/रोकता है

# कम्प्रेशन एक सस्ते मॉडल पर चलता है, मुख्य से अलग
[compression.decision]
model = "openai:gpt-5-mini"
max_tokens = 16000
temperature = 0.3

# उच्च-मात्रा टोह चरण के लिए लोकल मॉडल
[[roles]]
name = "researcher"
model = "ollama:glm-5"
temperature = 0.3
top_p = 0.7
top_k = 20
system = "You gather context and report findings. You do not modify files."
welcome = ""
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view"]

# उस काम के लिए फ्रंटियर मॉडल जो इसे कमाता है
[[roles]]
name = "reviewer"
model = "anthropic:claude-opus-4-8"
temperature = 0.2
top_p = 0.7
top_k = 20
system = "You review changes for correctness, security, and edge cases."
welcome = "Reviewer ready."
[roles.mcp]
server_refs = ["filesystem"]
allowed_tools = ["view", "ast_grep"]

इस पर भरोसा करने से पहले इसे वैलिडेट करें:

octomind config --validate
octomind config --show     # confirms which provider keys were detected

फिर डिफ़ॉल्ट रूप से सस्ता रास्ता चलाएँ और महँगे को केवल तभी बुलाएँ जब आपका इरादा हो:

octomind run researcher              # local model, free per token
octomind run reviewer                # frontier model, on purpose
octomind run -m deepseek:deepseek-chat   # one-off override for a session

देखें कि यह वाक़ई कितना पड़ता है — सेशन अवलोकन के लिए /info और प्रति-अनुरोध ब्रेकडाउन के लिए /report से। पहली बार जब आप इस तरह एक असली काम चलाएँ और देखें कि रिसर्च चरण कुछ नहीं पड़ता जबकि रिव्यू कुछ सेंट पड़ता है, बँटवारा सैद्धांतिक रहना बंद कर देता है।

बँटवारे के बाद क्या बदला

$312 वाली दोपहर अब नहीं होती, और इसलिए नहीं कि हम एजेंट का कम उपयोग करते हैं। रिसर्च और रिफ़ाइनमेंट ट्रैफ़िक सस्ते और लोकल मॉडलों पर चला गया, कम्प्रेशन निर्णय ने एक फ्रंटियर मॉडल पर सवारी करना बंद कर दिया, और महँगा मॉडल अब केवल रिव्यू और सचमुच कठिन निर्णयों के लिए दिखता है। कुल कॉल्स में फ्रंटियर मॉडल का हिस्सा गिरकर लगभग उन्हीं दस प्रतिशत पर आ गया जो उसे हमेशा होना चाहिए था।

रेट-लिमिट के अटकाव भी चले गए, जिसकी मुझे उम्मीद नहीं थी। ट्रैफ़िक को प्रोवाइडरों में फैलाना — कुछ OpenRouter के ज़रिए, कुछ सीधे, कुछ लोकल, कुछ OctoHub की बेतरतीब-चयन मैपिंग के पीछे — का मतलब है कि किसी एक प्रोवाइडर का 429 पूरे सेशन को नहीं रोकता। जो एजेंट पहले एक अपस्ट्रीम की रेट-लिमिट पर जम जाता था अब बस उसके इर्द-गिर्द रूट कर लेता है।

इसमें से किसी के लिए एक फ्रेमवर्क, एक रूटिंग लाइब्रेरी, या ऑर्केस्ट्रेशन कोड की ज़रूरत नहीं पड़ी। यह TOML में provider:model स्ट्रिंग्स, कुछ अतिरिक्त रोल, और एक सस्ता कम्प्रेशन मॉडल है। कठिन हिस्सा वायरिंग नहीं थी — octolib और Octomind के पास यह सब पहले से था। कठिन हिस्सा मानसिकता का बदलाव था: भारी काम के लिए फ्रंटियर दाम चुकाना बंद करें, और अपना सबसे अच्छा मॉडल केवल वहाँ रखें जहाँ आउटपुट की गुणवत्ता वाक़ई बदलती है कि आगे क्या होता है।

अगर आप इन एजेंटों के लिए प्रोजेक्ट-विशिष्ट टूल भी रैप कर रहे हैं, तो अपने रिपॉज़िटरी में कस्टम MCP पैटर्न मल्टी-मॉडल रोल के साथ साफ़-सुथरा जुड़ता है — संकरे टूल और सही-आकार के मॉडल एक ही दिशा में खींचते हैं।

अक्सर पूछे जाने वाले प्रश्न

क्या मुझे OpenRouter चाहिए, या मैं प्रोवाइडरों को सीधे इस्तेमाल कर सकता हूँ?

दोनों। एक OPENROUTER_API_KEY आपको openrouter: प्रीफ़िक्स के ज़रिए ज़्यादातर कैटलॉग देती है, जो सबसे आसान शुरुआत है। या अलग-अलग कीज़ सेट करें (ANTHROPIC_API_KEY, DEEPSEEK_API_KEY, …) और नेटिव प्रीफ़िक्स इस्तेमाल करें। आप एक ही कॉन्फ़िग में दोनों मिला सकते हैं — अलग-अलग रोल पूरी तरह अलग प्रोवाइडरों पर जा सकते हैं।

कॉन्फ़िग संपादित किए बिना मैं मॉडल कैसे बदलूँ?

प्रति रन: octomind run -m anthropic:claude-sonnet-5। सेशन के बीच में: /model deepseek:deepseek-chat। CLI फ़्लैग रोल और कॉन्फ़िग मॉडलों पर जीतता है; स्लैश कमांड लाइव सेशन बदलता है और उसे सहेजता है।

मॉडल ठीक कहाँ तय होता है?

रिज़ॉल्यूशन क्रम CLI --model > role.model > config.model है, साथ ही tap एजेंटों के लिए config.model स्तर पर एक [taps] ओवरराइड फ़िट होता है। एक समझदार config.model डिफ़ॉल्ट सेट करें, फिर उन कामों के लिए प्रति रोल ओवरराइड करें जो एक अलग मॉडल के हक़दार हैं।

क्या एक काम के अलग-अलग चरण अलग-अलग मॉडल इस्तेमाल कर सकते हैं?

हाँ — लेयर इसीलिए हैं। एक लेयर एक रोल को संदर्भित करता है, रोल मॉडल ले जाता है, इसलिए लेयरों की एक शृंखला मॉडलों की एक शृंखला चलाती है। सस्ता मॉडल कॉन्टेक्स्ट जुटाता है, मजबूत मॉडल उस पर तर्क करता है, सब एक ही फ़्लो में।

क्या लोकल मॉडल लागत ट्रैकिंग तोड़ देंगे?

नहीं। एक मुफ़्त या शून्य-मूल्य वाला मॉडल स्पष्ट रूप से संभाला जाता है: लागत ट्रैकिंग शून्य रिपोर्ट करती है, और कम्प्रेशन इंजन ऐसे मॉडलों के लिए हमेशा कम्प्रेस करता है (क्योंकि लागत गेट लागू नहीं होता) ताकि कॉन्टेक्स्ट संभालने योग्य रहे।

OctoHub ऐसा क्या जोड़ता है जो रोल नहीं करते?

रोल आपकी कॉन्फ़िग में रूट करते हैं; OctoHub प्रॉक्सी पर रूट करता है। यह एक उपनाम को कई असली बैकएंड से बेतरतीब लोड-बैलेंसिंग के साथ मैप करता है, हर अनुरोध लॉग करता है, मल्टी-टेनेंट उपयोग ट्रैकिंग के लिए प्रति-की API कीज़ जारी करता है, और एनालिटिक्स समेकित करता है। यह तब चाहिए जब किसी टीम को ट्रैफ़िक फिर से संतुलित करने और खर्च का हिसाब रखने के लिए एक स्थान चाहिए।

बात कभी "सस्ता मॉडल इस्तेमाल करो" नहीं थी। यह "हर कॉल के लिए सही मॉडल इस्तेमाल करो, और रूटिंग को कोड नहीं, कॉन्फ़िग बनने दो" है। Octomind आपको सीवनें देता है — रूट डिफ़ॉल्ट, प्रति-रोल, प्रति-लेयर, प्रति-रन, साथ ही नीचे एक प्रॉक्सी — और एक ही provider:model स्ट्रिंग उन सबको बाँध देती है।

अपना सबसे अच्छा मॉडल वहाँ खर्च करें जहाँ जवाब वाक़ई मायने रखता है। बाक़ी सब को सस्ता चलने दें।

— Don

Octomind Apache-2.0 के तहत ओपन सोर्स है, और वैसे ही octolib व OctoHub भी। मल्टी-मॉडल रूटिंग एक प्लगइन नहीं, कॉन्फ़िग है — अगर आपको चाहिए कोई प्रोवाइडर गायब है, तो वह octolib में आता है और Octomind में अपने आप दिखता है। अगर यहाँ कुछ टिकता नहीं, तो एक issue खोलें।