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

• Morph es un editor de código impulsado por inteligencia artificial que ofrece una función de modificación rápida de código, aplicando más de 4,500 tokens por segundo en bases de código a gran escala
• Los desarrolladores pueden reducir su tiempo de trabajo en tareas repetitivas o que requieren cambios masivos gracias a la rápida capacidad de procesamiento de la inteligencia artificial
• A diferencia de las herramientas existentes, tiene una estructura que puede aplicarse de forma eficiente sin sobrecarga de procesamiento incluso en proyectos grandes

Características principales

• Soporte de 4,500 tokens/segundo: Morph puede aplicar rápidamente ediciones de IA al código acumulado gracias a su alto rendimiento
• Uso sencillo: ofrece una interfaz centrada en el usuario y un flujo de trabajo intuitivo, reduciendo la barrera de entrada para la edición de código con IA
• Versatilidad: ofrece escalabilidad para aplicarse ampliamente a diversos lenguajes de programación y frameworks

Casos de uso y efectos esperados

• Demuestra alta eficiencia en refactorización de código, cambio de nombres de variables, adición masiva de comentarios y automatización de parches de seguridad
• En empresas y startups con bases de código de gran volumen, se pueden esperar ahorros de tiempo y costos

[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?