Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 196 posts

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#11

Post by bigyabai »

deepdarkforest wrote: post #9

> 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…

The marketing language seems to suggest they're insecure over quality and want to promote quantity. But I'm in the same boat as you - I would happily take 10 tok/sec of a correct answer instead of wasting an hour curating 4500 tok/sec throwaway answers. Benchmark performance matters 100x more than your latency.

If these "hot takes" extend into Morph's own development philosophy, then I can be glad to not be a user.

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#12

Post by bhaktatejas922 »

deepdarkforest wrote: post #9

> 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 think it depends - the actual thing to measure it to keep a developer in flow state. Many errors as well as latency break this. To be brief yes, accuracy comes first.

Quality is measured 2 main ways:

1) End-to-end: User query -> to task resolution. These are aider style benchmarks answering the question of actual task completion

2) Apply Quality: Syntax correctness, character diff, etc..

The error rate for large vs fast is around 2%. If you're doing code edits that are extremely complex or on obscure languages - large is the better option. There's also an auto option to route to the model we think is best for a task

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#13

Post by rs186 »

Sounds interesting, but I imagine all the big players (Cursor, Windsurf, and maybe even OpenAI/Anthropic) will achieve something similar very quickly in their tools first-party, which will decimate the company. And I don't get the API part of this -- at the end of the day people use those IDEs, and I don't see developers/companies want to send their code to yet another endpoint.

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#14

Post by bhaktatejas922 »

bigyabai wrote: post #11
deepdarkforest wrote: post #9

> 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…

The marketing language seems to suggest they're insecure over quality and want to promote quantity. But I'm in the same boat as you - I would happily take 10 tok/sec of a correct answer instead of wasting an hour curating 4500 tok/sec throwaway answers. Benchmark performance matters 100x more than your latency. If these "hot takes" extend into Morph's own development philosophy, then I can be glad to not be a user.

There's no amount of error rate that's acceptable to us - edits should always be correct. We've just found anecdotally the saving users time is just provably also very important for churn, retention and keeping developer flow state, right after accuracy.

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#15

Post by deepdarkforest »

bhaktatejas922 wrote: post #12
deepdarkforest wrote: post #9

> 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 think it depends - the actual thing to measure it to keep a developer in flow state. Many errors as well as latency break this. To be brief yes, accuracy comes first. Quality is measured 2 main ways: 1) End-to-end: User query -> to task resolution. These are aider style benchmarks answering the question of actual task completion 2) Apply Quality: Syntax correctness, character diff, etc.. The error rate for large vs…

Glad to hear quality comes first! Then I assume you have some public benchmarks like the ones you mention that are reproducible? I could only find this graph https://docs.morphllm.com/guides/apply but there is no mention of what it refers to, what data it used etc.

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#16

Post by bigyabai »

bhaktatejas922 wrote: post #14
bigyabai wrote: post #11

Earlier quoted context omitted.

The marketing language seems to suggest they're insecure over quality and want to promote quantity. But I'm in the same boat as you - I would happily take 10 tok/sec of a correct answer instead of wasting an hour curating 4500 tok/sec throwaway answers. Benchmark performance matters 100x more than your latency. If these "hot takes" extend into Morph's own development philosophy, then I can be glad to not be a user.

There's no amount of error rate that's acceptable to us - edits should always be correct. We've just found anecdotally the saving users time is just provably also very important for churn, retention and keeping developer flow state, right after accuracy.

Then why are you using a custom model instead of an industry-leading option?

I don't mean to be rude, but I can't imagine you're selling a product on-par with Claude 3.7. Some level of performance tradeoff has to be acceptable if you prioritize latency this hard.

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#17

Post by bhaktatejas922 »

rs186 wrote: post #13

Sounds interesting, but I imagine all the big players (Cursor, Windsurf, and maybe even OpenAI/Anthropic) will achieve something similar very quickly in their tools first-party, which will decimate the company. And I don't get the API part of this -- at the end of the day people use those IDEs, and I don't see developers/companies want to send their code to yet another endpoint.

Perhaps - Cursor does this in house. I see the coding agent space being large as we shift into a market of on-demand software.

Sending code externally is meh especially for companies with tight security rules. We do self-hosting for them in their infra

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#18

Post by candiddevmike »

bhaktatejas922 wrote: post #12
deepdarkforest wrote: post #9

> 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 think it depends - the actual thing to measure it to keep a developer in flow state. Many errors as well as latency break this. To be brief yes, accuracy comes first. Quality is measured 2 main ways: 1) End-to-end: User query -> to task resolution. These are aider style benchmarks answering the question of actual task completion 2) Apply Quality: Syntax correctness, character diff, etc.. The error rate for large vs…

I don't believe anyone can be in some kind of "flow state" while waiting on LLM responses. I think it's funny that we complained for years about C and others being slow to compile and now folks are fine waiting seconds++ everytime they want to change something.

Re: Launch HN: Morph (YC S23) – Apply AI code edits at 4,500 tokens/sec

#20

Post by bhaktatejas922 »

bigyabai wrote: post #16
bhaktatejas922 wrote: post #14

Earlier quoted context omitted.

There's no amount of error rate that's acceptable to us - edits should always be correct. We've just found anecdotally the saving users time is just provably also very important for churn, retention and keeping developer flow state, right after accuracy.

Then why are you using a custom model instead of an industry-leading option? I don't mean to be rude, but I can't imagine you're selling a product on-par with Claude 3.7. Some level of performance tradeoff has to be acceptable if you prioritize latency this hard.

We're not - our model doesn't actually think up the code changes. Claude-4 or Gemini still writes the code, we're just the engine that merges it into the original file.

Our whole thesis is that Claude and Gemini are extremely good at reasoning/coding - so you should let them do that, and pass it to Morph Fast Apply to merge changes in.

Post reply on HN