Morph (YC S23), AI code editing को प्रति सेकंड 4,500 टोकन पर लागू करता है

• AI coding tools से बनाए गए बदलावों को मौजूदा files में जोड़ने की प्रक्रिया bottleneck बन गई, इसलिए Morph अपने Fast Apply model के जरिए पूरे file rewrite और कमजोर search-replace को बदलना चाहता है
• Agent ऐसा loose edit output बनाता है जिसमें बदली न गई lines को //...existing code... की तरह छोड़ा जाता है, और Morph original file के आधार पर असली बदलाव लागू करता है
• उपलब्ध models में morph-v3-fast 4,500+ tok/sec देता है, morph-v3-large 2,500+ tok/sec देता है, और इन्हें create.xyz, databutton, continue.dev आदि में इस्तेमाल किया जाता है
• Search के लिए embedding और reranking models उपलब्ध कराए जाते हैं, और अगले products के तौर पर Cmd-K style inline editing model और sub-500ms latency वाला Morph Tab API तैयार किया जा रहा है
• Cursor ने यह तरीका पहले शुरू किया था, लेकिन इसे API के रूप में सार्वजनिक नहीं किया गया; Morph developers को सीधे integrate करने योग्य API और बड़ा free tier आगे रखता है

---

AI code edits लागू करने का bottleneck

• AI द्वारा बनाए गए code changes को मौजूदा code में भरोसेमंद तरीके से insert करने की प्रक्रिया Morph की मुख्य problem statement है
  • पूरे file को rewrite करना धीमा हो सकता है और लागत बढ़ा सकता है
  • Search-replace तरीका छोटे-छोटे फर्क से भी आसानी से टूट सकता है और errors दे सकता है
• Morph को इस तरह design किया गया है कि agent changes को loosely output करे
  • जिन मौजूदा lines में बदलाव नहीं किया गया, उन्हें // ...existing code... की तरह reference किया जाता है
  • Original file और loose patch को input के रूप में लेकर Fast Apply model और speculative decoding से असली edits लागू किए जाते हैं
• लक्ष्य AI patches को तेज, ज्यादा भरोसेमंद और production में इस्तेमाल के लिए आसान रूप देना है
• संबंधित सामग्री नीचे देखी जा सकती है
  • Demo video
  • Live demo
  • Docs

Model lineup और अगले products

• Morph दो तरह के Fast Apply models उपलब्ध कराता है
  • morph-v3-fast: 4,500+ tok/sec
  • morph-v3-large: 2,500+ tok/sec
• ये models create.xyz, databutton, continue.dev आदि में Fast Apply चलाने के लिए इस्तेमाल होते हैं
• Code search के लिए embedding और reranking हेतु search models भी साथ में उपलब्ध कराए जाते हैं
• अगली features edit flow को और छोटा बनाने पर केंद्रित हैं
  • Inline Edit Model, Cmd-K: development flow को बाधित किए बिना बेहद तेज inline edits
  • Morph Tab API: अगला code edit और action predict करने वाला model, जिसका लक्ष्य sub-500ms latency है और अभी private beta में है
• Morph मानता है कि developer experience में raw inference speed महत्वपूर्ण है, और पूरे file rewrite की तुलना में Fast Apply editing speed, cost और reliability के लिहाज से बेहतर है
• जब narrow task benchmarks 99% से ऊपर saturate हो जाते हैं, तो जटिलता एक single frontier model के बजाय specialized inference-optimized models की ओर शिफ्ट होती है—Morph का यही आकलन है

[GN⁺]

Hacker News की राय

