---
title: "Fast Apply Makes Faster Agents"
url: "https://www.morphllm.com/blog/fast-apply-fast-agents"
description: "How Morph Fast Apply is our first step building the sub-agent future. Small, specialized models that escape the valley of death."
date: "2025-11-04"
author: ["Dhruv Bhatia","Dat Quoc","Tejas Bhakta"]
---
# Fast Apply Makes Faster Agents

![Cognition's Semi-Async Valley of Death](/images/valley-of-death.png)

*Image credit: @swyx from Cognition*

**Small models are the future of agentic AI.**

Cognition illustrated this idea really well with their "Semi-Async Valley of Death." We agree with their framing, and we've seen the same thing in practice.

We've worked with almost all of the top vibecoding platforms and conversions boil down to:
- **Accuracy** - did it do what the user wanted (not what they said)
- **Speed** - there's a floor to speed, users that will wait 180s will also wait 10m. Those who truly care about speed see conversion rates roughly double when speeds double - within cohorts that don't run into errors

To stay out of "the valley of death," work has to land in a few seconds while the user is still in flow, or run on its own for hours. The middle is where it hurts. Every second in there raises the odds of breaking flow by about 10%, so the time turns into friction instead of output. A good subagent pulls its work out of that middle: it makes the model faster and more accurate, and it doesn't burn the model's context window to do it.

For agentic code systems, this principle forces a design choice:
- **Fast, specialized models for interactive loops.**
- Larger, general models for long-horizon autonomy.

The first model we made to achieve faster agents is [Fast Apply](/products/fastapply).

## Fast Apply: Option 3

The most popular form of an agent is a coding agent. While large models are great at thinking about what code needs to be written, merging that code into a file is a messy and failure-prone process.

The main option is search and replace. It works, but requires a separate tool call for each chunk being edited. When the model needs to make multiple edits, the tool calls add up.

At Morph we've introduced an option 3: a small model which your LLM can delegate tasks to for faster and more accurate edits.

## Apply Accuracy (What Actually Matters)

Latency alone doesn't make a fast-apply system useful but accuracy is what unlocks real speed. If an apply model fails, the LLM has to re-think, re-generate, and re-issue the edit. That retry loop destroys latency wins and breaks flow. **Accuracy is speed.**

This is where most "fast" apply approaches fall apart.

When edits fail, the LLM must try again so practical latency spikes.

A real fast-apply model must:
- Understand and modify code reliably
- Execute edits correctly on the first try
- Minimize token overhead for describing changes

The correct benchmark isn't single-model speed. It's end-to-end task completion time.

That includes retries, model output length, and recovery from failures. That's why Morph Fast Apply outperforms: higher accuracy → fewer retries → consistently lower total latency.

Users don't care about tokens/second. They care about how long it takes for what they asked for. That's why wall-clock time is more relevant. When traditional search and replace (claude code) or fast apply fails, models need to retry, increasing the P(breaking flow state) as it happens.

![End-to-end time comparison](/images/e-time.png)

![Accuracy comparison](/images/e-acc.png)

## Benchmark Dataset

The benchmark runs on 50 repositories. About half are open-source libraries. The rest are vibe-coded apps we grabbed off real users. For each repo we wrote 10 to 20 feature requests or bug fixes, phrased the sloppy way a real person phrases them, not clean tickets: "can you make the sky orange in this game," "the upload isn't working, can you fix it," "add more logging."

Then, each request was sent to Claude in an environment that represented the average coding agent. Claude was responsible for finding and fixing the bug using the tool we specified. This might be search and replace, full file edits, or third-party apply models. We then ran test cases to verify bug fixes and use an LLM as a judge to verify feature implementations. We also manually looked through randomly selected samples to ensure our evaluations were working correctly. The goal of the setup is to perfectly mimic an agentic coding environment.

## The Infra That Got Us to 10,500 tokens/sec

Getting here took more than shrinking a model. We built a new execution path for code-editing agents:

1. Custom CUDA kernels fusing attention and feed-forward ops, eliminating redundant memory.
2. A custom speculative decoding pipeline against the original file, delivering 5× practical speed-ups.
3. A purpose-built model architecture for merging code, with pruned vocabulary and hierarchical positional encodings for AST-like structure.

Purpose-built beats general-purpose when tasks are scoped. Agent systems are being architected around the minimum compute to complete a scoped task to high fidelity.

## The difference comes down to data quality

The open-source Fast Apply dataset which is now used across the ecosystem was originally built by Morph engineers.

The first version used the obvious approach: prompt an LLM to generate synthetic training data for code application. That data was clean, and clean is exactly the problem. It looks nothing like what a coding agent actually emits when it's working with half the context, a vague instruction, and edits spread across four files. Real agent output is messier than any prompt will hand you.

morph-fast-apply came out of a much harder pipeline. We distill from several frontier models and verify in stages, both with an LLM checker and with plain programmatic checks that feed the reward signal. The verification is the easy part to describe and the hard part to do. Most of our time goes into edge cases, poking at how the model should behave when the answer isn't obvious. Was that a syntax nitpick or a real style choice. Did the agent mean to drop that line or forget it. Long into a session, agents start leaving out the markers for code they didn't touch. Each of those calls is small, the set of them is finite, and getting them all right is most of the work.

The part that matters most: our training data is real agent output from production, not synthetic "please make an edit" prompts. Every week we retrain, and every failed edge case from the week before goes back into the pipeline. That loop between what actually breaks in production and what the model learns next is the whole reason apply holds up at scale.

## May the fastest systems win

Human intelligence organizes itself in tiers with the smartest among us at the top delegating work to those with lesser experience. Models will organize in a similar fashion with some of the largest and heaviest models at the very top that delegate work to subagents that get increasingly smaller and faster. Morph is building this sub-agent future, with fast apply only being the beginning.

Our goal is to prevent you from seeing a message like this ever again:

![Jump Scare](/images/str-not-found.png)