u/liviux

I’ve been building LoopTroop, an open-source local GUI that runs on top of OpenCode.

The reason is pretty specific: OpenCode is already a strong execution layer, but for bigger coding tickets I kept wanting more structure around it. Not a smarter single prompt. More like a full ticket lifecycle around the agent.

https://i.redd.it/djjw22sirlah1.gif

LoopTroop treats an AI coding task as a pipeline:

1. Start with a ticket.
2. Run an interview to clarify missing requirements.
3. Generate a PRD.
4. Break the work into small implementation units called beads.
5. Execute each bead through OpenCode.
6. Retry failed beads with a fresh session and a compact failure note.
7. Keep the human in the loop before important transitions and final review.

The main thing I’m trying to solve is context rot. Long agent sessions collect old logs, failed attempts, stale assumptions, and half-fixed code. After a while the model is no longer working from clean intent.

LoopTroop stores the useful parts as durable artifacts instead:

• ticket
• interview answers
• PRD
• bead plan
• acceptance criteria
• validation commands
• retry notes
• logs and final diffs

For planning, it can use an LLM Council. Multiple configured models draft independently, vote on the strongest result, then the winning draft is refined with useful ideas from the others. I use this for the interview, PRD, and bead planning phases.

https://preview.redd.it/zrffzjtjrlah1.jpg?width=1918&format=pjpg&auto=webp&s=9c27e356be2fbe37d472264d085b86d9426126fc

For execution, OpenCode stays the coding engine. LoopTroop is the orchestration layer around it: project/ticket state, model configuration, phase-specific context, logs, retries, GUI visibility, and review gates.

https://preview.redd.it/0tl4ffnkrlah1.jpg?width=1200&format=pjpg&auto=webp&s=4141b47b5c31572d22e0d5f5dd20c22731c1a118

It is intentionally slower than opening a coding assistant and asking for a patch. For small changes, that is still the better path. This is for the annoying multi-file work where the plan, context boundaries, retries, and review artifacts matter.

GitHub: https://github.com/looptroop-ai/LoopTroop
Full 16-minute demo: https://www.youtube.com/watch?v=LYiYkooc_iY

Any feedback is more than welcome. If you try it with OpenCode and it works, breaks, or feels wrong for your workflow, give me a sign. Happy to talk about it.

I’ve been working on an open-source app called LoopTroop. It came from a pretty simple frustration: AI coding tools are useful, but once a task gets bigger than a small edit, the chat starts turning into a junk drawer.

Old logs, failed attempts, stale assumptions, repeated code, partial fixes. The model keeps seeing all of it, and after a while it starts solving the wrong problem.

LoopTroop is my attempt to structure that workflow instead of just writing bigger prompts.

https://i.redd.it/7xtxawu2rlah1.gif

The app is local-first and runs as a GUI. You add a repo, create a ticket, then follow the work through a Kanban-style flow: interview, PRD, bead planning, implementation, checks, review, and PR output.

The main idea is context engineering over chat history.

Instead of one giant transcript, LoopTroop keeps durable artifacts outside the model:

• the original ticket
• interview answers
• a PRD
• small implementation units called beads
• acceptance criteria
• validation commands
• compact failure notes when something breaks

https://preview.redd.it/qu8qsl15rlah1.jpg?width=1919&format=pjpg&auto=webp&s=57ae8f166d3bcb59caa080a50936007134f90a63

For planning, it can use an LLM Council. Multiple models draft independently, compare the plans, vote, and then the best draft gets refined with useful parts from the others. It is slower, but the plans tend to catch more edge cases than a single pass.

For implementation, the work is split into beads. Each bead is small enough that the agent has a focused job instead of “go build this whole feature and somehow keep everything straight.”

If a bead fails or times out, LoopTroop uses a Ralph-style retry loop: save a short note about what went wrong, reset the polluted attempt where possible, and retry with fresh context plus the useful failure note.

