Morph (YC S23) wendet KI-Code-Edits mit 4.500 Tokens pro Sekunde an

• Als das Einfügen von durch KI-Coding-Tools erzeugten Änderungen in bestehende Dateien zum Flaschenhals wurde, will Morph mit seinem Fast-Apply-Modell das Neuschreiben ganzer Dateien und anfälliges Suchen-und-Ersetzen ersetzen
• Agenten erzeugen eine lockere Edit-Ausgabe, bei der unveränderte Zeilen etwa als //...existing code... stehen bleiben, und Morph wendet die tatsächlichen Änderungen anhand der Originaldatei an
• Die angebotenen Modelle sind morph-v3-fast mit 4.500+ tok/sec und morph-v3-large mit 2.500+ tok/sec; sie werden unter anderem bei create.xyz, databutton und continue.dev eingesetzt
• Für die Suche bietet Morph Embedding- und Reranking-Modelle an; als nächste Produkte sind ein Inline-Edit-Modell im Cmd-K-Stil und die Morph Tab API mit einer Latenz von unter 500 ms geplant
• Cursor hat diesen Ansatz zuerst vorangetrieben, ihn aber nicht als API veröffentlicht; Morph setzt auf eine API, die Entwickler direkt integrieren können, sowie auf ein großes kostenloses Kontingent

---

Der Flaschenhals beim Anwenden von KI-Code-Edits

• Morph sieht das zuverlässige Einfügen von durch KI erzeugten Codeänderungen in bestehenden Code als zentrales Problem
  • Das Neuschreiben ganzer Dateien ist langsam und kann teuer werden
  • Suchen-und-Ersetzen ist schon bei kleinen Abweichungen fehleranfällig und kann scheitern
• Morph ist so konzipiert, dass Agenten Änderungen locker ausgeben
  • Unveränderte bestehende Zeilen werden etwa als // ...existing code... referenziert
  • Auf Basis der Originaldatei und eines lockeren Patches wendet das Fast-Apply-Modell mit spekulativem Decoding die tatsächlichen Edits an
• Ziel ist es, KI-Patches schneller, zuverlässiger und einfacher produktiv einsetzbar zu machen
• Weitere Informationen gibt es hier
  • Demo-Video
  • Live-Demo
  • Dokumentation

Modellpalette und nächste Produkte

• Morph bietet zwei Fast-Apply-Modelle an
  • morph-v3-fast: 4.500+ tok/sec
  • morph-v3-large: 2.500+ tok/sec
• Diese Modelle werden unter anderem bei create.xyz, databutton und continue.dev eingesetzt, um Fast Apply zu betreiben
• Für die Codesuche werden zusätzlich Suchmodelle für Embeddings und Reranking angeboten
• Die nächsten Funktionen zielen darauf ab, den Edit-Workflow weiter zu verkürzen
  • Inline Edit Model, Cmd-K: sehr schnelle Inline-Edits, die den Entwicklungsfluss nicht unterbrechen
  • Morph Tab API: ein Modell, das die nächsten Code-Edits und Aktionen vorhersagt; Ziel ist eine Latenz von unter 500 ms, derzeit in privater Beta
• Morph ist der Ansicht, dass rohe Inferenzgeschwindigkeit für die Developer Experience wichtig ist und Fast-Apply-Edits gegenüber dem Neuschreiben ganzer Dateien bei Geschwindigkeit, Kosten und Zuverlässigkeit überlegen sind
• Wenn enge Aufgaben-Benchmarks bei über 99 % gesättigt sind, verlagert sich die Komplexität nach dieser Einschätzung von einem einzelnen Frontier-Modell hin zu spezialisierten, für Inferenz optimierten Modellen

[GN⁺]

Hacker-News-Kommentare

