OpenRouter Fusion API

• यह इस खोज से शुरू होता है कि कई मॉडलों के परिणामों को समेकित (synthesize) करने पर अक्सर किसी एक मॉडल के अकेले प्रदर्शन से काफी बेहतर नतीजे मिल सकते हैं
• इसमें एक multi-model deliberation तरीका अपनाया जाता है, जहाँ एक ही prompt का कई विशेषज्ञ मॉडल समानांतर विश्लेषण करते हैं, और फिर एक judge model उन परिणामों को समेकित करके अंतिम उत्तर तैयार करता है
• पैनल मॉडल web search और web fetch को सक्षम करके समानांतर विश्लेषण करते हैं, और judge model इन्हें सहमति, विरोधाभास, आंशिक मेल, विशिष्ट अंतर्दृष्टि, ब्लाइंड स्पॉट्स के रूप में संरचित विश्लेषण में व्यवस्थित करता है
• डिफ़ॉल्ट रूप से Quality preset उपयोग होता है; चाहें तो Budget preset से सस्ते मॉडल चुने जा सकते हैं, या fusion plugin के फ़ील्ड्स के ज़रिए पैनल और judge को पूरी तरह पुनर्परिभाषित किया जा सकता है
• यह उन स्थितियों के लिए उपयुक्त है जहाँ एक अकेला मॉडल पर्याप्त नहीं होता, जैसे research, expert critique, या जहाँ गलत उत्तर की लागत अतिरिक्त completion लागत से अधिक हो
• चूँकि सभी पैनल सदस्यों और judge call को चलाया जाता है, इसलिए अनुरोध की कीमत एकल मॉडल के बजाय अलग-अलग completions के कुल योग के आधार पर तय होती है

---

यह कैसे काम करता है

• यह एक single prompt को छोटे स्तर की multi-model deliberation में बदल देता है
  • विशेषज्ञ मॉडल पैनल web search और web fetch सक्षम करके prompt का समानांतर विश्लेषण करता है
  • judge model पैनल के उत्तरों को समेकित करके consensus, contradictions, partial coverage, unique insights, blind spots के रूप में संरचित विश्लेषण बनाता है
  • इसी संरचित विश्लेषण के आधार पर judge model अंतिम उत्तर लिखता है

पैनल कॉन्फ़िगरेशन और सेटिंग्स

• डिफ़ॉल्ट पैनल Quality preset का उपयोग करता है
  • यदि सस्ते सदस्य चाहिए हों, तो Budget preset पर स्विच किया जा सकता है
  • fusion plugin के analysis_models और model फ़ील्ड्स से पैनल और judge को पूरी तरह override किया जा सकता है
• इसका उपयोग तब करने की सलाह दी जाती है जब एक single model पर्याप्त न हो
  • research, expert critique, या ऐसे क्षेत्रों के लिए उपयुक्त जहाँ गलत उत्तर की लागत अतिरिक्त completion लागत से अधिक हो

कीमत और सीमाएँ

• चूँकि सभी पैनल सदस्यों और judge call को चलाया जाता है, इसलिए अनुरोध की कीमत single model के आधार पर नहीं बल्कि अलग-अलग completions के कुल योग पर तय होती है
  • वास्तव में कौन-से मॉडल चले, यह Activity पेज पर देखा जा सकता है
• context limit चुने गए मॉडल के अनुसार बदलती है

presets में 6 मॉडल उपयोग होते हैं

• सर्वोच्च गुणवत्ता: Claude Opus, OpenAI GPT, Google Gemini Pro
• न्यूनतम लागत: Google Gemini Flash, DeepSeek V4 Flash, MoonshotAI Kimi

---

संबंधित घोषणा: "Fusion से frontier performance से आगे"