https://preview.redd.it/q4oy7th6rlah1.jpg?width=1918&format=pjpg&auto=webp&s=a7aaefab3670f4cce3f4e740f2fdd9e01a125167

It is not meant to replace quick AI coding tools. For tiny edits, a normal coding assistant is faster. This is more for the annoying multi-file work where planning, retries, logs, diffs, and human review matter.

GitHub: https://github.com/looptroop-ai/LoopTroop
Full 16-minute demo: https://www.youtube.com/watch?v=LYiYkooc_iY

Any feedback is more than welcome. And if you try it and it works, breaks, or feels wrong for your workflow, give me a sign. Happy to talk about it.

https://preview.redd.it/d9i2vmk7rlah1.jpg?width=1200&format=pjpg&auto=webp&s=360918e63ef067fbe94f58b2ed2717fd709576bd

I’ve been building LoopTroop, an open-source local GUI for running longer AI coding tickets through a structured agent workflow.

The short version: I wanted something between “ask a coding agent in one huge chat” and “build a whole custom agent stack from scratch.”

https://i.redd.it/t9lcmldw97ah1.gif

The workflow is built around context engineering.

Instead of keeping the whole task inside one growing conversation, LoopTroop turns the work into durable artifacts:

• a short interview to clarify the ticket
• a PRD/spec
• small implementation units called beads
• execution logs
• retry notes
• review artifacts

The idea is to give the model the right context for the current step, without dragging every failed attempt and noisy log forward forever.

https://preview.redd.it/3h0ev22x97ah1.jpg?width=1200&format=pjpg&auto=webp&s=60481bf78705abd43776e38872ed40d332567ea1

Planning can run through an LLM Council. Multiple models draft independently, vote on the strongest plan, then merge useful parts into a final version before execution starts.

This is slower than one prompt, but it gives me something I can inspect before any code is written.

https://preview.redd.it/2lj9z0wx97ah1.jpg?width=1915&format=pjpg&auto=webp&s=27d923c62eb796c1d021d1e7ab1ec02e881b11e2

The retry system uses Ralph Loops.

When a bead fails or gets stuck, the system writes down what went wrong, drops the stale attempt, and starts fresh with that failure note. The next run carries the lesson, not the whole messy session.

https://preview.redd.it/23lza9vy97ah1.jpg?width=1919&format=pjpg&auto=webp&s=54dcaa709ec3dd04401b054da59d693f0e4e79bb

I built it mostly because long-running coding agents kept breaking in boring ways: losing the plan, retrying inside polluted context, or producing a diff that was hard to explain after the fact.

LoopTroop is still early alpha, but it’s MIT licensed and local-first.

GitHub: https://github.com/looptroop-ai/LoopTroop
16-minute demo: https://youtu.be/LYiYkooc_iY

Any feedback is more than welcome. And if you try it and it works, breaks, or feels confusing anywhere, give me a sign. Happy to talk through it.

I’ve been building LoopTroop, an open-source local GUI for running AI coding agents on bigger repo tasks.

This is the flow I wanted: write a ticket, let agents plan it, split it into small pieces, run the pieces in isolated git worktrees, and review the result before anything touches the main branch.

https://i.redd.it/qx684ukp87ah1.gif

The full path looks like this:

1. create a ticket for a local repo
2. answer a short interview so the agent has the missing context
3. generate a PRD/spec
4. split the work into small “beads”
5. run each bead through OpenCode in its own worktree
6. retry failed beads with fresh context and a failure note
7. review the logs, artifacts, diffs, and final output

https://preview.redd.it/yea0hjkr87ah1.jpg?width=1919&format=pjpg&auto=webp&s=b57d3aed8f811972fd1efbb4fe0cd811f6e34d33

The part that made the biggest difference was not making the agent “smarter.” It was keeping the workflow outside the chat.

A failed coding-agent run usually leaves behind a messy session: logs, wrong assumptions, partial fixes, and explanations that made sense ten minutes ago but now just pollute the next attempt. LoopTroop tries to keep the useful bit from the failure, then starts the retry clean.

