Morph (YC S23) applique l’édition de code par IA à 4 500 tokens par seconde

• Le goulot d’étranglement vient du moment où les modifications générées par les outils de coding IA doivent être appliquées aux fichiers existants ; Morph veut remplacer la réécriture complète des fichiers et le fragile search-and-replace avec son modèle Fast Apply
• Les agents produisent une sortie d’édition lâche qui laisse les lignes non modifiées sous une forme comme //...existing code..., puis Morph applique les changements réels à partir du fichier source
• Parmi les modèles proposés, morph-v3-fast atteint 4 500+ tok/sec et morph-v3-large 2 500+ tok/sec ; ils sont utilisés chez create.xyz, databutton, continue.dev, etc.
• Pour la recherche, Morph fournit aussi des modèles d’embedding et de reranking, et prépare comme prochains produits un modèle d’édition inline de style Cmd-K ainsi que l’API Morph Tab avec une latence inférieure à 500 ms
• L’approche a d’abord été ouverte par Cursor, mais n’a pas été exposée sous forme d’API ; Morph mise sur une API directement intégrable par les développeurs et sur une large offre gratuite

---

Le goulot d’étranglement de l’application des éditions de code par IA

• Pour Morph, le problème central est d’insérer de manière fiable dans le code existant les modifications générées par l’IA
  • Réécrire l’intégralité d’un fichier peut être lent et coûteux
  • L’approche search-and-replace peut casser au moindre écart et provoquer des erreurs
• Morph conçoit donc les agents pour qu’ils produisent les modifications sous une forme lâche
  • Les lignes existantes non modifiées sont référencées sous une forme comme // ...existing code...
  • En prenant en entrée le fichier source et ce patch lâche, le modèle Fast Apply applique ensuite les vraies modifications avec speculative decoding
• L’objectif est de rendre les patchs IA plus rapides, plus fiables et plus faciles à utiliser en production
• Ressources associées :
  • Vidéo de démonstration
  • Démo en direct
  • Documentation

Gamme de modèles et prochains produits

• Morph propose deux modèles Fast Apply
  • morph-v3-fast : 4 500+ tok/sec
  • morph-v3-large : 2 500+ tok/sec
• Ces modèles servent à faire tourner Fast Apply chez create.xyz, databutton, continue.dev, etc.
• Pour la recherche de code, Morph propose aussi des modèles de recherche pour l’embedding et le reranking
• Les prochaines fonctionnalités visent à raccourcir davantage le flux d’édition
  • Inline Edit Model, Cmd-K : une édition inline très rapide qui ne casse pas le flux de développement
  • API Morph Tab : un modèle qui prédit les prochaines éditions et actions de code, avec une latence visée inférieure à 500 ms, actuellement en bêta privée
• Morph estime que, dans l’expérience développeur, la vitesse brute d’inférence compte, et que l’édition Fast Apply est meilleure que la réécriture complète d’un fichier en termes de vitesse, de coût et de fiabilité
• Selon l’entreprise, une fois que les benchmarks étroits d’une tâche atteignent une saturation de plus de 99 %, la complexité se déplace d’un unique frontier model vers des modèles spécialisés et optimisés pour l’inférence

[GN⁺]

Avis Hacker News

