Morph V3 Fast: An Apply Model, Not a Chat Model

If you send Morph V3 Fast a question, you will get a poor answer. That is not a flaw. It is not a general model and was never meant to be one. It is an apply model: it takes an original file and a sketch of an edit, and returns the merged file. Nothing else.

That narrow job exists because the way coding agents edit files is surprisingly wasteful. Understanding why tells you whether Morph V3 Fast belongs in your stack, and whether you need it or its slower sibling.

The problem an apply model solves

A coding agent has three ways to change a file. It can rewrite the whole thing, which burns expensive frontier-model output tokens on lines that did not change. It can emit search-and-replace blocks, which fail whenever the search string does not match exactly, and need one tool call per hunk. Or it can write a short "lazy" edit that shows only the changed lines, with markers standing in for everything else, and hand that to a second model to merge.

The third option splits the work. The expensive model does the thinking and writes a few dozen lines. A small, fast, cheap model does the mechanical part: reproducing the file with the edit applied. Morph V3 Fast is built for that second step, and Morph sells it as an API that any agent can call. It is not the only vendor doing so; if you are comparing options, the Relace Apply 3 guide covers the main alternative.

What a request looks like

Morph exposes an OpenAI-compatible chat completions endpoint. The whole request is one user message with three tagged parts: an instruction describing the change, the original code, and the lazy update.

<instruction>Add a guard for a missing user and drop the legacy check</instruction>
<code>...the full original file...</code>
<update>
// ... existing code ...
if (!user) throw new Error("User not found");
// ... existing code ...
</update>

The response content is the merged file. Morph's quickstart is specific about one detail that is easy to get wrong: the instruction must be generated by the editing model for each change, not hard-coded. It is the merge model's only clue to intent when a marker is ambiguous, so a generic "apply this edit" throws information away.

Because it speaks the chat completions protocol, you can call it with the stock OpenAI SDK and a different base URL. Morph also ships an SDK with ready-made edit-file tools for the Anthropic, OpenAI and Vercel AI SDKs, if you would rather not write the tool definition yourself.

Speed is the product

Morph quotes V3 Fast at more than 10,500 tokens per second in its API documentation and live model list, roughly twice the figure it gives for V3 Large.

The reason speed matters so much here is that an apply model's output is the entire file. A 600-line file is several thousand tokens of output, and at a typical chat model's generation rate that is many seconds of the user staring at a spinner for an edit that has already been decided. At five figures per second the same merge is well under a second. Apply is also a natural fit for speculative decoding in general, because most of the output is a copy of the input; speculative decoding explained covers why that pushes the accepted-token rate up.

Treat the figure as an order of magnitude rather than a guarantee. It is a vendor number, and throughput on any hosted endpoint varies with load and with which provider is serving the request.

Price, context and the numbers that disagree

At the time of writing, OpenRouter lists V3 Fast at $0.80 per million input tokens and $1.20 per million output, which matches Morph's own model list. Note that the input side is not trivial: every apply call sends the full original file, so on large files input dominates the bill.

Context is where sources diverge. Morph's own model list shows a 262K window for V3 Fast on its API, while OpenRouter lists about 82K. If you route through an aggregator, the aggregator's limit is the one that applies to you. In practice, an apply call needs room for the file twice over — once in, once out — plus the update, so the usable file size is well under half the window.

Accuracy is quoted at about 96% for Fast and 98% for Large in Morph's documentation. Those figures come from Morph's own evaluation set, and you cannot reproduce them without it. What you can measure is your own merge failure rate, which is the number that actually matters.

When Fast is enough, and when it is not

Fast suits the shape of most edits in an ordinary agent loop: a function changed here, an import added there, a guard clause inserted. Local, unambiguous edits are where a smaller merge model has the least room to go wrong.

The cases that push toward Morph V3 Large are the ones where the lazy snippet leaves the most to interpretation:

• Edits spread across many distant regions of one file, with several elision markers.
• Repetitive code where a marker could plausibly match more than one location.
• Very large files, which Fast may not fit on some providers.
• Changes where a silent mis-merge is costly — generated migrations, configuration, anything without a test suite to catch it.

Morph's API documentation actually marks a third option, auto, as its recommended choice: it picks between the two per request. That is reasonable if you have no data, but unless you log the result it hides which model handled a failure, which makes debugging harder.

How to evaluate it on your own code

Do not judge an apply model by eye on a handful of edits. Pull fifty real edits from your agent's logs — the original file, the lazy snippet the editing model produced, and the file you eventually committed. Replay each through V3 Fast and diff its output against the committed version.

Count three outcomes: exact match, a whitespace-only difference, and a semantic mismatch. Then look at where the mismatches cluster. If they are all large files or multi-region edits, the answer is a size-based rule that sends those to Large, which is model routing in its simplest form. If they are spread evenly, the problem is probably the snippets your editing model writes, and no merge model will fix that.