https://preview.redd.it/j1ywmhbs87ah1.jpg?width=1200&format=pjpg&auto=webp&s=bac4f8e4605b7f552c6545c420ab8d6346e2c8de

There is also an LLM Council step for planning. Multiple models can draft a plan, vote, and merge the best parts before execution starts. It is slower than one prompt, but the output is easier to inspect.

I’m still treating this as early alpha. It is local-first and MIT licensed, but local does not mean safe by default. The execution agent can run shell commands, so I recommend using a VM or disposable dev environment.

GitHub: https://github.com/looptroop-ai/LoopTroop
16-minute demo: https://youtu.be/LYiYkooc_iY

I’ve been building LoopTroop, an open-source local GUI for running larger AI coding tickets without turning the whole thing into one long, fragile agent chat.

https://i.redd.it/dlurlk2737ah1.gif

The basic problem I kept running into: coding agents are useful on small tasks, but longer repo-level work gets messy fast. The plan drifts, retries happen inside already-polluted context, and after a while you’re debugging the agent’s state instead of the code.

LoopTroop is my attempt at putting more structure around that.

The workflow is:

1. attach a local git repo
2. create a ticket
3. answer a planning interview
4. generate a PRD/spec
5. split the work into small “beads”
6. run each bead in an isolated git worktree through OpenCode
7. retry failed/stuck beads with fresh context instead of continuing the same chat
8. review the result before anything is handed off

https://preview.redd.it/10xywhp837ah1.jpg?width=1919&format=pjpg&auto=webp&s=67de1b2b9b95d113b56e4d95722731e5252066ce

The part I’m most interested in is the planning layer. Instead of asking one model to produce the plan, LoopTroop can run an LLM Council: multiple models draft independently, vote on the strongest draft, then refine it and check coverage before execution starts.

https://preview.redd.it/fl0duvea37ah1.jpg?width=1200&format=pjpg&auto=webp&s=126c9281ffea99ecb52fb575bc6eec4613baa031

For execution, each bead is intentionally small. It has a purpose, acceptance criteria, target files, and validation commands. If a bead gets stuck, LoopTroop writes down what failed, resets the worktree, drops the stale session, and retries with that note carried forward.

https://preview.redd.it/njyrq2ob37ah1.jpg?width=1918&format=pjpg&auto=webp&s=e3d9c1e0222d53bd74107b48122c28a6584a537f

This is slower than just throwing a giant prompt into a coding agent. That’s deliberate. I’m optimizing for inspectability and recovery, not speed. I still review the artifacts, diffs, logs, and final output before trusting anything (if you want).

A few things I learned while building it:

• Keeping workflow state outside the model matters more than I expected.
• Retrying in the same conversation often makes failures worse.
• Git worktrees are useful for repo isolation, but they are not a security sandbox.
• Human approval gates make the tool feel less “magical,” but much easier to trust.
• The hard part is not only getting the model to write code. It’s keeping the whole ticket lifecycle understandable.

It’s early alpha, MIT licensed, and local-first. It runs around OpenCode, so model/provider setup comes from whatever you configure there.

GitHub: https://github.com/looptroop-ai/LoopTroop
16-minute demo: https://youtu.be/LYiYkooc_iY

I’m curious how other people here are handling long-running agent work. Are you mostly using one persistent session, explicit handoff artifacts, separate workers, worktrees, something else?

I built LoopTroop, an MIT-licensed local GUI for running longer AI coding tickets in a way you can inspect.

The reason I am sharing it here is that open-source AI needs more than open models. For real coding work, I kept running into the same problem: the model chat becomes the project state. Once that giant transcript gets messy, retries get worse and it is hard to review what actually happened.

LoopTroop keeps the workflow state outside the chat. A ticket goes through an interview, a PRD, small implementation units called beads, OpenCode execution in isolated git worktrees, and a final review step. The app stores logs and artifacts so you can see the plan, the attempts, the errors, the diffs, and the handoff.

