Getting the most out of a low-cost coding model

Here is something we have learned running an affordable model all day: how you set up the work matters as much as which model you picked. Feed the same low-cost model a sloppy request and a careful one and you get noticeably different results. A handful of habits account for most of that gap, and none of them are complicated.

The biggest one is to hand it the scope and not just the symptom. Any model guesses when the ask is vague, and a cheaper one guesses worse. So rather than pointing at one error, describe the change you want and the rules around it: which files are in play, what done looks like, how to treat the edge cases you already know about. When the prompt reads like a tiny spec, the diff comes back looking like real work instead of the agent's best guess at what you meant.

It also helps to let the agent read its fill before it touches anything. Understanding your code is the slow, input-heavy step, and on a cheap model that reading barely costs anything, so there is no reason to rush it. Point the agent at the relevant files, have it list the call sites or reproduce the bug, and only then let it edit. A long read and a short, precise write is the shape these models are best at.

And keep the steps short and checked. Where a cheaper model tends to wander is a long unsupervised stretch that rewrites twenty files before anything is verified. Work in batches with a build or a test run between them, and a wrong turn shows up immediately rather than three batches later wearing a disguise. Those checks are not busywork; they are what keeps a cheap model on course over a long task.

And keep yourself in the loop. Read the diffs, approve them, and take the genuinely ambiguous calls yourself instead of leaving the agent to guess. Pier is built to work this way, which is most of why a cheap default holds up on real work. You can watch the habits play out across the use cases, each a terminal session run on exactly these rails.

Put those together and a low-cost model carries the great majority of everyday coding for a fraction of the price. A brutal whole-repo problem might still earn a bigger model on a given day, and that is fine, as long as it is a call you make on purpose and not a tax you pay every day by default. The numbers behind it are on the pricing and cost per task pages.