Morph (YC S23), aplica edición de código con IA a 4,500 tokens por segundo

• Cuando el proceso de pegar en archivos existentes los cambios generados por herramientas de programación con IA se volvió un cuello de botella, Morph busca reemplazar la reescritura completa del archivo y el frágil método de buscar y reemplazar con su modelo Fast Apply
• Los agentes generan una salida de edición flexible que deja las líneas no modificadas como //...existing code..., y Morph aplica los cambios reales tomando como base el archivo original
• Los modelos disponibles son morph-v3-fast con 4,500+ tok/sec y morph-v3-large con 2,500+ tok/sec; se usan en create.xyz, databutton, continue.dev y otros
• Para búsqueda, ofrece modelos de embeddings y reranking, y como próximos productos prepara un modelo de edición inline estilo Cmd-K y la API de Morph Tab con latencia sub-500ms
• Es un enfoque que Cursor abrió primero, pero no lo expuso como API; Morph apuesta por una API que los desarrolladores pueden integrar directamente y por un gran nivel gratuito

---

El cuello de botella al aplicar ediciones de código con IA

• La idea central de Morph es que insertar de forma confiable en código existente los cambios generados por IA es un problema clave
  • Reescribir el archivo completo puede ser lento y costoso
  • El método de buscar y reemplazar puede romperse fácilmente incluso con pequeñas diferencias y provocar errores
• Morph diseña a los agentes para que produzcan los cambios de forma flexible
  • Las líneas existentes que no se modifican se referencian como // ...existing code...
  • Toma como entrada el archivo original y el parche flexible, y aplica la edición real con el modelo Fast Apply y decodificación especulativa
• El objetivo es hacer que los parches de IA sean más rápidos, más estables y más fáciles de usar en producción
• Puedes revisar materiales relacionados abajo
  • Video demo
  • Demo en vivo
  • Documentación

Línea de modelos y próximos productos

• Morph ofrece dos modelos Fast Apply
  • morph-v3-fast: 4,500+ tok/sec
  • morph-v3-large: 2,500+ tok/sec
• Estos modelos se usan para impulsar Fast Apply en create.xyz, databutton, continue.dev y otros
• También ofrece modelos de búsqueda para embeddings y reranking orientados a búsqueda de código
• Las próximas funciones están enfocadas en acortar aún más el flujo de edición
  • Inline Edit Model, Cmd-K: edición inline muy rápida que no interrumpe el flujo de desarrollo
  • Morph Tab API: un modelo que predice la siguiente edición y acción de código, con latencia objetivo de sub-500ms y actualmente en beta privada
• Morph considera que, en la experiencia del desarrollador, la velocidad bruta de inferencia es importante, y que la edición con Fast Apply supera a la reescritura completa de archivos en velocidad, costo y confiabilidad
• Su visión es que, cuando los benchmarks de tareas estrechas se saturan por encima del 99%, la complejidad se desplaza desde un único modelo frontier hacia modelos especializados y optimizados para inferencia

[GN⁺]

Comentarios en Hacker News

• No estoy muy de acuerdo con la idea de que, en la experiencia del desarrollador, la precisión importa más que la velocidad bruta de razonamiento. Si los usuarios aceptan un tok/sec mucho más lento y aun así prefieren modelos más grandes, es porque la calidad del código termina siendo el criterio principal. En cambios grandes de código, por ejemplo de 5,000 tokens, una latencia de 200~300 ms no significa gran cosa. Más que la velocidad de edición en sí, el factor más importante es la calidad. Si alguien prioriza ahorrar 200 ms por encima de la calidad al modificar código, la verdad no lo comparto. Si usas 1 o 2 agentes en paralelo, la mayor parte de los cambios ya está lista mientras revisas el código. Me da curiosidad saber con qué métricas evalúan la calidad y qué tanta diferencia de tasa de error hay entre el modelo rápido y el grande

  • A mí me parece que una mejora de alrededor del 50% en velocidad de inferencia aporta mucho más valor a mi flujo de trabajo que una mejora de un solo dígito en precisión. De todos modos tengo que revisar personalmente los cambios, así que un ciclo de iteración más rápido se siente mejor. Ahora bien, si la precisión fuera lo bastante alta como para verificar menos o con menos frecuencia, entonces la ventaja de velocidad de inferencia casi dejaría de importar

  • Totalmente de acuerdo. Después de que un modelo de IA propone cambios de código, lo primero que hay que hacer siempre es revisar ese resultado con mucho cuidado. En la mayoría de los casos, por contexto faltante en el prompt o por ciertos tokens, el código termina duplicado o se genera algo fuera de lugar. Si aplicas los cambios de golpe, depurar se vuelve más difícil, y mientras más se acumulan estas inserciones masivas de código, más probable es que el código se arruine antes de lo esperado

  • Según entiendo, no estamos hablando solo de ±300 ms, sino de una diferencia enorme, como 300 ms frente a 10 segundos. Esa espera de respuesta de los modelos grandes sí es una limitación clara para mí. Además, da la impresión de que se gastan recursos innecesariamente en tareas tan simples. De hecho, creo que aplicar cambios de código de forma inteligente es algo que los entornos de programación existentes ya pueden manejar bastante bien. Me pregunto si de verdad es una tarea tan difícil como para requerir un LLM

  • Parece que para ti el cuello de botella es el tiempo de revisión. Yo estoy construyendo una función que ayude a las personas a revisar mucho más rápido los resultados de los agentes de código. Si tienes tiempo, me gustaría entrevistar un poco más a fondo tu flujo de trabajo. Si te interesa, contáctame por comentario o por los datos de contacto de mi perfil

  • Creo que la clave es que el desarrollador mantenga el estado de flow. Tanto los errores como la latencia rompen ese flow. En conclusión, en programación la calidad (precisión) es el factor más importante. Para evaluar la calidad usamos dos criterios principales. Primero, rendimiento de extremo a extremo en toda la línea desde la consulta del usuario hasta la finalización de la tarea (un benchmark estilo aider); segundo, precisión de aplicación (problemas de gramática/sintaxis, diff a nivel de caracteres, etc.). La diferencia de tasa de error entre el modelo grande y el rápido es de alrededor del 2%. Si el lenguaje es complejo o difícil, el modelo grande resulta más adecuado, y también existe la opción de enrutar automáticamente al modelo apropiado según la tarea