https://i.redd.it/4by26jjwxe9h1.gif

A few important caveats:

- The app is free and MIT-licensed.

- It runs locally, but model privacy and cost depend on the providers you configure in OpenCode.

- For unattended agent work, use a VM, container, cloud dev machine, or another sandbox. Git worktrees help keep repo changes inspectable, but they are not a host security boundary.

https://preview.redd.it/nl81i15uxe9h1.png?width=1122&format=png&auto=webp&s=e71df3c318dca4bbdb6e18af5c63932ebbb012ef

The main pieces are:

- LLM Council planning for interview, PRD, and bead planning.

- Small bead-level execution instead of one giant prompt.

- Fresh retry sessions that keep a compact failure note but drop the polluted chat history.

- Human review gates before the final PR handoff.

https://preview.redd.it/xha5o09vxe9h1.jpg?width=1911&format=pjpg&auto=webp&s=c1f69bf9938ebd14d63c581feeddb28b218e3d96

https://preview.redd.it/w71na5rvxe9h1.jpg?width=1919&format=pjpg&auto=webp&s=1b5d73283b1e865e431d029d449e65405445fc93

GitHub:

https://github.com/looptroop-ai/LoopTroop

Full 16-minute demo:

https://www.youtube.com/watch?v=LYiYkooc_iY

I would love feedback from people who follow open-source AI tooling: does this kind of local orchestration layer feel useful, or would you rather keep the state in simpler scripts and plain files?

I built LoopTroop, an MIT-licensed local GUI for running longer AI coding tickets in a way you can inspect.

The reason I am sharing it here is that open-source AI needs more than open models. For real coding work, I kept running into the same problem: the model chat becomes the project state. Once that giant transcript gets messy, retries get worse and it is hard to review what actually happened.

LoopTroop keeps the workflow state outside the chat. A ticket goes through an interview, a PRD, small implementation units called beads, OpenCode execution in isolated git worktrees, and a final review step. The app stores logs and artifacts so you can see the plan, the attempts, the errors, the diffs, and the handoff.

https://i.redd.it/ia7pqbawwe9h1.gif

A few important caveats:

- The app is free and MIT-licensed.

- It runs locally, but model privacy and cost depend on the providers you configure in OpenCode.

- For unattended agent work, use a VM, container, cloud dev machine, or another sandbox. Git worktrees help keep repo changes inspectable, but they are not a host security boundary.

https://preview.redd.it/iad1s8vxwe9h1.jpg?width=1200&format=pjpg&auto=webp&s=32cecb25108dee3f03aae4f7ce4cba0b21b2c169

The main pieces are:

- LLM Council planning for interview, PRD, and bead planning.

- Small bead-level execution instead of one giant prompt.

- Fresh retry sessions that keep a compact failure note but drop the polluted chat history.

- Human review gates before the final PR handoff.

GitHub:

https://github.com/looptroop-ai/LoopTroop

Full 16-minute demo:

https://www.youtube.com/watch?v=LYiYkooc_iY

I would love feedback from people who follow open-source AI tooling: does this kind of local orchestration layer feel useful, or would you rather keep the state in simpler scripts and plain files?

I’m building LoopTroop, an MIT-licensed local GUI for running longer AI coding tickets against your own Git repos.

It is not a new harness. It is an orchestration layer around OpenCode: planning, review gates, worktrees, retries, logs, and final handoff.

https://i.redd.it/cuivq1tkse9h1.gif

The basic flow:

- you attach a local repo and create a ticket

- an LLM Council drafts interview questions, PRD, and implementation beads

- the council votes/refines before moving to the next step

- each bead runs as a small implementation unit in a git worktree

- if a bead gets stuck, LoopTroop resets and retries with fresh context plus a short failure note

- you review artifacts, logs, commits, and final diffs before accepting anything

https://preview.redd.it/hio8rcprse9h1.png?width=1122&format=png&auto=webp&s=d07a1ada96ef3492b0182f7fe28f00e7da7a69ad