• यह एक ऐसा टूल है जो कई मॉडलों के परिणामों को समेकित करके एकल मॉडल के प्रदर्शन से आगे जाता है; इसमें भाग लेने वाले मॉडल पैनल और परिणामों को मिलाने वाले judge model को सीधे चुनकर इसे एक single model की तरह call किया जा सकता है
• DRACO benchmark के deep research कार्यों के 100 मापों में पैनल ने लगातार अलग-अलग मॉडलों से बेहतर प्रदर्शन किया
  • Fable 5 + GPT-5.5 fusion ने 69.0% स्कोर के साथ अकेले Fable 5 (65.3%) समेत सभी व्यक्तिगत मॉडलों को पीछे छोड़ा
  • कम-लागत पैनल (Gemini 3 Flash + Kimi K2.6 + DeepSeek V4 Pro) ने 50% लागत पर Fable 5 के स्कोर से 1% के भीतर पहुँचकर GPT-5.5 और Opus 4.8 को पीछे छोड़ा
• prompt को पैनल मॉडलों को समानांतर भेजा जाता है, judge सहमति, विरोधाभास, विशिष्ट अंतर्दृष्टि और कमजोर पक्षों का विश्लेषण करता है, और call किया गया मॉडल इन्हीं के आधार पर अंतिम उत्तर बनाता है
• पूरा pipeline server-side पर चलता है, इसलिए इसका उपयोग व्यक्तिगत मॉडल call की तरह ही किया जा सकता है
• Opus 4.8 को खुद उसी के साथ fusion करने पर भी 65.5% स्कोर मिला, जो अकेले (58.8%) की तुलना में 6.7 अंकों की बढ़त है, इससे synthesis चरण के अपने प्रभाव की पुष्टि होती है
• यह पाया गया कि पैनल मॉडल ऑनलाइन scoring rubric खोज सकते हैं, जिससे contamination risk पैदा होता है; इसे web search और web fetch exclusion list को एक-पंक्ति सेटिंग से लागू करके रोका गया
• उपयोग के 4 तरीके: Chatroom (कोड की आवश्यकता नहीं), Model slug (string replacement), Server tool (सबसे उच्च स्तर का नियंत्रण), Plugin (पैनल निर्दिष्ट करना)
• यह Fable का drop-in replacement नहीं है; Fable की ताकत वाले long-horizon tasks इसमें शामिल नहीं हैं, और coding में इसे selective call tool के रूप में उपयोग किया जाता है

[GN⁺]

Hacker News की राय