• मैं इस बात से पूरी तरह सहमत नहीं हूँ कि developer experience में raw inference speed से ज़्यादा accuracy महत्वपूर्ण है। users कहीं ज़्यादा धीमे tok/sec को झेलते हुए भी बड़े models को पसंद करते हैं, क्योंकि अंततः code quality ही पहला मानदंड होता है। बड़े code edits (जैसे 5,000 tokens) में 200~300ms की latency कोई बहुत मायने रखने वाली संख्या नहीं है। edit speed अपने आप में bottleneck होने से ज़्यादा quality बड़ा factor है। अगर code changes में 200ms की बचत quality से ज़्यादा महत्वपूर्ण मानी जाए, तो मैं उससे बिल्कुल सहमत नहीं हो सकता। अगर 1~2 agents को parallel में चलाया जाए, तो code review करते-करते ज़्यादातर fixes पहले ही हो चुके होते हैं। quality measure करने का मानदंड क्या है, यह जानने की जिज्ञासा है, और fast model व large model के बीच error rate में कितना अंतर है, यह भी जानना चाहता हूँ

  • मुझे लगता है कि अगर inference speed लगभग 50% तेज़ हो जाए, तो वह मेरे workflow के लिए accuracy में single-digit सुधार से कहीं ज़्यादा मूल्यवान है। वैसे भी changes मुझे खुद verify करने होते हैं, इसलिए तेज़ iteration cycle बेहतर लगती है। हाँ, अगर accuracy इतनी ऊँची हो कि verification कम करना पड़े या कम बार करना पड़े, तब inference speed का फ़ायदा लगभग अर्थहीन हो जाता है

  • पूरी तरह सहमत। AI model code change propose करने के बाद सबसे पहला काम हमेशा उसके output को बहुत ध्यान से review करना होता है। ज़्यादातर मामलों में prompt में छूटा हुआ context या किसी specific token की वजह से code duplicate हो जाता है या पूरी तरह गलत बन जाता है। अगर changes को bulk में apply कर दिया जाए, तो debugging और कठिन हो जाती है, और ऐसी बड़ी code insertions जितनी जमा होती जाती हैं, codebase उतनी ही जल्दी उम्मीद से पहले टूट सकता है

  • मेरी समझ के मुताबिक बात सिर्फ ±300ms की नहीं है, बल्कि 300ms और 10 seconds जैसा बहुत बड़ा अंतर है। ऐसे बड़े models के response का इंतज़ार मेरी नज़र में निश्चित रूप से एक constraint है। ऊपर से ऐसे simple कामों के लिए resources भी बेवजह ज़्यादा खर्च होते हैं, यह भी खटकता है। सच कहूँ तो code changes को समझदारी से apply करना पारंपरिक programming environments में भी काफ़ी हद तक संभाला जा सकने वाला क्षेत्र लगता है। सच में क्या यह ऐसा मुश्किल काम है जिसके लिए LLM अनिवार्य हो?

  • तुम्हें review time ही bottleneck लग रहा है। मैं अभी ऐसी feature बना रहा हूँ जो लोगों को code agent के output को कहीं तेज़ी से review करने में मदद करेगी। अगर तुम्हारे पास समय हो, तो मैं तुम्हारे workflow के बारे में थोड़ा विस्तार से interview करना चाहूँगा। comment में या मेरी profile में दिए गए contact पर संपर्क करो

  • मुझे लगता है असली बात यह है कि developer flow state में बना रहे। errors और latency दोनों flow तोड़ते हैं। आख़िरकार coding में quality (accuracy) ही सबसे महत्वपूर्ण factor है। quality evaluation के लिए हम बड़े तौर पर 2 मानदंड इस्तेमाल करते हैं। पहला, user query से task completion तक की पूरी chain पर end-to-end performance (aider-style bench); दूसरा, apply accuracy (syntax/grammar issues, character-level diff आदि)। large और fast models के बीच error rate लगभग 2% के आसपास है। अगर language complex या difficult हो, तो large model ज़्यादा उपयुक्त होता है, और task के हिसाब से सही model को अपने आप route करने का option भी है

• मैंने microsoft copilot इस्तेमाल किया है, और खासकर code apply stage में वह बहुत धीमा और असुविधाजनक लगा। इतना resource-rich माहौल होने के बावजूद model को ठीक से train न कर पाना अजीब लगता है। अनुरोध: सबसे अच्छा diff format LLM generate कर सके, इसके लिए system prompt को official docs में शामिल किया जाए। हर LLM upgrade के साथ diff format बदल जाता है, इसलिए कौन-सा format सबसे अच्छा है यह हर बार अनुमान लगाना पड़ता है, जो असुविधाजनक है। साथ ही, privacy policy पूरी तरह समझ नहीं आई; मेरी समझ सही है तो क्या paid users का data भी store/train किया जाता है? (फोन नंबर दिए बिना) सिर्फ service के लिए payment करूँ और data training में इस्तेमाल न हो, ऐसा कैसे संभव है, यह जानना चाहता हूँ। Morph Privacy Policy का संदर्भ लिया है

  • ZDR(Zero Data Retention) option भी उपलब्ध है। [e-mail] पर mail भेज दें, हम set up कर देंगे। Morph को OpenRouter के ज़रिए इस्तेमाल करने पर यह हमेशा Zero Data Retention रहता है

  • “मेरे data से model को train मत करो” वाली मांग थोड़ी अजीब लगती है। ऐसे models बने ही इसलिए हैं क्योंकि इन्हें दूसरों के code पर train किया गया है। ऐसे tools का इस्तेमाल करते हुए यह कहना कि मेरा data training में इस्तेमाल न हो, असल में कुछ self-centered-सा तर्क है, जैसे collective benefit की दुविधा। इसी तरह तो models बेहतर बनते हैं