• Je ne suis pas vraiment d’accord avec l’idée que, dans l’expérience développeur, la vitesse brute d’inférence compte moins que la précision. Si les utilisateurs acceptent un nombre de tok/sec bien plus faible pour préférer des modèles plus gros, c’est au final parce que la qualité du code reste le premier critère. Sur de grosses modifications de code (par ex. 5a0000 tokens), une latence de 200 à 300 ms n’a pas beaucoup d’importance. Le vrai goulot d’étranglement n’est pas tant la vitesse d’édition que la qualité. Si gagner 200 ms sur un changement de code passe avant la qualité, je n’adhère pas du tout à cette logique. Avec 1 ou 2 agents en parallèle, la plupart des corrections sont déjà terminées pendant que je relis le code. Je serais curieux de connaître vos critères de mesure de la qualité, ainsi que l’écart de taux d’erreur entre les modèles rapides et les grands modèles

  • J’ai l’impression qu’une hausse d’environ 50 % de la vitesse d’inférence apporte bien plus de valeur à mon flux de travail qu’une amélioration de la précision de quelques points. De toute façon, je dois vérifier moi-même les changements, donc un cycle d’itération plus rapide me semble préférable. En revanche, si la précision devient suffisamment bonne pour que je doive moins vérifier, ou moins souvent, alors l’avantage de la vitesse d’inférence perd presque toute importance

  • Entièrement d’accord. Après qu’un modèle d’IA a proposé une modification de code, la toute première étape est toujours de relire soigneusement le résultat. Dans la plupart des cas, à cause d’un contexte manquant dans le prompt ou de certains tokens spécifiques, le code finit souvent dupliqué ou généré de manière aberrante. Appliquer les changements en bloc rend le débogage plus difficile, et plus ce type d’insertion massive de code s’accumule, plus le code risque de se dégrader beaucoup plus vite qu’on ne l’imagine

  • Si j’ai bien compris, on ne parle pas simplement de ±300 ms, mais d’un écart énorme, du genre 300 ms contre 10 secondes. L’attente de réponse de ces grands modèles est clairement une contrainte pour moi. En plus, j’ai le sentiment que cela consomme inutilement des ressources pour ce genre de tâches simples. En réalité, appliquer intelligemment des modifications de code me semble être un domaine que les environnements de programmation existants peuvent déjà traiter correctement. Je me demande vraiment si c’est à ce point une tâche difficile qu’elle nécessite absolument un LLM

  • On dirait que, pour toi, le temps de revue est le véritable goulot d’étranglement. Je travaille justement en ce moment sur une fonctionnalité qui aide à relire beaucoup plus vite les résultats produits par des agents de code. Si tu as un peu de temps, j’aimerais bien discuter plus en détail de ton workflow. N’hésite pas à me contacter en commentaire ou via les coordonnées de mon profil

  • À mon avis, le plus important est que le développeur reste en état de flow. Les erreurs comme la latence cassent toutes deux cette concentration. En fin de compte, en programmation, la qualité (la justesse) reste le facteur le plus important. Pour évaluer la qualité, nous utilisons principalement deux critères. Premièrement, les performances de bout en bout sur toute la chaîne, depuis la requête utilisateur jusqu’à l’accomplissement de la tâche (un bench de style aider) ; deuxièmement, la précision d’application (problèmes de grammaire/syntaxe, diff au niveau caractère, etc.). L’écart de taux d’erreur entre grands modèles et modèles rapides est d’environ 2 %. Pour des langages complexes ou difficiles, les grands modèles sont plus adaptés, et il existe aussi une option de routage automatique vers le modèle le plus approprié selon la tâche

• J’ai essayé microsoft copilot, et je l’ai trouvé beaucoup trop lent et peu pratique, surtout à l’étape d’application du code. Je trouve étrange qu’un acteur aussi bien doté en ressources n’ait pas réussi à mieux entraîner le modèle. Demande : j’aimerais que le prompt système permettant à un LLM de générer le meilleur format de diff possible soit inclus dans la documentation officielle. Avec chaque mise à jour de LLM, le format de diff change souvent, donc on doit toujours deviner quel format est optimal, ce qui est pénible. En plus, je ne comprends pas clairement la politique de confidentialité ; si j’interprète bien le texte, cela veut-il dire que même les utilisateurs payants voient leurs données stockées/utilisées pour l’entraînement ? J’aimerais savoir comment payer simplement le service (sans appel) tout en évitant que mes données servent à l’entraînement. Je me réfère à la Morph Privacy Policy

  • L’option ZDR (Zero Data Retention) est également possible. Il suffit d’envoyer un mail à [e-mail] et nous l’activerons. Si vous utilisez Morph via OpenRouter, c’est toujours en Zero Data Retention

  • La demande du type « n’entraînez pas le modèle sur mes données » me paraît un peu absurde. Le principe même de ces modèles, c’est qu’ils ont été entraînés sur le code des autres. Utiliser ce type d’outil tout en refusant que ses propres données servent à l’entraînement, c’est au fond une position assez égoïste, proche d’un dilemme d’intérêt collectif. C’est aussi comme ça que les modèles s’améliorent

