Morph (YC S23) – aplicação de edição de código com IA a 4.500 tokens por segundo

• Morph é um editor de código com inteligência artificial que oferece modificações de código em alta velocidade, aplicando mais de 4.500 tokens por segundo em codebases de grande escala
• Desenvolvedores podem reduzir o tempo de trabalho em tarefas repetitivas ou que exigem mudanças em larga escala por meio da capacidade de processamento rápido da inteligência artificial
• Diferente das ferramentas existentes, sua estrutura permite aplicação eficiente sem sobrecarga de processamento mesmo em projetos grandes

Principais características

• Suporte a 4.500 tokens/segundo: o Morph consegue aplicar rapidamente edições de IA em código acumulado graças à sua alta taxa de processamento
• Uso simples: oferece uma UI centrada no usuário e um fluxo de trabalho intuitivo, reduzindo a barreira de entrada da edição de código com IA
• Versatilidade: oferece escalabilidade para aplicação ampla em diversas linguagens de programação e frameworks

Casos de uso e efeitos esperados

• Refatoração de código, renomeação de variáveis, adição em massa de comentários, automação de patches de segurança e outros cenários com alta eficiência
• Empresas e startups com codebases de grande porte podem esperar economia de tempo e custos

[GN⁺]

Comentários no Hacker News

• Eu tendo a não concordar com a afirmação de que, na experiência do desenvolvedor, a precisão é mais importante do que a velocidade bruta de inferência. O motivo de os usuários preferirem modelos maiores, mesmo aceitando um tok/sec muito mais lento, é que a qualidade do código acaba sendo o primeiro critério. Em mudanças grandes de código (por exemplo, 5.000 tokens), uma latência de algo como 200~300 ms não é um número muito relevante. A velocidade de edição em si pesa menos do que a qualidade, não é o principal gargalo. Se reduzir 200 ms numa mudança de código for mais importante do que a qualidade, sinceramente não consigo me identificar com isso. Se você usar 1 ou 2 agentes em paralelo, a maior parte das correções já termina enquanto você ainda está revisando o código. Fico curioso sobre qual métrica vocês usam para medir qualidade e qual é a diferença na taxa de erro entre modelos rápidos e modelos grandes

  • Para mim, se a velocidade de inferência ficar cerca de 50% mais rápida, isso traz muito mais valor para o meu fluxo de trabalho do que uma melhoria de um dígito na precisão. De qualquer forma eu preciso verificar as mudanças manualmente, então um ciclo de iteração mais rápido parece melhor. Agora, se a precisão ficar alta o bastante a ponto de eu precisar validar menos, ou com menos frequência, aí a vantagem de velocidade de inferência praticamente deixa de importar

  • Concordo totalmente. Depois que um modelo de IA propõe uma alteração no código, a primeira coisa a fazer é sempre revisar esse resultado com muito cuidado. Na maioria dos casos, por causa de contexto ausente no prompt ou de certos tokens específicos, o código acaba sendo duplicado ou gerado de forma equivocada. Aplicar mudanças em lote só torna o debugging mais difícil, e quanto mais esse tipo de inserção massiva de código se acumula, maior a chance de o código se degradar mais rápido do que parece

  • Pelo que eu entendi, não é simplesmente algo na faixa de ±300 ms, e sim um abismo enorme, como 300 ms contra 10 segundos. Ficar esperando resposta desses modelos grandes definitivamente é uma limitação no meu caso. Além disso, é frustrante desperdiçar recursos em tarefas simples assim. Na verdade, acho que aplicar mudanças de código de forma inteligente é algo que ambientes de programação já conseguem tratar muito bem. Fico pensando se isso realmente é uma tarefa tão difícil a ponto de precisar de um LLM

  • Parece que, para você, o tempo de revisão é o gargalo. No momento estou criando recursos para ajudar alguém a revisar muito mais rápido o resultado de agentes de código. Se você tiver tempo, eu gostaria de entrevistar você com mais detalhes sobre o seu fluxo de trabalho. Seria ótimo se pudesse entrar em contato por comentário ou pelos meios que estão no meu perfil

  • Acho que o ponto central é manter o desenvolvedor em estado de flow. Tanto erros quanto atrasos quebram esse flow. No fim das contas, em programação, qualidade (correção) é o fator mais importante. Para avaliar qualidade, usamos basicamente 2 critérios. Primeiro, desempenho de ponta a ponta em toda a linha, da consulta do usuário até a conclusão da tarefa (benchmark no estilo aider); segundo, precisão da aplicação (problemas de gramática/sintaxe, diff em nível de caractere etc.). A diferença de taxa de erro entre modelos grandes e rápidos fica em torno de 2%. Se a linguagem for complexa ou difícil, o modelo maior é mais adequado, e também existe a opção de rotear automaticamente para o modelo mais apropriado para a tarefa

