ForgeLoopWhy ForgeLoop exists
The hard part is not generating a diff.
It is making a change you can explain, verify, review, and safely integrate. ForgeLoop is built around that responsibility.
Why the system around the agent matters
A generated change is only one part of software delivery. Someone still has to decide what work is allowed, coordinate dependent changes, run checks, interpret failures, and determine whether the result is ready to merge. ForgeLoop brings those responsibilities into an inspectable workflow.
- GitHub remains the place for issues, branches, and pull requests.
- Agents implement bounded tasks inside that workflow.
- ForgeLoop coordinates planning, execution, verification, repair, review, and delivery.
Built for your existing repositories
ForgeLoop is repository agnostic. You connect your own GitHub repository and keep its stack, history, conventions, and deployment process. Repository-specific harnesses and verification commands describe how work should be performed and checked.
- Useful for teams experimenting with issue-to-PR automation on reviewable changes.
- Useful for maintainers who want visibility into agent work and evidence before delivery.
- Each repository still needs appropriate tooling and checks; connecting it does not automatically make every task suitable for automation.
A browser control plane and a runner you operate
The website provides the operator view: repositories, runs, policies, evidence, and usage. Your enrolled runner executes repository work and uses locally configured provider credentials. This separation gives you a clear place to inspect delivery and a clear place to control execution.
- Start and pause work from the desktop runner.
- Choose provider settings and keep credentials on the runner.
- Inspect progress and estimated usage through the console.
Evidence is part of the product
ForgeLoop is built around results that can be inspected: verification output, acceptance coverage, artifacts, and the commit associated with delivery. Those records make it easier to understand why a change passed, why it failed, and where a person needs to intervene.
- A model’s explanation is useful context, but does not substitute for a passing check.
- Estimated costs depend on configured pricing and recorded usage.
- Passing repository checks does not prove a production deployment will succeed.
Where the project stands
Desktop previews are available for Windows, macOS, and Linux; the downloads page only lists assets from a complete published release. The expanded matrix covers Windows x64/ARM64, macOS Apple Silicon/Intel, and Linux x64/arm64 DEB, RPM, portable tar.gz, and native Arch packages. Previews are unsigned, and macOS packages are not notarized. Published downloads include version information and checksums.
- Use the current release notes and repository checklist to assess readiness for your environment.
- Begin with a small issue, explicit limits, and reviewable acceptance criteria.
- Report reproducible problems through support without including credentials or private source.
Ready for your first run?
Connect a repository, set up your runner, and start with a small change you can review.