• कुछ महीने पहले मैंने OpenRouter का इस्तेमाल करने वाले MCP के साथ Fusion बनाकर देखा था। आइडिया यह था कि जब Claude अटक जाए, तो एक “expert panel” हो जिसके पास जाया जा सके
  बहुत सारे tests और benchmarks करने के बाद पाया कि एक model से दूसरे model के जवाब का मूल्यांकन करवाना वास्तव में बेहतर जवाब नहीं देता। आखिरकार यह कुछ ऐसा पूछने जैसा है, “यह जवाब उस जवाब से कितना मिलता-जुलता है जो तुमने खुद दिया होता,” और extra rounds या अचानक सूझने वाले “obvious” solutions असल में temperature बढ़ाने जैसा ही थे। समाधान तो मिले, लेकिन लागत बेतुकी तरह से महंगी थी। अगर इस तरीके पर और ध्यान गया, तो शायद मैं अपना वाला भी open कर दूँ

  • Prompt अहम है। अगर आपको दूसरे models की राय चाहिए, तो जाहिर है कि उन्हें शुरुआत से वही prompt देकर generate करवाना चाहिए और फिर synthesize करना चाहिए, और चाहें तो existing response पर भी काम करवाया जा सकता है
    मैं साफ़ तौर पर उनसे severity के हिसाब से issues ढूँढने को कहता हूँ, फिर उन issues को judge model panel से पास करवाता हूँ, और सिर्फ़ वे ही चीज़ें original response में ठीक करवाई जाती हैं जो एक खास threshold पार करती हैं। जिस बात से परिणाम काफी बेहतर हुए, वह यह थी कि judge models से truthfulness और “usefulness / क्या इसे ठीक करना चाहिए” को अलग-अलग axis पर evaluate करवाया जाए। क्योंकि अगर आप issue ढूँढने के लिए मजबूर करेंगे, तो आखिरकार वे मामूली खामियाँ निकालेंगे। truthfulness axis मेरे use case के लिए issue-detection model का मूल्यांकन करने में भी बेहतर था। इस तरह की व्याख्या बनाते समय यह आंशिक रूप से लागू होता है: https://hanzirama.com/character/%E6%9D%A5#explain — अब यह साइट मेरे LLM evaluation setup का एक छोटा side product बन गई है। अगर आपको सबसे अच्छी quality चाहिए, तो OpenRouter में provider को pin करना पड़ सकता है। सिर्फ़ :exacto से, खासकर open-weight models में, repeatable अच्छे results पाना मुश्किल है
  • मैंने यह भी देखा है कि अगर judge model को बताया जाए कि जवाब एक छोटा और कमज़ोर local LLM से आया है, तो वह जवाब को बहुत ज़्यादा सख्ती से चीर-फाड़ करता है। हालांकि मैंने इसे systematic तरीके से नहीं परखा, इसलिए नहीं जानता कि यह मेरी impression से आगे generalize होता है या नहीं
    क्या किसी और को भी ऐसा लगा है कि अगर आप LLM को “मैं श्रेष्ठ हूँ” वाली mode में फँसा दें, तो वह काफ़ी बुरा व्यवहार करता है?
  • मैंने 2024 में इस आइडिया का एक rough version बनाया था[0], और यह देखना दिलचस्प है कि यह सोच अब भी चल रही है। Quality threshold सेट किया जा सकता था, लेकिन उससे खास फ़र्क नहीं दिखा, और frontier models लगभग हमेशा एक-दूसरे से सहमत होते थे और जवाब को ऊँचे अंक देते थे
    2 साल पहले की तुलना में अब पूरा परिदृश्य बदल चुका है, इसलिए इसे फिर से देखना चाहिए। [0] https://github.com/Ceroxylon/konsensis
  • मुझे लगता है कि यह इस बात पर निर्भर करता है कि जवाब verifiable है या नहीं
    मैंने अपने app में दो judge models test किए। पहला resume-tailoring model के लिए judge model था, जो output resume को original resume और job posting से तुलना करके fit और honesty को 10 में score देता था, और वह अच्छी तरह काम करता था और उपयोगी था। दूसरा LLM trading bot platform के लिए review model था, जो main model के decisions की समीक्षा करता था। यहाँ, क्योंकि bot ambiguity को संभालता है, यह तब तक उल्टा नुकसानदेह हो सकता है जब तक कि वह candle prices गलत पढ़ने या SELL होना चाहिए था तब BUY कर देने जैसी साफ़ गलतियाँ न पकड़ ले। पहले तो decision latency जुड़ जाती है, जिससे Gemma 4 31B पर 30 सेकंड की जगह 60 सेकंड लगने लगते हैं। और review model सिर्फ़ BUY/SELL decisions पर चलता है, HOLD पर नहीं, इसलिए latency और cost की वजह से bot ज़्यादा trades करने के बजाय बहुत ज़्यादा cautious हो सकता है। इसलिए अगर जवाब आसानी से verify नहीं किया जा सकता, तो review model लगाने से बेहतर है कि काम एक ही बार में किसी बेहतर model से कराया जाए। फिर यह भी साफ़ नहीं रहता कि judge model की ज़रूरत ही क्यों है, और उसी agent से self-review क्यों न कराया जाए। ऊपर से, Gemma 4 जैसे reasoning models का reasoning text पढ़ें, तो वे पहले से self-review कर रहे होते हैं। यानी वे पहले से अपनी पूरी कोशिश कर रहे हैं, इसलिए दोबारा review ज़्यादा नई जानकारी नहीं जोड़ता। प्रयोग दिलचस्प है, लेकिन इसे case-by-case देखना पड़ता है
  • मेरा अनुभव भी यही है। वस्तुनिष्ठ रूप से बेहतर जवाब ढूँढना जितना लगता है उससे कहीं मुश्किल था, और यह महंगा भी था और धीमा भी

