[bensyverson]

Yes, and I'm arguing that the post is over-simplifying. As I mention, for small plans, it's probably easier to have the big model just do it. But for large, multi-session plans, it's cheaper to let smaller models execute the bulk of the work.

[markust]

Perhaps, there's a small change that might work better here - if we use a different agent (by creating custom agents) for plan and implementation, then the switch to the implementation agent wouldn't end up re-reading a lot as the new agent would have fresh empty context. I implemented this[1] from one of the posters on HN and I think it'd work well with this problem too. Would be great if you could point out if my understanding is wrong.

[1]: https://www.stavros.io/posts/how-i-write-software-with-llms/

[bensyverson]

The issue with this is just how much context it consumes. Generating the plan could easily get me to 30% of a 1M context window—the point at which I normally clear. Most of that context fill is not necessary for execution, and the model degrades as context fills. So starting from 30% (or passing a fresh agent all of that context) is not ideal. But maybe I'm misunderstanding what you're proposing?

[markust]

Yes, sorry let me explain a bit more. The idea is that we have custom agents each having a model version of their own. So, if we have a planning agent that uses Opus and a worker agent that uses Sonnet, then the planning agent writes the plan and hands it over to the worker agent. This way, the handover here is not going to retain the context.

When the worker agent picks it up, it'd have a new context and only the todo list from the plan, so it shouldn't be reading all the files again.

[bensyverson]

Ah, got it. Yeah, that's what I do using my tool, Jobs. When the plan is big enough, it's definitely cheaper & more efficient than having the "big" agent do everything.