TL;DR: **my current workflow is basically: good/expensive model plans + reviews, cheap/open models build**.

And I'm increasingly convinced that, with a good enough spec, the builder model matters a lot less than it used to.

For my latest project I used Fable 5.1 to create a \`spec.json\`, following roughly Anthropic's long-running-agent approach:

[https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)

The important part: small, verifiable tasks. Not "build authentication", but small problems with context, constraints and explicit verification.

Then I leave that original planner window open and start building with cheaper models.

I've been using/testing **Laguna S 2.1**, Qwen, Kimi K2.7 Code, GLM-5.3, Muse Spark 1.3, plus Haiku, GPT-5.4 nano, GPT-5.6 Luna, etc.

Poolside's models in particular are worth looking at:

[https://poolside.ai/models](https://poolside.ai/models)

What surprised me: once the spec is good, the quality starts converging a lot.

I can have different models implement tasks, then bring the result back to the stronger planner/reviewer. Most of the time I'm getting something around 7–8 (rated by fable 5.1), regardless of which decent coding model did the implementation.

Not saying the models are equally smart. They aren't.

But for:

\> "Here is one small task. Here is the architecture. Here are the constraints. Here is exactly how you prove it works."

...the gap gets much smaller.

The biggest difference I'm noticing now is often speed, not whether the model can actually do the job.

My loop is basically:

\`\`\`text  
strong model  
↓  
plan / spec.json  
↓  
cheap/open model  
↓  
5–10 tasks  
↓  
strong model reviews  
↓  
fix / split / add / reorder tasks  
↓  
repeat

\`\`\`

Don't wait until all 50/100 tasks are done before reviewing. After the first 5–10, go back to the planner. Let it inspect what actually happened and modify the plan.

That feedback loop matters a lot.

I also run a dumb Ralph Wiggum-style loop around this. One task, fresh agent, implement, test, commit, next:

[https://github.com/fcavalcantirj/sticks3-ai-usage/blob/main/ralph-continuous.sh](https://github.com/fcavalcantirj/sticks3-ai-usage/blob/main/ralph-continuous.sh)

It can swap between Codex, Claude Code, OpenCode, Kimi-style workflows, etc. If one provider is limited, use another.

When I need multiple agents talking to each other, or when the task is complex and weaker models strugling to deliver, I've also used free A2A rooms on Solvr: (planer as mentor, weaker as executor, both align on room and get the job done).

[https://solvr.dev/rooms](https://solvr.dev/rooms)

But that's optional. \`spec.json\` + Git + a progress file already gets surprisingly far.

The project I'm using for this experiment:

[https://github.com/fcavalcantirj/sticks3-ai-usage](https://github.com/fcavalcantirj/sticks3-ai-usage)

And the actual spec:

[https://github.com/fcavalcantirj/sticks3-ai-usage/blob/main/spec.json](https://github.com/fcavalcantirj/sticks3-ai-usage/blob/main/spec.json)

The nice part is that this project itself tracks all my AI quotas and tells me which provider I should use for the next 4 hours. So the agents built the thing I now use to decide which agents to run. :)

My takeaway after doing this for a while:

Spend expensive tokens on thinking.  
Spend cheap/free tokens on execution.  
Keep tasks small.   
Review early.   
Keep the project context in files, not only inside one huge chat window.   
Open-weight models aren't just "interesting alternatives" anymore.   
For a lot of normal implementation work, they're already good enough.   
  
And that makes building stuff ridiculously cheap.  
ps; visual made by [https://v0.dev/](https://v0.dev/) \- so it wasnt free..but, almost!

Open-source coding models are getting really good — and dev can be almost free now