- Morph ist ein KI-gestützter Code-Editor, der schnelle Code-Änderungen für große Codebasen ermöglicht und dabei mehr als 4.500 Tokens pro Sekunde anwendet
- Entwickler können bei Aufgaben mit wiederholten oder großflächigen Änderungen durch die schnelle Verarbeitungsleistung der KI ihre Arbeitszeit verkürzen
- Anders als bestehende Tools ist es so aufgebaut, dass es sich auch auf große Projekte effizient anwenden lässt, ohne hohe Verarbeitungslast zu verursachen
Hauptmerkmale
- Unterstützt 4.500 Tokens/Sekunde: Morph kann dank hoher Durchsatzrate KI-Bearbeitungen schnell auf gewachsene Codebasen anwenden
- Einfache Nutzung: Eine nutzerorientierte UI und ein intuitiver Workflow senken die Einstiegshürde für KI-gestützte Codebearbeitung
- Vielseitigkeit: Bietet Skalierbarkeit für den breiten Einsatz in verschiedenen Programmiersprachen und Frameworks
Anwendungsfälle und erwartete Effekte
- Hohe Effizienz bei Code-Refactoring, Umbenennung von Variablen, massenhaftem Hinzufügen von Kommentaren und Automatisierung von Sicherheitspatches
- Bei Unternehmen und Startups mit großen Codebasen sind Einsparungen bei Zeit und Kosten zu erwarten
1 Kommentare
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 info@morphllm.com, 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.
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).
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?
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.
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
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.
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?