Earlier quoted context omitted.
Correct, but morph is a LLM as well. In practice its basically Big LLM using small LLM as a tool call
Big LLM and small LLM, very Starbucks sizing vibes here.
That would be Grande LLM and Tall LLM.
Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
131–140 of 196 posts
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#132> 1) Raw inference speed matters more than incremental accuracy gains for dev UX—agree or disagree? I know you are trying to generate some controversy/visibility, but i think if we are being transparent here, you know this is wrong. People prefer using larger (or reasoning) models, with much bigger diff in tok/sec just for quality in coding, it comes first. Even if i have a big edit to apply, like 5k tokens, 200-300m…
Sounds like review time is the bottleneck for you.
I'm currently working on something that that makes people much faster at reviewing the output of coding agents. If you have some time, I'm very interested in interviewing you about your workflows. Just reply here, or find my contact information in my profile.
-- Jimmy Koppel, Ph. D.
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#133Seems completely broken. I used the provided HTML example on https://morphllm.com/dashboard/playground/apply . Without editing anything at all, I pressed apply. Your model added a bunch of CSS even though that wasn't in the update instructions at all. It also added a contact section, which again, wasn't in the update instructions that your demo provided.
nice catch. the html example was using a hardcoded snippet we forgot to uncomment. fixed
Thanks I will give it another try because our use case is HTML/Markdown documents, not code, and this could be interesting. I'm just hesitant to trust an LLM to do replacements and your broken example really didn't help with my confidence. Even a 1% error rate wouldn't be worth it because if find/replace doesn't work you know it doesn't work and can feed that error back into the agent to fix it (like how Claude Code recovers from its editing errors)
edit: The example is still broken. I've inspected the network request and it's definitely your backend that is broken not something being hardcoded... The CSS is not present in the request at all, but in the response it's being inserted.
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#134Really impressive. I'm in the market for such a solution for our internal AI coding systems - how do you compare to the opensource https://huggingface.co/osmosis-ai/Osmosis-Apply-1.7B ? I am assuming your models are not opensource/openweights?
You should give both a try! key difference is our models are faster and more accurate by a large margin
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#135"Let's be wrong faster! It's a feature, we swear!"
[deleted]
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#136> 1) Raw inference speed matters more than incremental accuracy gains for dev UX—agree or disagree? I know you are trying to generate some controversy/visibility, but i think if we are being transparent here, you know this is wrong. People prefer using larger (or reasoning) models, with much bigger diff in tok/sec just for quality in coding, it comes first. Even if i have a big edit to apply, like 5k tokens, 200-300m…
I do find that having inference happen ~50% faster is much more valuable to my workflow than a single digit accuracy increase. If I'm going to have to check that the changes are correct anyways, getting more iterations in faster feels much better than incremental accuracy. There's definitely a tipping point though. If the accuracy gains are so high that I can check its work less carefully or less often, the benefits…
I've been using Cursor pretty extensively in the past few months and I use it to code pretty hard problems sometimes, and a while ago when the options were between claude 3.5 sonnet vs gemini 2.5 pro, there was such a significant difference in quality that claude 3.5 often straight up failed -- the code it wrote woudln't work, even after retrying over and over again, and gemini 2.5 pro often was able to solve it correctly. In a particular project I even had to almost exclusively use gemini 2.5 pro to continue to make any progress despite having to wait out the thinking process every time (gemini was generally slower to begin with, and then the thinking process often took 30-90 seconds).
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#137> 1) Raw inference speed matters more than incremental accuracy gains for dev UX—agree or disagree? I know you are trying to generate some controversy/visibility, but i think if we are being transparent here, you know this is wrong. People prefer using larger (or reasoning) models, with much bigger diff in tok/sec just for quality in coding, it comes first. Even if i have a big edit to apply, like 5k tokens, 200-300m…
Fully agree.
The very 1st thing you do after you get a proposed set of changes from an AI model is to review them carefully before applying them. Most of the time it duplicates code because it skipped specific tokens or context that was out of it's window and the user didn't include it in their prompt.
Batch applying any changes is just a way to create even harded code to debug and accumulating such bulk code injections will definietly break your code much earlier than you think.
B, Sam
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#138Earlier quoted context omitted.
nice catch. the html example was using a hardcoded snippet we forgot to uncomment. fixed
Thanks I will give it another try because our use case is HTML/Markdown documents, not code, and this could be interesting. I'm just hesitant to trust an LLM to do replacements and your broken example really didn't help with my confidence. Even a 1% error rate wouldn't be worth it because if find/replace doesn't work you know it doesn't work and can feed that error back into the agent to fix it (like how Claude Code…
took a closer look, the update snippet provided is referencing css thats not defined.
this is sort of a overreach example of the "semantic" nature of the edits - ie, if an update explicitly contains syntax, or minor reference errors, the apply model corrects them. you can argue that this is an overstep in this example - but at the same time its not something claude/gemini would suggest
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#1391- I agree that speed is intelligence[+], but you're suggesting we can reduce accuracy, increase speed, and get better results. I don't buy it.
2- I'm confused. Claude Code and a Neovim plugin I used both do edits/diffs. Are you saying they're actually rewriting entire files instead?
3- Aren't "simple tasks" just things you train the model on? If so, are you solving a bunch of simple tasks or offering custom training?
> No more slow full-file rewrites or brittle search-and-replace hacks.
Here's the thing - LLMs are already blazing fast. I commented the other day that you could probably write Chrome's entire code base in a couple months at average speed. The bottleneck isn't speed, it's accuracy; that's of course my opinion.
Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec
#140> 1) Raw inference speed matters more than incremental accuracy gains for dev UX—agree or disagree? I know you are trying to generate some controversy/visibility, but i think if we are being transparent here, you know this is wrong. People prefer using larger (or reasoning) models, with much bigger diff in tok/sec just for quality in coding, it comes first. Even if i have a big edit to apply, like 5k tokens, 200-300m…
Fully agree. The very 1st thing you do after you get a proposed set of changes from an AI model is to review them carefully before applying them. Most of the time it duplicates code because it skipped specific tokens or context that was out of it's window and the user didn't include it in their prompt. Batch applying any changes is just a way to create even harded code to debug and accumulating such bulk code injecti…
if you've used cursor, you've probably felt how seamless fast apply can feel - fast apply is accurate and fast to the point where most don't even realize its a model