• He probado microsoft copilot y me pareció demasiado lento e incómodo, sobre todo en la etapa de aplicar código. Me sorprende que en un lugar con tantos recursos no hayan entrenado bien el modelo. Solicitud: ojalá incluyeran en la documentación oficial el system prompt para que el LLM pueda generar el mejor formato de diff posible. Con cada actualización del LLM el formato de diff suele cambiar, así que siempre toca adivinar cuál es el mejor formato. Además, no me queda clara la política de privacidad; según la interpreto, ¿significa que incluso los usuarios de pago tienen sus datos almacenados/usados para entrenamiento? Me gustaría saber cómo pagar por el servicio sin llamadas y sin que mis datos se usen para entrenar. Consulté Morph Privacy Policy

  • También ofrecemos la opción ZDR (Zero Data Retention). Si escribes a [e-mail], te lo configuramos. Si usas Morph a través de OpenRouter, siempre es Zero Data Retention

  • La exigencia de “no entrenen el modelo con mis datos” me parece un poco absurda. Estos modelos existen justamente porque fueron entrenados con código de otras personas. Usar estas herramientas y al mismo tiempo pedir que tus datos no se utilicen para entrenamiento es, en el fondo, una postura egoísta, algo parecido al dilema del beneficio colectivo. Así es como estos modelos mejoran

• Probé tal cual el ejemplo HTML de la demo oficial en https://morphllm.com/dashboard/playground/apply y, aunque no pedí ningún cambio, se añadió CSS y hasta apareció una sección de contacto. Eso no estaba en las instrucciones de actualización

  • Buena observación. El ejemplo HTML tenía un snippet hardcodeado sin descomentar. Ya lo corregimos

• En costos, me da la impresión de que Morph es bastante más caro que Gemini Flash. Gemini Flash también genera código bastante decente, y la idea de una IA que aplique ediciones rápidamente está buena, pero el precio no es nada menor. Por ejemplo, Morph v3 fast cuesta $1.20/M tokens de entrada y $2.70/M tokens de salida, mientras que Gemini 2.5 Flash cuesta $0.30/M tokens de entrada y $2.50/M tokens de salida (referencia: OpenRouter)

  • Ese es el precio con la opción de cero retención de datos. En el sitio oficial de Morph, el precio es $0.80 por 1M tokens de entrada y $1.20 por 1M tokens de salida. También hay descuentos para volumen/instancias reservadas

• Pregunto para no confundirme: ¿Morph es una herramienta para “aplicar” resultados de otros LLM y no un LLM propio? ¿Lo de 4,500 tokens por segundo se refiere a la aplicación y no a la generación?

  • Correcto. Pero Morph también es un LLM en sí mismo. En la práctica, la estructura es que un LLM grande utiliza un LLM pequeño como si fuera una tool call

• Muy impresionante. Estoy buscando una solución así para un sistema interno de programación con IA, y me interesa saber en qué se diferencia frente a proyectos open source como Osmosis Apply 1.7B. Asumo que el modelo de Morph no es open source/open weight

  • ¡Lo mejor es probar ambos directamente! Nuestro modelo lleva una ventaja clara tanto en velocidad como en precisión

• Antes no veía Morph en OpenRouter, pero parece que ahora ya está ahí. Aun así, da la impresión de que el modelo listado es una versión antigua. ¿Piensan darle un soporte más activo? Y también me interesan benchmarks del modelo fast apply frente a Relace o Llama/Cerebras, especialmente en rendimiento y precisión

  • ¡El poder de Hacker News es enorme! Ahora también están listados ahí los modelos nuevos

  • Por ahora el modelo v2 apunta a morph-v3-large. Pronto también se agregarán v3-large y v3-fast

• Me interesa la comparación con Relace. Ambas son empresas salidas de YC y sus funciones parecen muy parecidas Relace

  • Buena pregunta. Incluso la lista de clientes (create.xyz, continue.dev) aparece igual

• Una extensión de navegador que haga de puente entre ChatGPT y VSCode, metiendo Morph (o Claude) en medio, sería genial para aprovechar de inmediato el agentic coding desde una UI web. La idea sería usar la interfaz web en vez de la API

  • Con MCP se puede lograr ese objetivo. Sale pronto

• Si hubiera una función donde la IA automatice de forma inteligente rebase+merge, la velocidad de desarrollo podría dispararse. Si la IA entendiera la intención detrás de los cambios de código de varios usuarios y los fusionara automáticamente, eso sí sería una gran mejora de productividad

  • Si usas Claude Code, esa función ya existe. Solo tienes que pedirle: “fusiona otra rama y resuelve los conflictos”

  • ¿Con qué frecuencia te topas con conflictos de merge?