A few honest caveats:

- it is early alpha

- it can be slow by design, especially on larger tickets

- worktrees isolate repo work, not the host machine

- because the execution agent can run shell commands, I strongly recommend a VM or sandbox

https://preview.redd.it/ixnhnegvse9h1.jpg?width=1913&format=pjpg&auto=webp&s=2ad7868e1f7f93630111b7340f37cc8ebda1ec7b

https://preview.redd.it/wpb10ayvse9h1.jpg?width=1919&format=pjpg&auto=webp&s=6eb15bf457052fecdcfce38aa1a5962c632b1398

https://preview.redd.it/r0u9wpewse9h1.jpg?width=1911&format=pjpg&auto=webp&s=f260517cf23c1f4af3b93bd096b742962c413420

I’m mainly looking for feedback, any feedback. thanks

GitHub:

https://github.com/looptroop-ai/LoopTroop

16-minute walkthrough/demo:

https://www.youtube.com/watch?v=LYiYkooc_iY

I built LoopTroop, an MIT-licensed local GUI app for running bigger AI coding tickets from a local repo to a reviewable PR.

https://i.redd.it/hfjevlqspe9h1.gif

The repo is here:

https://github.com/looptroop-ai/LoopTroop

It is not a hosted service. You run the app locally, attach a Git repo from disk, write a ticket, then review the planning and execution artifacts as the work moves through the pipeline.

The basic flow is:

- interview questions before writing the spec

- PRD generation

- small implementation units called beads

- execution through OpenCode in isolated git worktrees

- fresh-context retries when a bead fails

- final verification and PR review

https://preview.redd.it/x9roahdvpe9h1.jpg?width=1200&format=pjpg&auto=webp&s=8cae9c80356ea78e2565ed35975072a8d93c2077

The part I cared about most was making the agent work inspectable. I do not want a long chat where the plan, failures, test output, and final diff all blur together. LoopTroop stores artifacts, logs, bead status, execution attempts, and final changes so you can inspect what happened before trusting it.

Important caveat because this is AI tooling: the app runs locally, but model privacy depends on how you configure OpenCode. If you use cloud model providers, code may leave your machine. If you need stricter privacy, use a local/private model setup and run the whole thing inside a VM or sandbox. The execution agent can run shell commands, so I would not run this loose on a personal machine.

There is also a 16-minute walkthrough/demo here:

https://www.youtube.com/watch?v=LYiYkooc_iY

I’d like feedback from the FOSS side especially on the local execution model, the safety caveats, and whether the repo/setup feels clear enough for people who want to inspect the code before running it.

I’m the maker of LoopTroop, an MIT open-source local app for running larger AI coding tickets from a GUI instead of one long chat.

https://i.redd.it/j65di3vnme9h1.gif

The short version: you attach a local Git repo, write a ticket, answer an interview, review the generated PRD/bead plan, then LoopTroop runs the work through OpenCode in isolated git worktrees. The goal is not instant edits. It is slower, more inspectable agent work where you can see the plan, logs, artifacts, retries, diffs, and final PR output.

The part I think may fit this sub: the app itself runs locally, keeps state/artifacts/logs in your environment, and lets you use whatever model providers you have configured through OpenCode. If you need strict local/private execution, configure it that way and run the whole thing inside a VM or sandbox. The execution agent can run any kind of commands.

Architecture in plain terms:

- LLM council for planning: multiple models draft/vote/refine interview questions, PRDs, and bead plans

- Beads: small implementation units with target files, acceptance criteria, and validation steps

- Ralph-style retries: failed/stuck beads restart with fresh context plus a compact failure note

- Git worktrees: implementation happens away from your active checkout

- Human gates: you approve the interview, PRD, bead plan, setup, and final result

https://preview.redd.it/6n3wdscvme9h1.jpg?width=1200&format=pjpg&auto=webp&s=2a829c2d1c836cf821af69986e5f801851128adf

A few screenshots from the flow:

https://preview.redd.it/om56xd1xme9h1.jpg?width=1915&format=pjpg&auto=webp&s=b961c943cf5a63f274947d4e93ae62253fa65d1b

https://preview.redd.it/n0n3irixme9h1.jpg?width=1919&format=pjpg&auto=webp&s=d85b21f641d8e522c3b732326fbc1ad3c424321e

https://preview.redd.it/3k77chnyme9h1.jpg?width=1911&format=pjpg&auto=webp&s=0dcb7c24acb3c4d6a89b3ed101649d41ee7a3665

Repo:

https://github.com/looptroop-ai/LoopTroop

16-minute walkthrough/demo:

https://www.youtube.com/watch?v=LYiYkooc_iY

I’d especially like feedback from people already running local/self-hosted AI stacks:

- would you run something like this inside a VM, container, or separate dev box?

- does the “slow, inspectable, recoverable” workflow make sense, or is it too much structure?

I owe a lot to GitHub Copilot CLI.

I mostly created LoopTroop using Copilot CLI back when I could run it without thinking too much about limits, and I’m honestly forever grateful for that period. It helped me build way more than I could have built with other tools.

But after using it heavily, I started noticing the same pattern on bigger tasks: long runs got messy, retries carried too much old context, logs piled up, and sometimes the agent would keep “fixing” things while drifting away from the original goal.

So I built LoopTroop around that pain.

https://i.redd.it/4cu93whkm89h1.gif

It is not a Copilot replacement. It also does not use Copilot CLI as the execution layer right now (it will support in a future release multiple harnesses). It currently uses OpenCode for implementation. But the whole idea came from using Copilot-style CLI agent workflows a lot and wanting more structure around them.

The flow is roughly:

• start with a ticket
• ask clarifying questions before writing a spec
• generate a PRD
• split the work into small implementation units - beads
• run each unit in an isolated git worktree
• retry failed units with fresh context plus a compact failure note
• keep logs, artifacts, diffs, and final PR output visible

https://preview.redd.it/wi6b0mpsm89h1.jpg?width=1200&format=pjpg&auto=webp&s=a8d08b1742280e1290650da5769913aa9cfeb484

The main thing I wanted was a way to avoid one huge agent session becoming the source of truth. LoopTroop stores durable artifacts outside the model and rebuilds smaller context for each phase.

For planning, it can use multiple models as an LLM Council. They draft, vote, refine, and check coverage before execution starts.

For implementation, each small unit runs separately, so if one gets stuck, the next try can start fresh instead of dragging the entire broken chat history forward.

It is early alpha, local, open source, and very much built by someone who spent a lot of time pushing Copilot CLI hard and learning where I wanted more guardrails.

GitHub: https://github.com/looptroop-ai/LoopTroop

Full 16-minute demo: https://youtu.be/LYiYkooc_iY

I’ve used Cursor a lot while building LoopTroop, and honestly it shaped a big part of how I think about AI coding now.

Cursor is great when I’m moving fast, editing locally, asking questions, or doing focused changes. The pain started showing up on bigger tickets: long sessions, lots of logs, half-fixed retries, context getting messy, and the agent slowly losing the original goal.

So I built LoopTroop around that problem.

https://i.redd.it/x8s6zv1uk89h1.gif

It’s not a Cursor replacement. I still use Cursor directly for smaller work. LoopTroop is more of a local orchestration layer for the kind of ticket where I want structure before the coding agent starts touching files.

The rough flow is:

• scan the repo
• ask an interview round so the spec is not based on guesses
• generate a PRD
• split the work into small “beads”
• run each bead in an isolated git worktree
• retry failed beads with fresh context plus a compact failure note
• show logs, artifacts, diffs, and final PR output for review

https://preview.redd.it/qbex47ivk89h1.jpg?width=1200&format=pjpg&auto=webp&s=5dc0f800240dbf136aa3cf84b3dc85aa5f1f9449

