ForgeLoopBuilt around the work
More than an agent with a terminal.
A delivery system needs to know what work is allowed, what passed, what failed, and which exact commit is ready for review.
GitHub intake you control
Turn an issue into eligible work using the repository rules you choose. Connect selected repositories through the GitHub App, then configure the intake label and optional assignment gate. Choose any GitHub assignee or one exact login. Safe issue drafts prefill the title and acceptance-criteria body without attaching activation metadata; add the missing label or assignment only when ready.
- Keep issues and pull requests in your existing GitHub workflow.
- Require assignment when you want an explicit handoff before processing.
- Paste an issue number or matching GitHub issue URL into the read-only intake diagnostic; it checks rules without editing or starting work.
- Keep your runner stopped until eligible issues are intentionally allowed to start provider work.
Plans with clear task boundaries
ForgeLoop turns a specification into a task graph with dependencies, acceptance criteria, and owned paths. Agents work on defined units of the change, while the orchestration tracks what must finish before another task can proceed.
- Independent work can proceed when dependencies permit.
- Leases track which runner has claimed a task.
- Isolated Git worktrees separate checkout changes during execution.
- Acceptance criteria keep the plan connected to the behavior the issue requested.
Reusable repository harnesses
A harness describes how to work with a repository and verify its changes. Connect your existing stack and configure the commands and gates it needs, rather than moving application code into ForgeLoop or adopting a special example project.
- Reuse harness definitions across repositories with similar requirements.
- Choose verification commands appropriate to the repository, such as tests and builds.
- Organization policies define execution limits and approval requirements.
- Runner-local MCP processes make configured tools available where repository work executes.
Runners on your infrastructure
The browser coordinates delivery and shows its progress. An enrolled runner executes repository commands on a computer you operate, using locally configured provider credentials. The desktop app handles pairing, provider settings, readiness checks, and starting or pausing work.
- The downloads page lists the platforms included in the latest complete release. The expanded matrix covers Windows x64/ARM64, macOS Apple Silicon/Intel, and Linux x64/arm64.
- Linux package formats include DEB, RPM, portable tar.gz, and a native Arch pacman package; AppImage is no longer used for new releases.
- Java is bundled; Git and Docker are prerequisites.
- Compare the desktop and browser fingerprints when approving enrollment.
- Check saved credentials locally without making a model request. Starting work can incur provider charges.
Verification with inspectable evidence
Configured gates evaluate the change and produce results tied to the commit under review. Inspect command output, acceptance coverage, and checksummed artifacts to understand what was tested and where verification fell short.
- Use test and build output to evaluate results alongside the proposed diff.
- Review screenshot evidence when a configured browser gate produces it.
- Choose checks that exercise both expected behavior and failure paths.
- Passing repository checks supports review; deployment validation remains part of your application release process.
Bounded repair and review
A failed verification step can send failure context into a repair loop. ForgeLoop tracks the attempts within configured limits so the next action is informed by the failed check. When limits are exhausted, the run needs attention rather than an unsupported success claim.
- Inspect failing gates and repair attempts in run details.
- Set task and budget limits before starting eligible work.
- Independent review adds another stage before guarded delivery.
- Use the recorded failure context to decide whether to revise the issue, adjust a command, or intervene.
Pull requests and optional auto-merge
Delivery brings the proposed change back to your repository as a pull request, with review and verification evidence supporting the decision. Human approval and optional auto-merge follow the configured policy and checks for the expected commit.
- Keep human approval where your workflow requires it.
- Explicitly enable auto-merge when you want eligible changes merged after its checks pass.
- A new commit must satisfy delivery checks; an earlier passing result does not authorize a changed branch.
- Continue using your normal deployment and release process after merge.
Run visibility and estimated spending
Follow runs from the console, inspect their tasks and events, and open artifacts when you need detail. Usage & costs brings recorded provider usage into daily spending views and model breakdowns, helping you understand where work is consuming tokens.
- Filter usage by repository and the last 7, 30, or 90 UTC calendar days.
- Inspect token usage, estimated costs, and pricing coverage. Missing prices appear as unavailable, not as zero cost.
- The runner looks up public base model prices automatically; you can override account-specific rates. Totals are estimates, not a provider invoice or account balance.
- Archive finished runs to clear the queue while retaining their contribution to usage totals.
Ready for your first run?
Connect a repository, set up your runner, and start with a small change you can review.