• मेरे पास एक prompt था जिसे मैं सिर्फ़ Claude Code के साथ इस तरह इस्तेमाल करता था
  चलिए architecture issues की समीक्षा करें। 10 agents चलाओ, हर एक से एक persona बनवाओ, फिर _api.go की समीक्षा करवाओ और reviews/-review.md में review लिखवाओ। हर agent को हर review के सामने दिया गया summary पढ़ने दो, फिर round-robin तरीके से अपनी पसंद की 3 reviews का जवाब response/--response.md में लिखवाओ। उसके बाद उन जवाबों पर rebuttals को rebuttals/-rebuttal.md में लिखवाओ। अंत में, हर agent अपनी review, response और rebuttal की समीक्षा करने के लिए फिर एक agent चलाए और नतीजे findings/-findings.md में व्यवस्थित करे। आखिर में कोई दूसरा agent इन नतीजों को मिलाकर review-findings.md में लिखे, और उसमें एक concise version भी दे। यह तरीका frontier models पर भी, और locally hosted models पर भी, अच्छा चला। आख़िरी बार मैंने इसे Qwen 3.5 के साथ इस्तेमाल किया था

  • मैं एक ही flow में कई agents इस्तेमाल करने का आदी नहीं हूँ, इसलिए कुछ बातें जानना चाहता हूँ
    क्या आप generated सभी files को review करके hallucinations न होने की पुष्टि करते हैं, या सिर्फ़ आख़िरी concise results file देखते हैं? यह भी जानना चाहता हूँ कि क्या मकसद यह है कि कई agents से गुज़रते-गुज़रते hallucinations एक-दूसरे को काट दें और अंत में सिर्फ़ सच्चाई बचे। क्या आपने कभी final version में बहुत गंभीर गलतियाँ देखी हैं? cost की चिंता थी, लेकिन locally hosted models से वह हिस्सा शायद कम हो जाता होगा। हालांकि local hosting वाले models को अब भी local commands चलाने या internet access में दिक्कत नहीं होती? अगर ऐसा है, तो क्या यह तरीका project के बाकी हिस्सों को refer किए बिना सिर्फ़ उस file के context पर चलता है?
  • यह सिर्फ़ एक ही review को n बार चलाकर results merge करने की तुलना में काफ़ी ज़्यादा elaborate setup लगता है। जानना चाहूँगा कि आप इस design तक क्यों पहुँचे

• बैकग्राउंड संदर्भ यहाँ है: Surpassing Frontier Performance with Fusion
  https://news.ycombinator.com/item?id=48525392
  थोड़ा बेहतर UI यहाँ है: https://openrouter.ai/fusion. OpenRouter का Fusion API रिक्वेस्ट को एक साथ कई मॉडल्स को भेजता है, और एक जज मॉडल जवाबों को मिलाकर अंतिम प्रतिक्रिया बनाता है। समय ज़्यादा लगता है, लेकिन कहा जा रहा है कि इससे परफॉर्मेंस काफ़ी बढ़ती है। कम से कम जिन deep research benchmarks पर इन्होंने टेस्ट किया, वहाँ ऐसा था। Budget preset तीन सस्ते मॉडल्स से बना है, और उस benchmark में Fable के लगभग बराबर है जबकि लागत आधी है। Quality preset तीन महंगे मॉडल्स से बना है, Fable को हरा देता है, लेकिन लागत Fable की दोगुनी है। Pareto graph: https://openrouter.ai/blog/images/blog/fusion-benchmark-cost.... दिलचस्प बात यह है कि एक ही मॉडल को खुद उसी के साथ fuse करने पर भी परफॉर्मेंस बढ़ी। 2xOpus4.8 benchmark में Fable के लगभग बराबर है, लेकिन लागत Fable की दोगुनी है। अलग-अलग मॉडल्स को मिलाने पर थोड़ा अतिरिक्त फ़ायदा भी मिलता है। लगता है कि मुख्य लाभ अतिरिक्त test-time compute से आता है। अच्छा होगा अगर हाल के सस्ते मॉडल्स, जैसे DSV4, को खुद उसी के साथ या Mimo के साथ fuse करने पर और रिसर्च आए, और parallel test-time compute वाले fusion तथा inference बढ़ाने या turns बढ़ाने के बीच के trade-off भी दिखें

  • “एक ही मॉडल को खुद उसी के साथ fuse करने पर भी परफॉर्मेंस बढ़ी” — GPT-2 से GPT-3 की तरफ़ जाते समय यह काफ़ी आम तरीका था
    असल में यह संभव आउटपुट स्पेस से ज़्यादा samples लेना है। अगर कोई मॉडल किसी काम को 60% संभावना के साथ कर सकता है, तो 5~10 samples लेकर majority vote जैसा कुछ लागू किया जा सकता है। जिन समस्याओं में परिणामों को जोड़ना आसान था, वहाँ मॉडल accuracy बढ़ने के साथ इसका इस्तेमाल कम हो गया, लेकिन अगर ज़्यादा जटिल judge, यानी सक्षम LLM, मौजूद हो तो आउटपुट स्पेस को अधिक sample करके अच्छे हिस्सों को चुन लेने भर से भी परफॉर्मेंस अब भी बढ़ सकती है
  • यह दिलचस्प है कि Fable 5 + GPT 5.5 panel दोनों में से किसी एक की frontier performance को काफ़ी पीछे छोड़ देता है, लेकिन Gemini को मिलाने पर तीन-मॉडल panel बेहतर नहीं होता बल्कि और खराब हो जाता है
    मुझे तो ऐसा लगता है कि उस task में Gemini शायद कमज़ोर है, लेकिन अपने समाधान को judge model के सामने मनवा लेने में बेहतर है। और दो Opus 4.8 का panel लगभग ठीक-ठीक एक Fable 5 के बराबर निकलना भी थोड़ा संदिग्ध लगता है। क्या पता Anthropic पर्दे के पीछे पहले से ऐसा कुछ कर रहा हो?
  • यह अफ़सोस की बात है कि synthesis चरण की वजह से कितना ज़्यादा समय लगता है, इस पर लगभग बात ही नहीं की गई। Deep research benchmark में शायद यह ज़्यादा मायने न रखता हो, लेकिन coding tasks में यह कैसे लागू होगा, यह दिलचस्प है
  • पता नहीं मौजूदा मॉडल्स में अब भी ऐसा है या नहीं, लेकिन कुछ पीढ़ी पहले की Microsoft research में पाया गया था कि मॉडल से N बार दोहराने को कहने पर परफॉर्मेंस काफ़ी सुधरती है, और optimal point 4 repetitions था

