You only need the frontier model for one single edit

It's hard to argue with the numbers, but starting with a (mostly true!) “research is the most expensive part” premise, this strikes me as an odd direction to go to optimize costs:

1. As others pointed out, we feed all the same research turns to a smaller model, so we pay the uncached price for all of them.

2. During research, the model typically reads more code than is relevant, to figure out what is relevant and what is not. If that's the expensive part, we keep paying for those turns with the most expensive model?

3. There is no quality comparison of the resulting code. Same plan != same code, and AI tokens during the initial implementation phase isn't the only cost attributable to the task.

I do the opposite:

1. Outsource research to a subagent, or several parallel subagents. Let them output the relevant code paths only. Using gpt-5.6-terra-high on Codex and sonnet on Claude. Merge results into a single per-task research file. This saves tokens and context window of the bigger model, and avoids re-researching after compactions and in subagents.

2. Use the smartest agent (Sol xhigh ultra / Fable max) for both planning and execution. Tell it to use the research file where possible.

3. Switch to dumber agents for verbose substeps, e.g. gpt-5.6-luna-medium / sonnet is enough to drive browser use.

Sadly, got no numbers to back this approach.

PS: Of course, different task complexities and codebase complexities demand different approaches. The most expensive part is actually the code review step, which they don't mention/have at all. We should come up with some sort of complexity grading, so that discussions like this can be contextualized.

Also "divide and conquer" is still applicable. Tired of waiting 10 minutes for the model to come up with a plan that ends up being wrong? Divide the problem into pieces and attack the pieces individually, worst case scenario the model spends 2 minutes and got some detail wrong, but way easier to correct the tiny stuff.

Once you've done with the pieces, do one "integrate them together" part, then you have a fully formed plan with less chance of wrong stuff in it. Yes, this requires a bit more interactivity than "prompt model then come back after making and drinking a coffee", but personally I prefer that.

I cannot imagine local models running on an igpu could get anything close to either a useful plan or execution of a plan. I've tested Qwen 3.5 27B locally and its solutions to coding problems are usually flawed and running in thinking mode is too slow and that's on a discrete GPU. How do you get anything useful done on a model that runs on an igpu?

I've been doing more or less this (from the post) for months:

> plan deeply, then capture the plan as a todo list, then start.

I do the plan deeply phase by writing a 50 line specification myself and then asking Claude to evaluate it, find what I missed, ask questions. I answer the question and we iterate until I know that we have what I had in mind to do.

Then I ask it to write the implementation plan, that I might end up reviewing because it always asks some more question. Finally it implements the steps.

If the planning was good the implementation is fast.

In many languages that’s the only way to express that since there is no “it”. It doesn’t mean speakers of such languages anthropofy everything and I think that’s the case here.