The part I cared about most is avoiding the “one huge AI chat that slowly rots” pattern. Instead of keeping everything in one growing conversation, LoopTroop stores durable artifacts and rebuilds smaller context for each phase.

For planning, it uses an LLM Council: multiple models draft, vote, refine, and check coverage before execution starts.

https://preview.redd.it/x63hla1xk89h1.jpg?width=1911&format=pjpg&auto=webp&s=c4a249d13a2b4d5fa02524eace6c41fa2074ffcd

For implementation, it currently uses OpenCode as the execution layer, so this is not a Cursor plugin. The idea came from using Cursor a lot and wanting a separate harness for longer, messier tickets where planning, retries, worktrees, and review matter more than speed.

https://preview.redd.it/s3jjlpuzk89h1.jpg?width=1915&format=pjpg&auto=webp&s=87511d2f51456eaf0c1c3fcf82bfc1e0f5f2dfb7

It is early alpha, local, open source, and definitely not magic. Also, because it runs agentic coding locally with command execution, I recommend using a VM or sandboxed dev environment.

GitHub: https://github.com/looptroop-ai/LoopTroop

Full 16-minute demo: https://youtu.be/LYiYkooc_iY

Curious how people here handle bigger Cursor tasks today. Do you manually split work into smaller prompts, use rules/MCP, restart sessions often, or just keep one agent thread going until it works?

Hey r/opencodeCLI,

I’m the maker of LoopTroop. It’s a local, open-source GUI that uses OpenCode as the execution engine, but adds a more structured workflow around it.

The problem I kept hitting: OpenCode is great for direct agent work, but on bigger tickets the session can slowly turn into a messy pile of logs, partial fixes, and old decisions. After a few failed attempts, continuing the same chat often makes things worse.

https://i.redd.it/287pvbk4h79h1.gif

So LoopTroop takes the slower route:

• start from a local repo and a ticket
• ask clarifying questions before writing the spec
• let multiple configured models draft, vote on, and refine the PRD / implementation plan
• split the work into small “beads” with target files, acceptance criteria, and validation steps
• run each bead in an isolated git worktree through OpenCode
• if a bead fails or times out, reset the worktree and start a fresh OpenCode session with only the bead + a short failure note
• stop at human approval points before execution and before the final PR

https://preview.redd.it/d2spdep9h79h1.jpg?width=1200&format=pjpg&auto=webp&s=f59f5c5e2d1e70312424ecd63fbcc8febb9a19ce

The main idea is not “replace OpenCode.” It is more like: keep OpenCode as the coding layer, but give it a local harness for planning, state, retries, logs, and review.

Any feed-back is more than welcome

models are picked from providers in OpenCode

Execution dashboard (logs are SSE from OpenCode)

GitHub: https://github.com/looptroop-ai/LoopTroop
Full 16-min demo: https://www.youtube.com/watch?v=LYiYkooc_iY

Body
Hey, I’m building LoopTroop, a local open-source coding-agent orchestrator. I don’t want this to be a link drop, though. The part I think fits this sub is the context pattern behind it.

The problem I kept running into: long AI coding sessions slowly turn into a messy pile of old assumptions, logs, failed patches, partial fixes, and stale decisions. Then every retry inherits that mess. The model is technically getting “more context,” but the useful signal is getting worse.

So I started structuring the workflow differently:

1. Durable artifacts outside the model The ticket turns into interview answers, then a PRD, then small implementation units called beads. Those artifacts live outside the chat and become the source of truth.
2. Bounded context per phase Each phase only gets the context it needs. Planning does not inherit execution logs. A bead does not inherit the whole ticket history. A retry does not inherit the full failed session.
3. Small execution units Each bead has a clear objective, target files, acceptance criteria, dependencies, and test commands. The agent is not asked to solve the whole feature in one giant pass.
4. Fresh retries instead of polluted retries If a bead fails or times out, the system writes a compact failure note, resets the worktree, and retries in a fresh session with just the bead spec plus that note.
5. Human gates I still review the interview, PRD, bead plan, execution setup, and final diff. The goal is not silent autopilot. It is a more inspectable path from ticket to PR.

