Let the Expensive Model Write the Instructions
I build dcaudiotours.com, a set of self-guided walking tours for Washington DC. Thirteen themed tours, eight neighborhood walks, each one a…
Let the Expensive Model Write the Instructions
I build dcaudiotours.com, a set of self-guided walking tours for Washington DC. Thirteen themed tours, eight neighborhood walks, each one a sequence of stops, and every stop is a short script that has to read cleanly through a text-to-speech voice and then come out again in eight languages. That is a lot of stop scripts, times eight.
I gave the first tour to Fable 5 and asked it for something other than finished scripts. I wanted the method behind them: the length that sounds right at walking pace, the SSML markup that survives Google’s neural voices, the DC place names that come out mangled without a pronunciation override, the rules for carrying a finished English stop into the other seven languages. Fable worked through one full tour, hit those problems on its own, and wrote a two-page instruction file. Opus generated the rest of the stops from that file.
The pattern comes from manufacturing, where one expensive expert works out how a job should be done, writes the procedure, and leaves the line to run it without standing over it. With language models the expert is the frontier tier and the procedure is a text file. You pay top-tier prices once, while the method is still unknown, then execution-tier prices on every run after. The file is the deliverable; the finished stop scripts are simply what a correct file produces.
Why the split works
Tiers cost different amounts because they are good at different things, and the difference sits in a narrow band of the work. The frontier tier earns its price on ambiguity: an unfamiliar API, documentation that contradicts itself, a task whose right approach only shows up after the second or third failed attempt. On well-specified work the cheaper tier keeps pace, and across a few hundred runs the price gap turns into real money.
Most real jobs mix the two. My tour scripts are mostly repetition, one stop after another in the same shape, but the shape itself took work to pin down. Getting the SSML right, finding the pronunciation overrides, deciding how literal each translation should stay: that part rewards the expensive model. Producing stop number forty in an established shape does not. Send the whole thing to one tier and you either overpay for the repetition or watch the cheaper model rediscover the SSML problem on stops three, six, and nine, burning retries that cost more than you saved.
The split pulls the two apart. You hand the frontier model a job that is not the task in front of you and ask it for a document that turns the task into something routine.
What the instruction file has to contain
A useful instruction file reads like a runbook from someone who already made the mistakes. Here is an outline of what Fable produced for the tour scripts, with the reasoning behind each part.
Objective, stated narrowly. “Write a narration script for one tour stop, 90 to 120 words, second person, present tense. Do not add any historical claim that is not in the source notes.” The narrowness keeps the executing model from making a call the file could have made for it.
The chosen approach, with the rejected ones named. “Mark pauses with <break time='400ms'/>, not ellipses; the neural voice ignores ellipses. Skip <emphasis>; it destabilizes the Spanish and Japanese voices. Escape ampersands or the whole request fails." Naming the dead ends costs three sentences and stops the cheaper model from walking into them on your budget.
Failure signatures and their responses. “If a stop about Dupont Circle comes back read as two flat syllables, the voice missed the name; wrap it in a <sub alias> tag with the spoken form. If the audio ends a beat early, a break tag swallowed the final sentence." This is the section that separates an instruction file from a summary. Both of those lines came from Fable running the first tour and hearing the audio break. Opus inherited the fixes without ever meeting the breakage.
Verification the executor can run. A short check that renders each script to audio and flags any file whose duration falls outside the expected range, which catches swallowed sentences before they ship. The executing model runs it after every batch.
Escalation boundaries. “If a stop needs a factual claim that is not in the source notes, stop and flag it rather than inventing one. If a place name has no pronunciation entry yet, flag it instead of guessing.” The cheaper model needs standing permission to stop and say something is wrong. Left to fill the gap on its own it will, and that guesswork is the one thing you were trying not to pay for.
How to run the research phase
The prompt should ask for the file, not the task. Mine reads close to this: research and test a way to do X, then write an instruction file a weaker model can follow to do X on its own, and include the failure modes you ran into and how to spot them.
Then make it test for real. A frontier model writing the file from memory gives you something plausible. Have it produce three actual stops and listen to them first, and the file it writes afterward holds up. Plausible and working look identical on the page, and the only way to tell them apart is to make the model follow its own instructions once before it commits them to the file.
Budget one real run into the research phase for this reason. The instruction file for the tours cost me one fully worked tour plus the research tokens. Everything after that ran on the cheaper tier.
How to think about it as a reader
Treat the first phase as a compilation step. Source runs slowly through an interpreter until you compile it once, after which it runs fast until the source changes and you recompile. Instruction files behave the same way. When I add a language or change the script length, I go back to Fable for a revision instead of asking the execution tier to muscle through it.
Two questions decide whether the pattern earns its keep on a given task.
Volume comes first. The research phase costs more than a single plain execution, sometimes several times more, so under about ten runs you are better off doing the task on whatever tier handles it. The file only pays back by being reused.
Stability comes second. Drifting inputs wear an instruction file down the way weather wears down a trail sign. If every run turns up a new edge case, the escalation section keeps growing until the cheaper model stops to flag something on nearly every stop, and you have rebuilt the expensive workflow with extra handoffs. The pattern wants work where the hard thinking sits up front and what follows really does repeat.
A third thing took me longer to notice. The instruction file turns into an asset with its own lifecycle. Mine sit in a repo now, versioned, each with a header noting which model wrote it and when. When Anthropic ships a stronger frontier model, I have a queue of files worth regenerating, since a sharper process engineer writes a tighter procedure. Execution stays cheap while the procedures keep getting better, and I only pay the expert now and then.
Skill files in Claude Code are this idea already formalized, and anyone who has hand-written a SKILL.md knows the shape of the document. The only thing I am changing is who writes it. A frontier model with a sandbox and permission to fail a few times will produce one, and it will list failure signatures I would not have thought to include, down to the ones it found only by breaking the tour audio itself. I stopped writing them by hand for that reason.
By Joshua McDonald on July 7, 2026.
Exported from Medium on August 26, 2026.
Reader discussion