I've been heads-down on this for months and only now feel ready to talk about it properly.

LoopTroop is a local, open-source GUI orchestrator I built. It uses OpenCode (right now, more backends in the future) to create new apps or add features, fix bugs, and improve existing codebases. It leans heavily on context engineering, Ralph loops, beads, LLM councils, and git worktrees.

Think Lovable or Replit, but with the opposite philosophy: it cares more about getting things right than shipping as fast as possible.

The Problem That Started Everything

Early this year I kept hitting the same wall. I'd try to add meaningful features to my own apps and the normal IDE route just became overwhelming on anything complex. Tools like Replit didn't deliver what I needed either — they were even worse.

Around the same time Ralph loops were getting popular. I thought: What if I combine Ralph loops with a proper LLM council and a full development lifecycle? Maybe I could finally solve the real problems I was facing instead of fighting the tools.

I told myself it would take a month. Maybe six weeks max.

Boy, was I wrong.

(I also have a day job, kids, a house — you know, normal life.)

So me and my partner just started working on it whenever we could.

120 Hours of Planning (The Most Important Part)

The first 120 hours were pure planning. No code at all.

We looked at every similar project we could find and asked: what did they do well? Where did they fall short? I basically threw the initial idea at almost every model available back then and kept asking "What's missing? What's dumb? What should we push to later?"

Some of the Chinese open models actually gave the best suggestions. I'd take their feedback, update the plan, switch to another model, ask again, and repeat.

Once the core plan felt solid, I started digging into the actual tech stack behind it, this time leaning more on frontier models, then bouncing the new version back to the others for another round of criticism.

That whole back-and-forth took the full 120 hours.

some parts of the app

Actually Building It (And Why One-Shotting Was Impossible)

Then we started implementing the plan.

I used a bunch of different harnesses — hammering GitHub CLI (insanely useful at the time because one request could just keep running for hours), Claude Code, Codex, Droid, and a couple others. I'd keep the best output from each run, steal good UI ideas from the rest, and then go back to the strongest harness (mostly Claude Code with Opus back then) to fold everything together.

Another month+ passed before it actually worked. This thing is genuinely complex. There was never any chance of one-shotting it.

After the core started working, I spent the next couple of months adding features and refining until it finally felt like the thing I had originally pictured in my head. Only then did I feel comfortable starting to talk about it publicly.

Because LoopTroop itself runs an LLM council, I needed access to lots of different models at the same time for testing and building. Here's what I leaned on:

• Multiple Codex Pro subscriptions + Codex-lb (the open-source load balancer so I wasn't constantly logging in and out)
• VS Code + Copilot + Copilot CLI (mainly for Claude Opus/Sonnet)
• OpenCode Go subscription for smaller tasks
• Antigravity (with Google Pro) for UI work and occasional Opus. Now that Flash 3.5 is out I use it constantly; it's fast and good enough for most non-complex work
• Kilo and OpenRouter to pull in free models for the council

For big architectural decisions I would spin up GPT-5.5 (or 5.4) Pro and cross-check the plan across a ton of other models: MS Copilot, Z.ai GLM, Qwen, Minimax, Grok, Gemini, Deepseek, Kimi, Xiaomi, and sometimes even Mistral or Ernie. Same technique I used in my planning phase (described before) — moving the plan between different model families to catch edge cases and collect good ideas. I ended up with an architecture.md file with 10000+ lines that got so changed when I made the app actually work.

When I just wanted to know "What's the current best way people are doing X right now?", I usually started with Grok or Gemini.

Out of the open models, I'd currently recommend Kimi and GLM (on top of the big three).

Anything that got too complicated went straight onto the roadmap (it lives on GitHub and in the docs). That's how I actually managed to launch.

What I'd Recommend Now (After Going Through It)

If you're building something genuinely complex with AI right now, here's what I'd tell you:

1. Spend way more time on initial planning than you think you need. Run your plan through as many different models as possible. Different model families catch completely different things. Push the big scary features onto a roadmap and get as close to a real MVP as you can. Tens of hours, hundreds even if you want something serious — not a to-do app.
2. After planning, use the strongest model you can afford for the first real iteration. I'd honestly just use LoopTroop for this now, with whatever the current top model is as the main implementer.
3. Then settle into the real forever coding loop: Complex work? Use LoopTroop. Seriously, it's built for exactly this. Small stuff or quick fixes? Use whatever fits your budget (full Claude/Codex/Cursor plan, OpenCode Go, or free models via OpenRouter). Just keep repeating this forever.
4. Market and build at the same time. Don't wait until it's perfect. Keep shipping updates and talking about it in parallel with the development work.

See It In Action

Here's a full walkthrough of LoopTroop doing its thing:

Watch the full demo (16 minutes, after 6:50 the demo) on YouTube:

That's the story so far. It took way longer than I expected, cost more in subscriptions than I want to admit out loud, and taught me a ridiculous amount about how different models actually think.

If you're building something complicated with AI agents or orchestrators right now, I'd genuinely love to hear how you're approaching it.

• Repository: github.com/looptroop-ai/LoopTroop
• Docs: looptroop.ovh/docs