• Ich stimme eher nicht der Behauptung zu, dass bei der Developer Experience rohe Inferenzgeschwindigkeit wichtiger sei als Genauigkeit. Dass Nutzer trotz deutlich geringerer Tok/sec größere Modelle bevorzugen, liegt letztlich daran, dass Codequalität das wichtigste Kriterium ist. Bei größeren Codeänderungen, z. B. 5.000 Tokens, sind 200–300 ms Verzögerung kaum relevant. Beim Editieren ist Qualität ein viel größerer Faktor als die reine Geschwindigkeit, nicht der Flaschenhals. Wenn 200 ms weniger bei einer Codeänderung wichtiger sein sollen als Qualität, kann ich das überhaupt nicht nachvollziehen. Wenn man 1–2 Agenten parallel nutzt, sind die meisten Änderungen ohnehin schon fertig, während man den Code reviewt. Mich würde interessieren, nach welchen Kriterien Qualität gemessen wird und wie groß der Unterschied in der Fehlerrate zwischen schnellen und großen Modellen ist.

  • Ich habe das Gefühl, dass eine um etwa 50 % höhere Inferenzgeschwindigkeit für meinen Workflow deutlich mehr Wert hat als eine Verbesserung der Genauigkeit um einen einstelligen Prozentwert. Ich muss die Änderungen sowieso selbst prüfen, daher fühlt sich ein schnellerer Iterationszyklus besser an. Wenn die Genauigkeit allerdings hoch genug wäre, dass man weniger oder seltener verifizieren müsste, dann wäre der Vorteil bei der Inferenzgeschwindigkeit fast bedeutungslos.

  • Stimme voll zu. Nachdem ein AI-Modell Codeänderungen vorgeschlagen hat, ist der allererste Schritt immer, das Ergebnis sorgfältig zu reviewen. In den meisten Fällen wird Code wegen fehlendem Kontext im Prompt oder bestimmter Tokens dupliziert oder völlig daneben generiert. Wenn man Änderungen gesammelt anwendet, wird das Debugging noch schwieriger, und je mehr sich solche massiven Code-Inserts ansammeln, desto wahrscheinlicher ist es, dass der Code schneller kaputtgeht, als man denkt.

  • So wie ich es verstanden habe, geht es nicht nur um ±300 ms, sondern um eine sehr große Lücke wie 300 ms gegenüber 10 Sekunden. Das Warten auf Antworten solcher großen Modelle ist für mich definitiv eine Einschränkung. Außerdem ist es schade, dass bei solchen einfachen Aufgaben unnötig viele Ressourcen verbraucht werden. Eigentlich denke ich, dass das intelligente Anwenden von Codeänderungen auch in bestehenden Programmierumgebungen gut lösbar sein sollte. Ich frage mich wirklich, ob das eine Aufgabe ist, die unbedingt ein LLM braucht.

  • Für dich scheint die Review-Zeit der Flaschenhals zu sein. Ich arbeite gerade an einer Funktion, die Leuten hilft, die Ergebnisse von Code-Agenten viel schneller zu reviewen. Wenn du Zeit hast, würde ich deinen Workflow gern etwas genauer interviewen. Melde dich gern per Kommentar oder über die Kontaktdaten in meinem Profil.

  • Ich denke, der Kernpunkt ist, dass Entwickler ihren Flow-Zustand beibehalten können. Sowohl Fehler als auch Latenz unterbrechen diesen Flow. Unterm Strich ist beim Coden Qualität bzw. Korrektheit der wichtigste Faktor. Für die Qualitätsbewertung nutzen wir grob zwei Kriterien. Erstens die End-to-End-Performance über die gesamte Kette von der Nutzeranfrage bis zur Task-Erfüllung hinweg (ein aider-artiger Benchmark); zweitens die Anwendungsgenauigkeit (Syntax-/Grammatikprobleme, Diff auf Zeichenebene usw.). Der Unterschied in der Fehlerrate zwischen großen und schnellen Modellen liegt bei etwa 2 %. Bei komplexen oder schwierigen Sprachen eignen sich größere Modelle besser, und es gibt auch eine Option, automatisch das für die Aufgabe passende Modell zu routen.

• Ich habe Microsoft Copilot ausprobiert und fand es vor allem in der Phase des Code-Anwendens viel zu langsam und umständlich. Es wundert mich, dass man an einem so ressourcenstarken Ort das Modell nicht ordentlich trainiert hat. Bitte: Nehmt den System-Prompt für das beste Diff-Format in die offizielle Dokumentation auf, damit das LLM es generieren kann. Bei jedem LLM-Upgrade ändert sich das Diff-Format gefühlt, und man muss immer raten, welches Format am besten ist. Außerdem verstehe ich die Datenschutzrichtlinie nicht eindeutig; wenn ich sie richtig lese, heißt das, dass selbst bei zahlenden Nutzern Daten gespeichert bzw. zum Training verwendet werden? Ich würde gern wissen, wie man für den Dienst bezahlen kann, ohne dass die Daten fürs Training verwendet werden. Siehe Morph Privacy Policy.

  • Eine ZDR-Option (Zero Data Retention) ist ebenfalls möglich. Schick einfach eine Mail an [e-mail], dann richten wir das ein. Wenn du Morph über OpenRouter verwendest, gilt immer Zero Data Retention.

  • Die Forderung „Trainiert das Modell nicht mit meinen Daten“ ist eine etwas absurde Position. Solche Modelle funktionieren überhaupt nur, weil sie mit dem Code anderer trainiert wurden. Solche Tools zu verwenden und gleichzeitig zu sagen, die eigenen Daten dürften nicht fürs Training genutzt werden, ist letztlich egoistisch, fast wie ein Dilemma des kollektiven Nutzens. So werden diese Modelle eben besser.

