Should the expensive model see every message, or only the step that uses a tool?

Only the step that uses a tool, and only with the original request sitting next to that step. The expensive model should not see every message. Chatter, status pings, and a cheap model’s running commentary are how the bill grows and how a rewritten task sneaks in. It should also not see the tool call alone. If you hide the user’s sentence and hand it the cheap model’s paraphrase, it will execute the paraphrase perfectly. The packet that is worth the frontier price is short: the original request, the tool name and arguments about to run, and the latest tool result if this is a retry.

Everything else can stay on the cheap model, or skip a model entirely and be a log line.

What “every message” actually costs

I ran a week with the frontier model on the whole transcript because I did not trust the split. The transcript was a coding agent: a request, a search, a file read, a mutter about the test name, another read, a shell call, a “looks good,” a follow-up from me that said “yes, run the billing tests.” Most of those turns did not need a strong model. They needed a tool runtime and a short memory of the path.

The invoice was the proof. The tokens were dominated by repeated file bodies and by the model restating the plan between calls. The one turn I would have paid for was the shell call that ran the tests, because a wrong command would have told me the suite passed when the billing package never ran. I had paid frontier rates to watch the model agree with itself.

Seeing every message also makes the strong model inherit the cheap model’s drift if you later insert a cheap model into the middle. The strong model is polite. It will treat the prior assistant turns as established. If those turns say the task is now “update the fallback URL,” the strong model will write that edit and feel consistent. Consistency with a bad middle turn is not accuracy.

The packet I send instead

When a tool is about to run, and the tool can write, delete, send, spend, or execute, the frontier model gets one packet:

• The user’s original sentence, unchanged, even if it is two weeks of chat old. I store it. I do not let the coordinator’s rewrite replace it.
• The tool name and the arguments the cheap model proposed.
• If this is a retry, the previous tool result, trimmed to the error or the diff, not the whole world.

I ask the frontier model for a yes, a corrected argument list, or a stop. I do not ask it to continue the conversation. It does not get the cheap model’s “I think we should” paragraph. That paragraph is how a fallback hostname becomes the task.

Reads are not in this packet by default. A search that returned three paths can stay cheap if the next step is another read. I promote the step when the arguments are about to change the disk or leave the machine, or when the cheap model already failed this call once. A second bad argument is more expensive than one frontier check. A first read of a file I can open myself is not.

The shell call that passed the wrong tests

This is the failure mode of “only the tool step” done carelessly. The user message was “run the billing tests.” A cheap model decided that meant npm test at the repo root. The root script runs the UI package, which was green. The frontier model saw only the proposed command, npm test, and the tool schema for the shell. The command was valid. The model approved it. The tool returned success. The billing tests never started.

The frontier model was not stupid. It was not shown the sentence it needed. “Is npm test a reasonable command?” is a different question from “does npm test fulfill ‘run the billing tests’ in this repo?” The second question needs the original request and, if you have it, one line from package.json about what the root script actually calls. It does not need the forty messages of us discussing the invoice layout.

I reran with the packet: original sentence, proposed command, and the root test script’s name. The frontier model rejected it and named the billing package script. That rejection was the entire value of the expensive call. The rest of the session stayed cheap.

What you should leave out on purpose

Leave out the cheap model’s plan. Plans are where the request gets edited into something the tools can do. If the frontier model reads the plan first, it will repair the plan instead of comparing the tool call to the user. I have seen it “improve” a bad URL edit into a cleaner bad URL edit, because the plan said the fallback string was the staging link.

Leave out earlier tool bodies that are not this call. Pasting three full files into the frontier model so it “has context” recreates the every-message bill and gives it more chances to latch onto a comment that looks like the key. If the argument is a patch, the packet includes the patch and the target hunk, not the file’s history of chatter.

Leave out your own “ok” and “continue” messages. They are not instructions. Fed to a strong model at the end of a long thread, they read as approval of whatever the last assistant said. I have had a frontier model treat “continue” as permission to apply a diff I had not looked at, because continue was the latest user turn and the original request had scrolled out of the window it was given. Pin the original. Do not let continue be the request.

Which tool steps are worth it

Not every tool is equal. I pay for the frontier model on shell, file write, send, calendar create, and anything that calls a paid API. I do not pay for it on a directory listing. The listing is either there or it isn’t, and a cheap model’s argument error on “list this folder” is obvious in the trace.

I also pay when the cheap model is retrying. The first write can be cheap if the path came straight from a search hit and the old string is the full line. The retry, after the tool said the string was not unique, goes to the frontier model with the error text. That is the step where small models narrow the string badly or widen it to the whole file. A strong model looking at one error is a better spend than a strong model watching the successful search that preceded it.

Browser steps sit in the middle. Navigating to a URL the user pasted does not need a frontier model. Clicking submit, or typing into a logged-in page, does. If I cannot classify the browser tool that finely, I treat the whole browser tool as expensive. I would rather over-check a click than discover the cheap model approved its own form fill.

How the cheap model is still useful

The cheap model proposes. It searches, it drafts arguments, it keeps the shortlist of paths. The frontier model is a gate on the proposal, not a second employee rewriting the session. If you let the frontier model take over the transcript after the gate, you are back to every message, just delayed by one cheap preamble.

Proposal quality still matters. A gate that rejects everything is a person doing the job with extra steps. I watch the reject rate. If the frontier model rewrites most write-calls, the cheap model is not ready to propose those calls, and I should stop letting it draft them. If the frontier model approves most of them and the approvals match the original sentence, the split is earning its keep.

I log three lines per gated call: the original sentence, the proposed arguments, and the frontier model’s yes, edit, or stop. I do not log the frontier model’s explanation into the cheap model’s next prompt. Explanations leak back in as fake context. The cheap model will quote them later as if they were tool results.

The rule on one card

One more cut is worth making. Do not send the frontier model the tool catalog. It already knows the call you are asking about. A catalog invites it to suggest a different tool, and then you are back in planning instead of gating one step. If the proposed tool is the wrong type — a root test script for a billing request — the right answer is stop, not a new design. You can pick the next tool with the cheap model, or yourself, after the stop.

The expensive model does not sit in the room. It sees the original request and the tool step that can change something or that already failed. It does not see the transcript, the cheap plan, or a continue that replaced the request. A tool step without the original sentence is how a valid command passes the wrong tests. Every message is how you pay a frontier model to reread a file the cheap model already opened.

If you cannot point at the tool call you are buying, you are not routing. You are still running one expensive chat, and the cheap model is a narrator you did not need.