some views in the app

This is slower than a normal coding chat. Sometimes the planning phase is annoyingly slow. But for multi-file work, it has been much easier to debug because I can see what the agent knew, what artifact it was following, and where the context got narrowed.

The project is here if anyone wants to inspect the implementation:
https://github.com/looptroop-ai/LoopTroop

I’d love feedback from people working on context systems:

• What do you keep as durable repo context versus temporary session context?
• Do you summarize old agent sessions, retrieve from artifacts, or just reset and carry a short failure note?
• Where does this kind of structure become useful, and where does it become too much process?

Salut r/programare,

Sunt din București și în ultimele 5-6 luni am lucrat la un proiect împreună cu partenerul meu pe care în sfârșit o să îl arăt și aici. Nu e o postare de lansare, e mai mult un jurnal de construcție plus câteva lecții, că poate ajută pe cineva care se chinuie cu aceleași probleme.

Spun de la început că eu sunt cel care l-a făcut, ca să fie clar.

De la ce am plecat

Foloseam tool-uri de tip Lovable, Repplit, Codex, Claude Code și mă loveam mereu de aceeași treabă: modelul pornește bine, dar după o conversație lungă începe să uite ce a stabilit la început, se contrazice și o ia razna. În engleză îi zice "context rot". Pe scurt, cu cât îi dai mai mult istoric, cu atât devine mai prost.

Așa că am încercat altceva.

Ce am construit

Un program local GUI care duce un task de la descriere până la un PR verificat. Ideea de bază e că nu folosesc un singur model într-o conversație uriașă, ci sparg totul în pași mici, fiecare pas cu strictul necesar de context și fără să păstrez istoricul între pași (partea de context engineering).

Câteva lucruri concrete pe care le-am învățat pe drum:

• Mai multe modele care votează bat un singur model genial. La faza de planificare pune mai multe modele să scrie fiecare câte o variantă, apoi votează anonim între ele, iar varianta câștigătoare împrumută ideile bune de la cele care au pierdut. Sună complicat, dar diferența în calitatea planului e reală. (partea de LLM Council)
• Planificarea trebuie să fie serioasă. La mine faza de plan (interviu cu întrebări, PRD, apoi spargere în pași atomici cu criterii de test - beads) poate dura și peste o oră. Pare mult, dar aici se câștigă sau se pierde tot. Dacă planul e bun, execuția e aproape plictisitoare.
• Cand un model se blochează la executarea propriu zisă, cel mai bine e să ștergi tot și să o iei de la capăt. Dacă un pas nu se termină într-un timp dat, programul scrie o notă cu ce a mers prost, curăță complet contextul și worktree și reia pasul de la zero, dar cu nota aceea în plus. E contraintuitiv, dar a curăța și a reîncerca curat merge mult mai bine decât să insiști pe un context deja murdar. (partea de Ralph Loop)
• Izolarea contează. Fiecare task rulează în propriul git worktree, deci nu se calcă în picioare între ele. În spate folosește OpenCode ca harness.

Unde e

E open-source complet moka. Dacă vreți să vă uitați:

• GitHub: https://github.com/looptroop-ai/LoopTroop
• Site: https://www.looptroop.ovh/
• Demo (video, 16 min): youtu.be/LYiYkooc_iY

Întrebare pentru voi

Voi cum vă descurcați cu tool-urile de AI pe proiecte mari, unde un fișier depinde de zece altele? Ați simțit și voi că se prostesc după conversații lungi, sau e doar la mine? Orice alt feed-back este foarte bine venit.

Și dacă e cineva din București interesat, mă gândesc să fac un demo live la un meetup local (prin zona Bucharest, meetup-uri de AI).

https://preview.redd.it/9cxj6oh1zt8h1.png?width=1122&format=png&auto=webp&s=44064dcf2c5e8dec74b8bbf0d7d06a5cf129034e

Mulțumesc că ați citit până aici.