• Ich habe das HTML-Beispiel aus der offiziellen Demo unverändert unter https://morphllm.com/dashboard/playground/apply angewendet, und obwohl ich gar keine Änderung angefordert habe, wurden CSS hinzugefügt und sogar ein Contact-Abschnitt erzeugt. So etwas stand nicht in den Update-Instruktionen.

  • Gut gesehen. Im HTML-Beispiel war ein hartcodiertes Snippet noch nicht auskommentiert. Das ist jetzt behoben.

• Kostenseitig wirkt Morph deutlich teurer als Gemini Flash. Gemini Flash erzeugt ebenfalls ziemlich guten Code, und schnelle AI für Edits ist zwar gut, aber die Preise sind nicht ohne. Zum Beispiel kostet Morph v3 fast $1.20/M Input-Tokens und $2.70/M Output-Tokens, während Gemini 2.5 Flash bei $0.30/M Input-Tokens und $2.50/M Output-Tokens liegt (Quelle: OpenRouter).

  • Das ist der Preis mit der Option für 0 Datenaufbewahrung. Auf der offiziellen Morph-Website liegt der Preis bei $0.80 / 1M Input-Tokens und $1.20 / 1M Output-Tokens. Für hohe Volumina bzw. Reserved Instances gibt es auch Rabatte.

• Nur zur Sicherheit, damit ich es nicht falsch verstehe: Ist Morph ein Tool, das die Ergebnisse anderer LLMs „anwendet“, und kein eigenes LLM? Geht es also nicht um 4.500 Tokens pro Sekunde bei der Generierung, sondern beim Anwenden?

  • Genau. Aber Morph ist auch selbst ein LLM. Tatsächlich ist es eine Struktur, in der ein großes LLM ein kleines LLM wie einen Tool-Call nutzt.

• Sehr beeindruckend. Ich suche gerade nach so einer Lösung für ein internes AI-Coding-System. Mich würde interessieren, worin die Unterschiede zu Projekten wie dem Open-Source-Osmosis Apply 1.7B liegen. Unter der Annahme, dass das Morph-Modell weder Open Source noch Open Weights ist.

  • Am besten probierst du beide selbst aus! Unser Modell ist bei Geschwindigkeit und Genauigkeit deutlich überlegen.

• Früher habe ich Morph nicht auf OpenRouter gesehen, jetzt scheint es dort gelistet zu sein. Allerdings wirkt es so, als sei das eingetragene Modell eine ältere Version. Gibt es Pläne, das aktiver zu unterstützen? Und mich würden Benchmark-Ergebnisse interessieren, wie sich das Fast-Apply-Modell gegenüber Relace oder Llama/Cerebras schlägt, besonders bei der Genauigkeit.

  • Die Macht von Hacker News ist enorm! Jetzt sind dort auch die neuen Modelle gelistet.

  • Das aktuelle v2-Modell zeigt derzeit auf morph-v3-large. Bald werden auch v3-large und v3-fast hinzugefügt.

• Mich würde ein Vergleich mit Relace interessieren. Beides sind YC-Unternehmen, und die Funktionen scheinen sehr ähnlich zu sein: Relace

  • Gute Frage. Auch die Kundenliste wird identisch angezeigt (create.xyz, continue.dev).

• Eine Browser-Erweiterung als Brücke zwischen ChatGPT und VSCode, dazwischen Morph (oder Claude), damit man agentic coding direkt über die Web-UI nutzen kann, wäre wirklich großartig. Die Idee wäre, statt der API die Weboberfläche zu nutzen.

  • Mit MCP lässt sich dieses Ziel erreichen. Kommt bald.

• Wenn AI intelligent Rebase + Merge automatisieren könnte, würde die Entwicklungsgeschwindigkeit massiv steigen. Wenn die AI die Absicht hinter den Codeänderungen mehrerer Nutzer versteht und sie automatisch zusammenführt, wäre das ein echter Produktivitätsschub.

  • Mit Claude Code kannst du das bereits nutzen. Du musst nur sagen: „Merge den anderen Branch und löse die Konflikte.“

  • Wie oft gerätst du in Merge-Conflict-Situationen?