• यह देखने के लिए मैंने एक तेज़ evaluation चलाया कि Opus 4.7 या GPT 5.5 को सीधे call करने की तुलना में यह गुणात्मक रूप से कितना अलग है
  उम्मीद के मुताबिक Fusion 7 गुना धीमा और 4 गुना महंगा था। मैं इसकी आलोचना नहीं कर रहा; मेरे हिसाब से Fusion “ज़रूरत पड़ने पर ही इस्तेमाल करो” वाली category में आता है। https://3fpi5avcqq.evvl.io/

  • distillation target के रूप में Fusion वाकई बहुत अच्छा लगता है
  • साझा करने के लिए धन्यवाद। मेरी सबसे बड़ी चिंता speed थी, लेकिन उधर उस हिस्से का ज़िक्र नहीं था
  • जानना चाहूँगा कि नीचे कौन-से मॉडल्स इस्तेमाल किए गए। अगर आपने interface में Quality default लिया था, तो frontier के 3 मॉडल्स और उनमें से एक के judge होने वाली संरचना के कारण लागत लगभग 4x होना समझ में आता है
    शायद मूल विचार यह है कि Fusion को ज़्यादा सरल और सस्ते मॉडल्स के साथ इस्तेमाल किया जाए
  • यह मुझे काफ़ी हद तक intuition के खिलाफ़ लगता है। इसके अच्छे से काम करने के लिए सही framing और structure पकड़ना आसान नहीं होगा। मॉडल्स को साथ में अच्छे से खेलना सच में पसंद नहीं है
    असली इस्तेमाल में इनका version कितना टिकेगा, यह जानने की उत्सुकता है

