What Replit is, in its own words
Replit’s homepage asks “What will you build?” and answers it with “Turn ideas into apps in minutes — no coding needed.” Its Agent is sold as “Describe it. Publish it.” — it “writes production-ready code, evolves it, and stays out of your way.” The platform ships “Authentication, Database, Hosting, and Monitoring” with “zero setup”, advertises “100+ integrations” to “OpenAI, Stripe, Google Workspace, and more in minutes”, and routes models itself: “the best model for every task”, claiming equal output quality “at 65% lower average cost.” Enterprise adds “SSO/SAML, SOC 2, and admin controls”, “Single-tenant environments” and “Static outbound IPs.” A customer quote credits “parallel task execution” — submitting tasks simultaneously “with full visibility before anything merges.” (Source: replit.com .)
We are stating that fully because the out-of-date version of this comparison — “Replit is a browser IDE for prototypes” — is false today. Replit publishes production applications with authentication, a database, hosting and monitoring behind them, and runs tasks in parallel while you watch.
The real difference is what you are describing, and what you are left holding when the run ends.
The difference in one table
| Replit | Forge | |
|---|---|---|
| What you describe | The app you want | The team you would have hired, and the process it follows |
| What an agent is | A builder that writes the app and publishes it | A named role with a job description — PM, architect, developer, tester, reviewer, researcher, writer |
| Who checks the work | You, looking at the app it published | A management agent on every handoff: pass, send back with enrichment instructions, or escalate to a person |
| Primary artifact | A running app on Replit’s infrastructure | A run branch in your own repository — spec, brief and each role’s handoff as commits, Co-authored-by the persona — and then a pull request |
| A rejected step | Prompt again | A new commit; the earlier attempt stays in history and git diff shows what changed |
| Scope | Applications | Software delivery (most mature), plus research, content and operations on the same engine |
| Where it runs | Replit’s platform | Managed SaaS, or self-hosted runners on your own hardware |
| Which model runs it | Replit routes for you | A provider pool you control — priority weights, failover, self-hosted models, any OpenAI-compatible endpoint |
Where Forge is different
Different roles, not one builder working faster. A Forge delivery run is five roles: a product manager who surfaces ambiguity instead of inventing an answer, an architect, a developer, a tester and a reviewer. Between each pair sits a management agent that reads the handoff and decides whether it is good enough to pass on. Weak work does not travel down the chain to quietly become someone else’s problem. See Multi-Agent Pipeline .
The reasoning is committed, and it is committed to your remote. Every run gets a branch — forge/workflow/{workflowId}/run/{runId} — holding the spec, the original brief, and each persona’s structured and freeform handoff as its own commit. You can read the argument behind a decision, diff a second attempt against the first, or intervene mid-run by committing a corrected handoff yourself. It lands in the repository you already have. See Git-Backed Audit
.
It is not an app builder. The same engine, the same validation loop and the same audit trail run a research team that verifies its own sources, a content team that publishes on a schedule, or an ops rotation that sweeps your infrastructure. Software delivery is where it is most mature — because it is how Forge is built — but it is one archetype. See Workflow Engine and the use cases .
Your hardware and your keys. Self-hosted runners keep execution on your machines, and the routing gateway sends inference to a provider pool you control, with priority weights and automatic failover — including self-hosted models and any OpenAI-compatible endpoint. See Bring Your Own Hardware and Multi-Provider Routing .
The one number a single agent cannot report
An app builder can report that the app is live. It cannot report how often the work was sent back before it got there, because there is nobody in the loop whose job is to send it back. Here is what happens when the reviewer is part of the system.
| Twelve weeks of Forge building Forge | |
|---|---|
| Runs dispatched | 322 |
| Handoffs judged by a management agent | 1216 |
| Sent back to their author for rework | 56 |
| Escalated to a human | 24 |
| Runs where the supervisor stopped at least one handoff | 51 |
| Runs that completed | 215 |
| Runs that failed, escalated or were cancelled | 103 |
| Median wall-clock, dispatch to finished run | 39 minutes |
| Median handoffs per completed run | 5 |
| Pull requests merged, across 7 repositories | 202 |
Where these came from. One workflow — Main Forge SDLC, the one that builds Forge — every run it made in twelve consecutive weeks, counted from the control plane’s own records. Not a sample, not a pilot, not a customer case study we cannot show you.
Forge stopped its own work 80 times. 56 handoffs went back to their author with specific rework instructions; 24 went to a person. One run in six was interrupted by its own supervisor before any human looked at it. That is precisely the review a single-agent tool leaves on your desk — here it is priced at one model call per edge, and counted.
It merged 202 pull requests across 7 repositories in the same period — roughly 17 a week, into the platform you are reading about, with a human performing every merge. Organisation-wide, agent-authored work merged at 773 of 875 opened. Forge is not a demo running beside the product; it is how the product gets built, and these are its commits.
A finished run takes about 39 minutes and 5 handoffs. Median dispatch-to-done — and inside those 39 minutes sit the reviews that stopped 80 pieces of work from reaching the next role in the state they were first written in.
80 of those were work that looked finished to the agent that wrote it — and in a build-and-publish loop, work that looks finished is work that ships. The difference here is that something read it first, and wrote down what it decided.
Ask us to walk you through the runs themselves — the branch, the handoff commits, the verdicts that sent work back, and the ones that went to a person. Every other number on this site belongs to a named run and says so: 18 sources gathered, 11 verified by direct retrieval, 4 corroborated and 2 shipped marked unverifiable, on the research use-case page .
Sources
- replit.com — hero copy, Agent description, platform and enterprise claims, model routing, plan limits.
- Forge claims on this page link to the corresponding feature pages , which describe the mechanism in detail.