Morph V3 Large: When Your Apply Model Should Be the Slow One

The difference between Morph's two apply models looks small on paper. Morph quotes V3 Fast at about 96% accuracy and V3 Large at about 98%. Two percentage points is the sort of gap most people round away.

Read the other way round, it is not small at all. A 4% failure rate becoming 2% means half as many broken merges. Whether that is worth paying for depends almost entirely on what a broken merge costs you, and that is the question this guide is about.

What V3 Large is for

Like its sibling, V3 Large is not a general model. It is an apply model: it takes an original file, a lazy edit that shows only the changed lines with // ... existing code ... markers standing in for the rest, and an instruction describing the change, and it returns the merged file. A frontier model decides what to change; the apply model does the mechanical rewrite.

If that split is new to you, the Morph V3 Fast guide explains the pattern, the request format and why agents use it instead of search-and-replace. This article assumes you already know the pattern and are deciding which model to put behind it.

The two-point gap, done properly

Suppose an agent fleet makes 2,000 file edits a day. At Morph's quoted figures, Fast would mis-merge around 80 of them and Large around 40. Forty fewer bad merges a day is the entire case for Large.

What each of those failures costs depends on whether anything notices:

• Caught by a compiler or test. The agent sees the error, re-reads the file and tries again. Cost: one extra loop iteration, which on a frontier model means re-sending the conversation. That is usually far more than the apply call itself.
• Caught by a human in review. Cost: reviewer attention, plus the agent session to fix it.
• Not caught. A duplicated block, a dropped line in a config file, a migration that merged in the wrong place. Cost: whatever that bug costs in production.

The first case is why apply accuracy matters more than its own price suggests. A failed merge does not cost one apply call; it costs a frontier-model turn to diagnose it. Escalation rate as a cost metric works through the same arithmetic for model choice generally.

The usual caveat applies: these are Morph's numbers on Morph's evaluation set. Your failure rates will differ, possibly a lot, depending on how well your editing model writes lazy snippets.

What you give up: speed, and a little money

Morph's documentation and launch post put V3 Large at more than 5,000 tokens per second, against more than 10,500 for Fast. Its live model list shows a lower figure for Large, so treat the exact rate loosely; the safe reading is that Large is roughly half the speed of Fast or less.

Half the speed of very fast is still fast. A file of a few thousand tokens merges in around a second on either. The latency cost becomes visible only on large files in interactive tools, where a user is waiting for the edit to land.

Price is a smaller gap than speed. At the time of writing, OpenRouter lists V3 Large at $0.90 per million input tokens and $1.90 per million output, against $0.80 and $1.20 for Fast. Since an apply call sends the whole file in and gets the whole file back, a merge is roughly balanced between input and output, so Large costs around a third more per merge. Against the price of one wasted frontier-model turn, that is noise.

Context is the other practical difference. OpenRouter lists V3 Large at a 262K window, with 131K of output, and structured output support; it lists Fast at about 82K. Morph's own API shows 262K for both. If you call through an aggregator and edit large files, Large may be the only option that fits.

Which edits deserve Large

Running Large on everything is defensible if your volume is low and your tests are thin. At volume, a routing rule is better. The edits where merge models most often go wrong share a pattern: the lazy snippet leaves the most to interpretation.

1. File size. Send files above a threshold — start around 500 lines and tune from data — to Large.
2. Marker count. A snippet with one elision marker is easy. One with six, each skipping a different region, is where models drift.
3. Repetition. Test files, route tables and generated code have many near-identical blocks, and a marker can plausibly anchor in more than one place.
4. Blast radius. Migrations, infrastructure configuration and anything without a test that would catch a mis-merge.

Morph's own API has an auto option that chooses per request. It is a sensible starting point, but writing the rule yourself means you can log which model handled each edit and see where the failures land. Model routing and fallbacks covers the general pattern, including retrying a failed Fast merge on Large rather than routing up front.

Measuring it before you commit

The test is the same one you would run for any apply model, and it is cheap. Take a sample of real edits from your agent logs: the original file, the lazy snippet, and the file that was eventually committed. Replay each through both Fast and Large and diff the outputs against the committed version.

Score each result as exact, whitespace-only, or wrong. Then break the wrong ones down by file size and marker count. If Large's advantage is concentrated in one bucket, route that bucket and leave the rest on Fast. If the two models fail on the same edits, the snippets are the problem, and the fix belongs in the editing model's prompt. If you are also weighing a different vendor, the Relace Apply 3 guide covers the main alternative, and the same replay harness works for it unchanged.