• J’ai repris tel quel l’exemple HTML présenté dans la démo officielle sur https://morphllm.com/dashboard/playground/apply, et sans demander aucune modification, du CSS a été ajouté et une section contact est même apparue. Rien de tout cela ne figurait dans les instructions de mise à jour

  • Bien vu. L’exemple HTML contenait un snippet codé en dur qui n’avait pas été décommenté. C’est corrigé maintenant

• Côté coût, j’ai l’impression que Morph est nettement plus cher que Gemini Flash. Gemini flash est déjà assez bon pour la génération de code, et une IA qui applique rapidement les edits est intéressante, mais le niveau de prix n’est pas anodin. Par exemple, Morph v3 fast coûte $1.20/M tokens en entrée et $2.70/M tokens en sortie, alors que Gemini 2.5 Flash coûte $0.30/M tokens en entrée et $2.50/M tokens en sortie (source : OpenRouter)

  • Ce tarif correspond à l’option zéro conservation de données. Sur le site officiel de Morph, le prix est de $0.80 / 1M tokens en entrée et $1.20 / 1M tokens en sortie. Il existe aussi des remises pour les gros volumes / instances réservées

• Je pose la question au cas où il y aurait confusion : est-ce que Morph est un outil qui « applique » les résultats d’autres LLM, plutôt qu’un LLM en soi ? Autrement dit, les 4a0500 tokens par seconde correspondent-ils à l’application et non à la génération ?

  • Oui. Mais Morph est aussi lui-même un LLM. En pratique, l’architecture fonctionne comme un grand LLM qui utilise un petit LLM un peu comme un tool call

• Très impressionnant. Je cherche justement ce type de solution pour un système interne de coding assisté par IA ; je serais curieux de savoir en quoi cela diffère de projets open source comme Osmosis Apply 1.7B. En partant du principe que le modèle Morph n’est ni open source ni open weight

  • Le mieux est de tester les deux directement ! Notre modèle est nettement supérieur en vitesse comme en précision

• Je n’avais pas vu Morph sur OpenRouter auparavant, mais il semble maintenant y être. En revanche, le modèle enregistré a l’air d’être une ancienne version ? Avez-vous l’intention de le supporter plus activement ? Et je serais aussi intéressé par des benchmarks comparant le modèle fast apply à Relace ou à Llama/Cerebras en termes de performances, surtout sur la précision

  • La puissance de Hacker News est impressionnante ! Les nouveaux modèles y sont désormais aussi enregistrés

  • Actuellement, le modèle v2 pointe vers morph-v3-large. v3-large et v3-fast seront ajoutés prochainement

• Je suis curieux d’avoir une comparaison avec Relace. Les deux sont des sociétés issues de YC, et les fonctionnalités semblent très proches Relace

  • Bonne question. Même la liste de clients affichée (create.xyz, continue.dev) est identique

• Une extension navigateur qui ferait le pont entre ChatGPT et VSCode, avec Morph (ou Claude) au milieu, pour exploiter directement le coding agentic depuis une UI web, ce serait vraiment excellent. L’idée serait d’utiliser l’interface web plutôt qu’une API

  • Avec MCP, cet objectif est atteignable. Sortie prévue bientôt

• Si l’IA pouvait automatiser intelligemment le rebase + merge, la vitesse de développement augmenterait énormément. Si l’IA pouvait fusionner automatiquement les changements de code de plusieurs utilisateurs en comprenant même l’intention derrière, ce serait un vrai gain de productivité

  • En utilisant Claude Code, cette fonctionnalité existe déjà. Il suffit de demander : « fusionne l’autre branche et résous les conflits »

  • À quelle fréquence te retrouves-tu dans des situations de merge conflict ?