• मैंने इस समस्या के बारे में बहुत सोचा है, और सरल रूप में समझूँ तो हर मॉडल को मानव ज्ञान के ऊपर एक bell-shaped distribution की तरह देखा जा सकता है, और हर मॉडल की distribution अलग होती है
  कई मॉडल्स इस्तेमाल करने पर आप दूसरे मॉडल्स की distribution को ऐसे text से बदल सकते हैं जो मूल curve के बाहर हो। लेकिन फिर सोचता हूँ कि क्या SFP और reinforcement learning पहले ही text distribution को इतना बदल चुके हैं कि मॉडल्स के संयुक्त आउटपुट सचमुच कुछ बेहतर और पर्याप्त रूप से विविध बनते हैं, या फिर वे बस एक echo chamber बन जाते हैं। इसे साबित करने का अभी कोई तरीका नहीं है, लेकिन मेरा मानना है कि ऐसा नहीं है

• Fusion के बारे में एक anecdotal नतीजा: Fable में इस्तेमाल की गई वही query मैंने OpenRouter Fusion पर चलाई, और परिणाम बदतर था
  Fable ने काफ़ी गहरी knowledge/intelligence layer तक कुछ पकड़ बनाई, सिर्फ़ plausible जवाब देने के बजाय समाधान के लिए priorities सुझाईं और कुछ items को छोड़ देने की भी सलाह दी, जो मुझे काफ़ी उचित लगा। दूसरी तरफ़ Fusion ऐसा लगा जैसे Fable से पहले के state-of-the-art मॉडल्स जिस तरह के जवाब देते थे, बस उसी वर्ग के जवाबों में थोड़ी विविधता जोड़ दी गई हो, और जब तक मेरे पास Fable की access थी, उस दौरान किए गए बहुत सीमित test में Fusion उस गहराई तक नहीं पहुँच पाया जहाँ Fable पहुँचता था

• वीकेंड पर नए OpenRouter Fusion मॉडल से प्रेरित होकर मैंने यह देखने के लिए काम किया कि क्या इसे Claude Code में चलाया जा सकता है और क्या इसे दूसरों के लिए भी आसानी से आज़माने लायक बनाया जा सकता है
  मैंने claude-fusion-launcher बनाया — यह Claude Code को एक single model के बजाय models के panel पर चलाता है। लागत भी दिखाता है। https://github.com/smorinlabs/claude-fusion-launcher

  • क्या यह जल्दी महँगा नहीं हो जाता? वेबसाइट पर मैंने जो one-off prompts आज़माए, वे लगभग प्रति prompt 1 डॉलर पड़ रहे थे

• सोच रहा हूँ कि क्या एक ही मॉडल पर एक ही prompt को कई बार, ज़्यादा temperature के साथ regenerate करना, अलग-अलग मॉडल्स चलाने के बराबर है
  मुझे शक है कि अलग frontier मॉडल्स के बीच जो variability महसूस होती है, उसका बड़ा हिस्सा non-zero temperature से आने वाली randomness की वजह से हो सकता है। लगता है मॉडल्स को 5, 10, 15 जैसी साफ़-सुथरी गोल संख्या में items लौटाने के लिए train किया गया है। यह marketing material पर training के हस्तक्षेप की वजह से भी हो सकता है। ऊपर से बड़े context में recall भी 100% से काफ़ी दूर है। इसलिए अगर code में 27 bugs हैं, तो चाहे आप कई मॉडल्स इस्तेमाल करें या उसी मॉडल को बार-बार call करें, हर run में उन 27 में से अलग 10 समस्याएँ मिल सकती हैं

• मुझे जिज्ञासा है कि क्या इस क्षेत्र में कोई औपचारिक शोध मौजूद है। मैंने भी इस तरह के approach के कुछ variation आज़माए हैं, लेकिन यह भरोसे के साथ कहना मुश्किल था कि नतीजे बेहतर थे
  कहीं यह वैसा तो नहीं जैसे business के लिए सबसे अच्छी strategy अलग-अलग 2~3 consultant से पूछना। जवाबों को जोड़ देने से वास्तव में कुछ बेहतर निकलता है या नहीं, यह साफ़ नहीं है

• मैंने भी अपने TrustedRouter में ऐसा ही फीचर open source के रूप में, end-to-end encryption के साथ रिलीज़ किया है: https://trustedrouter.com/

  • वास्तव में privacy promise दिखना अच्छा लगता है। टालमटोल भरे और अस्पष्ट provider terms को अंतहीन पढ़ने में मैं बहुत समय खर्च कर रहा हूँ