• official demo में दिया गया HTML example मैंने https://morphllm.com/dashboard/playground/apply पर वैसे का वैसा apply करके देखा, तो बिना कोई बदलाव माँगे भी CSS जुड़ गया और contact section भी बन गया। update instructions में ऐसा कुछ नहीं था

  • बढ़िया पकड़। HTML example में hardcoded snippet uncommented नहीं था। अब इसे ठीक कर दिया गया है

• cost के हिसाब से देखें तो Morph, Gemini Flash से काफ़ी महँगा लगता है। Gemini flash भी काफ़ी ठीक-ठाक code generation कर लेता है, और edits को तेज़ी से reflect करने वाला AI अच्छा है, लेकिन price point हल्का नहीं है। उदाहरण के लिए Morph v3 fast की input cost $1.20/M token और output $2.70/M token है, जबकि Gemini 2.5 Flash की input $0.30/M token और output $2.50/M token है (संदर्भ: OpenRouter)

  • यह 0 data retention option के हिसाब से pricing है। Morph की official website पर pricing input $0.80 / 1M tokens और output $1.20 / 1M tokens है। bulk/reserved instances के लिए discount policy भी है

• कहीं मैं भ्रमित न हो रहा हूँ, इसलिए पूछ रहा हूँ: क्या Morph दूसरे LLMs के output को “apply” करने वाला tool है, और खुद का LLM नहीं? यानी यह 4,500 tokens per second generate नहीं कर रहा, बल्कि apply speed बता रहा है?

  • सही। लेकिन Morph खुद भी एक LLM है। व्यवहार में structure ऐसा है कि एक large LLM, एक small LLM को tool call की तरह इस्तेमाल करता है

• बहुत प्रभावशाली। मैं अपने internal AI coding system के लिए ऐसे solution की तलाश में हूँ; open source Osmosis Apply 1.7B जैसे project की तुलना में यह किस तरह अलग है, यह जानना चाहता हूँ। मान रहा हूँ कि Morph model open source/open weight नहीं है

  • दोनों को खुद इस्तेमाल करके देखना सबसे अच्छा रहेगा! हमारे model को speed और accuracy, दोनों में काफ़ी बढ़त है

• पहले मुझे Morph, OpenRouter पर नहीं दिखा था, लेकिन अब लगता है उपलब्ध है। हालांकि listed model शायद पुराना version है? क्या इसे ज़्यादा सक्रिय रूप से support करने की योजना है? और fast apply model का Relace या Llama/Cerebras के साथ performance (खासकर accuracy) comparison benchmark भी जानना चाहता हूँ

  • Hacker News की ताकत कमाल की है! अब वहाँ नए models भी listed हैं

  • अभी v2 model, morph-v3-large को point कर रहा है। जल्द ही v3-large और v3-fast भी जोड़े जाएँगे

• Relace के साथ comparison जानना दिलचस्प होगा। दोनों YC की कंपनियाँ हैं, और feature set भी काफ़ी मिलता-जुलता दिखता है Relace

  • अच्छा सवाल है। customer list भी वही दिखाई गई है (create.xyz, continue.dev)

• ChatGPT और VSCode के बीच bridge बनाने वाला कोई browser extension हो, और उसके बीच Morph (या Claude) को डालकर agentic coding सीधे web UI में इस्तेमाल किया जा सके, तो बहुत अच्छा होगा। यह API की बजाय web interface इस्तेमाल करने का idea है

  • MCP का इस्तेमाल करके यह उद्देश्य हासिल किया जा सकता है। जल्द जारी होगा

• अगर AI समझदारी से rebase+merge को automate कर दे, तो development speed बहुत बढ़ सकती है। कई users के code changes को AI अगर उनकी intent तक समझकर अपने आप merge कर दे, तो वह सच में productivity boost होगा

  • Claude Code इस्तेमाल करें तो यह feature पहले से मिल जाता है। बस कहें, “दूसरी branch merge करो और conflicts resolve करो"

  • आप कितनी बार merge conflict की स्थिति का सामना करते हैं?