Most people try to save on AI coding by picking a cheaper model. That is the blunt instrument. A better move is to stop sending every kind of work to the same model in the first place.

A recent practitioner write-up describes a small local harness that uses a frontier model for exploration and planning, then hands routine execution to a cheaper model. The reported result was a 75% reduction in frontier-model usage while the author worked from two $20 plans. That is not a controlled benchmark, and it is not a promise that your bill will fall by the same amount. It is a useful design pattern because it gives you a place to measure the tradeoff instead of hoping a chat product routes well on its own.

A reported 75 percent reduction in frontier model usage after role based handoffs

Build the workspace boundary

Start with a directory that is deliberately boring. The point is to make the agent's working area obvious to you and to the model. A useful minimum looks like this:

harness/
|-- AGENTS.md
|-- skills/
|-- extensions/
|-- artifacts/
`-- work/
    `-- my-project/

Put shared instructions in AGENTS.md. Put reusable procedures in skills/. Keep generated files, screenshots, logs, and throwaway experiments under artifacts/. Keep the real repository in work/, then sync changes into it deliberately. This boundary matters more than the brand of terminal UI. If an agent can scatter state through your home directory, you cannot easily inspect what it changed or reproduce the next run.

The open source brayness harness takes this idea further by putting an agent's own state under .pi/agent/ and refusing to run when a stray ~/.pi appears. Its skills are shared with multiple clients through one source directory, with symlinks only where a client requires them. In practical terms, keep 1 source-of-truth skills directory and link clients into it. You do not need to copy that exact layout. You do need the rule behind it: one source of truth for instructions, one visible place for artifacts, and a clear line between harness state and project code.

Create the boundary before adding clever prompts. Then run one harmless task, such as asking the agent to list files and write a short report under artifacts/. If it writes outside the boundary, fix that problem before granting it more access.

Route work by task shape

The practical routing rule is simple. Use a cheaper model for work where the pattern is already known. Use a frontier model when the shape of the problem is still unclear or the cost of a wrong first decision is high.

Cheap-model candidates include maintenance edits, repetitive test additions, straightforward migrations, documentation updates, and one-file refactors with an existing example to copy. Frontier-model candidates include exploring an unfamiliar codebase, choosing a design for a feature with several moving parts, writing the first task in a new pattern, or reviewing a change where the failure would be expensive.

A handoff can be explicit instead of magical:

explore -> plan -> worker -> critic -> promoter

The explorer asks questions and identifies constraints. The planner turns the result into a task list or dependency graph. The worker implements one small item at a time. The critic checks the result against the request and looks for needless complexity. The promoter prepares the change for another human to review, including tests, notes, and any remaining uncertainty.

Do not send the entire conversation to every role by default. Save the plan and relevant evidence as files in the harness. Give the worker the smallest context that lets it complete its assigned node. This is where the savings come from: not just a cheaper model, but fewer repeated tokens and fewer vague restarts.

The source author says this role split dropped frontier usage by 75%. Treat that as a field report, not a benchmark. The Hacker News discussion also exposed the catch: some developers prefer one strong model because reloading context and handing off can cost more time and tokens than it saves. That objection is correct for tiny tasks. A four-stage harness is overhead. Use it when the task is long enough to benefit from a written plan, repeated subtasks, or a review checkpoint.

Make handoffs auditable

A model handoff should produce an artifact, not a mood. Require the planner to write a plan file. Require the worker to record which plan item it touched. Require the critic to point to evidence: a test command, a diff, a reproduced bug, or a clear reason a requested check could not run.

A minimal AGENTS.md can state the operating boundary like this:

- Work only inside the harness and the linked project directory.
- Put generated files and experiments under artifacts/.
- Read the plan before editing code.
- Run the narrowest relevant test after each task node.
- Never claim success without naming the command or file that proves it.

That last line is more valuable than a long personality prompt. It turns a pleasant sounding answer into a claim you can inspect. It also gives a cheap model a way to stop instead of improvising when the plan no longer matches the code.

Keep a tiny cost log for a week. Record the task type, model used, rough token count or subscription limit consumed, elapsed time, and whether a human had to redo the work. You are looking for the break-even point. If the handoff saves 30 percent of expensive context but adds 20 minutes of setup and review, it may still be a bad deal for a five-minute edit. If it prevents one failed large refactor, the same machinery can pay for itself.

A local harness is also a safer place to experiment with tools such as Docker, a web interface, filesystem access, or a browser driver. Give those capabilities to the harness, not automatically to every repository and every model. The source setup treats sandboxing and auditability as first-class concerns for exactly this reason: an agent that can reach more of your machine needs a smaller, more visible room to work in.

The rule I would actually use

Build the smallest harness that makes one recurring task easier. Start with the directory boundary, a shared AGENTS.md, an artifacts/ folder, and a written plan. Add role separation only when you can name the repeated failure it fixes. Add parallel execution only when the subtasks are independent and you have a verifier for the results.

The useful part of the 75% figure is not the number itself. It is the reminder that model choice is a workflow decision. A cheap model can be perfectly adequate after the hard ambiguity has been removed. A frontier model can be wasteful when it is repeatedly asked to rediscover the same pattern. Your harness should make that distinction visible, reversible, and easy to review.

If you already run parallel agents, read the local supervisor for parallel agents guide next. It covers the separate control problem that appears once one workspace becomes several workers.

Sources