• Eu usei o Microsoft Copilot e achei tudo muito lento e pouco prático, especialmente na etapa de aplicar código. É estranho que um lugar com tantos recursos não tenha conseguido treinar direito o modelo. Pedido: coloquem na documentação oficial o prompt de sistema para que o LLM consiga gerar o melhor formato de diff possível. A cada upgrade de LLM o formato de diff costuma mudar, então é sempre um chute descobrir qual formato é o melhor. Além disso, a política de privacidade não está clara para mim; pela minha leitura, isso quer dizer que até dados de usuários pagos são armazenados/usados em treinamento? Queria saber como pagar pelo serviço sem telefone e sem que meus dados sejam usados para treinar. Consultei a Morph Privacy Policy

  • A opção ZDR (Zero Data Retention) também está disponível. Se você enviar um e-mail para [e-mail], configuramos isso para você. Se usar o Morph pelo OpenRouter, ele é sempre Zero Data Retention

  • Esse pedido de “não treinem o modelo com os meus dados” é meio engraçado. Esses modelos existem justamente porque foram treinados com código de outras pessoas. Usar essas ferramentas e ao mesmo tempo exigir que os seus dados não entrem no treinamento é, na prática, uma postura egoísta, quase como um dilema entre interesse individual e benefício coletivo. É assim que o modelo melhora

• Peguei o exemplo em HTML mostrado na demo oficial e apliquei exatamente igual em https://morphllm.com/dashboard/playground/apply, e mesmo sem eu pedir nenhuma mudança ele adicionou CSS e até criou uma seção de contato. Isso não estava nas instruções de atualização

  • Boa observação. O exemplo em HTML estava com um snippet hardcoded sem ter sido descomentado. Já corrigimos isso

• Em termos de custo, minha impressão é que o Morph é bem mais caro que o Gemini Flash. O Gemini Flash também consegue gerar código razoavelmente bem, e uma IA que aplica edições rapidamente é ótima, mas a faixa de preço não é nada leve. Por exemplo, o Morph v3 fast custa input de $1.20/M tokens e output de $2.70/M tokens, enquanto o Gemini 2.5 Flash custa input de $0.30/M tokens e output de $2.50/M tokens (referência: OpenRouter)

  • Esse é o preço da opção com retenção zero de dados. No site oficial da Morph, o preço é $0.80 por 1M tokens de input e $1.20 por 1M tokens de output. Também há política de desconto para grande volume/instâncias reservadas

• Perguntando para não confundir: o Morph é uma ferramenta para “aplicar” o resultado de outros LLMs, e não um LLM próprio? Ou seja, esses 4.500 tokens por segundo seriam de aplicação, não de geração?

  • Isso mesmo. Mas o Morph também é um LLM por si só. Na prática, a estrutura é de um LLM grande usando um LLM pequeno como se fosse uma tool call

• Muito impressionante. Estou procurando uma solução assim para um sistema interno de programação com IA, então queria entender em que ele difere de projetos open source como o Osmosis Apply 1.7B. Partindo do pressuposto de que o modelo da Morph não é open source/open weights

  • O ideal é testar os dois diretamente! Nosso modelo tem uma vantagem bem grande em velocidade e precisão

• Antes eu não via o Morph no OpenRouter, mas agora parece que ele entrou lá. Só que o modelo listado parece ser uma versão antiga? Há planos de dar um suporte mais ativo? E também tenho curiosidade sobre benchmarks comparando o modelo fast apply com Relace ou Llama/Cerebras em desempenho, especialmente precisão

  • O poder do Hacker News é impressionante! Agora os modelos novos também já estão listados lá

  • No momento, o modelo v2 está apontando para o morph-v3-large. Em breve, v3-large e v3-fast também serão adicionados

• Queria ver uma comparação com a Relace. As duas são empresas saídas do YC e parecem ter funcionalidades bem parecidas Relace

  • Boa pergunta. Até a lista de clientes (create.xyz, continue.dev) aparece igual

• Uma extensão de navegador que fizesse a ponte entre o ChatGPT e o VSCode, colocando o Morph (ou Claude) no meio, para usar agentic coding direto pela interface web, seria algo muito bom. A ideia é usar a interface web em vez da API

  • Dá para alcançar esse objetivo com MCP. Está para sair em breve

• Se existisse um recurso em que a IA automatizasse rebase+merge de forma inteligente, a velocidade de desenvolvimento aumentaria drasticamente. Se a IA conseguisse entender a intenção por trás das mudanças de código de vários usuários e mesclar tudo automaticamente, seria um ganho enorme de produtividade

  • Com o Claude Code isso já é possível. Basta pedir algo como “mescle a outra branch e resolva os conflitos"

  • Com que frequência você passa por situações de merge conflict?