Why Forge Changed Direction
Forge did not flip from “stable product” to “experiment” in a single day. Research was part of the February plan; June changed which trade-off came first, and the Gradio 4 and FLUX releases made that choice visible.
The goal stayed. The compatibility contract changed.
Forge began as a research-friendly layer over the familiar Stable Diffusion WebUI, with speed and memory management as immediate user benefits. In June 2024, upstream progress reduced the reason to preserve a near-upstream path, while Forge’s more invasive systems remained expensive to integrate.
The team chose to use Forge for those harder experiments. That raised update and extension risk. The July Gradio 4 rewrite and August FLUX work were the concrete result—not evidence that the repository had been cancelled.
This page answers the first. The dated project-status evidence answers the second.
What caused each phase—and what users actually felt.
Select a phase. The map keeps four things separate: the trigger, the shipped change, the user consequence, and the limit of the evidence.
The original bargain
The team wanted a familiar Stable Diffusion WebUI surface for research while improving speed, memory use and development ergonomics—especially for SDXL.
Forge opened as a separate repository on top of Stable Diffusion WebUI. The Development Plan said it did not intend to compete with A1111 and described conditions under which it could return to the upstream ecosystem as an extension.
Early users could retain a familiar tab-and-form workflow while testing Forge resource management and integrated research work.
The February plan was a statement of intent and test criteria. It was not a permanent compatibility contract or a promise that every A1111 extension would behave identically.
Memory became the product identity
Large SDXL generations exposed the practical value of controlled offloading, tiled VAE work and lower VRAM use.
Forge 0.0.16 documented NeverOOM controls and performance flags. The maintainer also documented that faster options could raise crash, black-image or OOM risk on some devices.
Forge became known less as a cosmetic WebUI fork and more as a way to make constrained-GPU workflows possible.
The published demonstrations came from named test hardware and settings. They do not establish a universal speed or maximum-resolution result.
The compatibility bargain changed
The maintainer said upstream WebUI had improved several performance bottlenecks, while Forge features such as its UNet patcher and modern memory management were costly to fit into the existing upstream ecosystem.
The announcement recommended that many users—especially production users—consider upstream WebUI and said Forge would mainly test costly experimental features. It warned that the planned Gradio 4 work was likely to break extensions and told users to back up.
Updating stopped being a routine “get fixes” action. Users had to choose between a known-good environment and the experimental line.
This was a warning about planned change. It did not itself change code on 8 June, and it did not announce repository deletion.
The warning was narrowed
Users interpreted the June announcement as abandonment or immediate breakage.
The maintainer clarified that there had been no code change between 8 and 27 June, denied that the repository would be eliminated, and said the extension warning mainly concerned Gradio-version compatibility. A previous-version download route followed in July.
Users gained an official rollback line and a clearer distinction between the logical patching API and UI extensions coupled to Gradio.
“Not eliminated” is not a promise of continuous maintenance. The previous build is a historical fallback, not automatically the right build for newer models.
The planned break became shipped code
Forge needed a newer UI foundation for richer browser-side interaction and its experimental interface work.
The Gradio 4 announcement introduced Forge Canvas with zoom, pressure-aware drawing, mask display and clipboard-oriented editing. The maintainer’s dated test said roughly 70% of tested extensions still worked and that many failures might need small Gradio-call changes.
Image editing improved, but some tabs disappeared or failed until extensions were updated, replaced or removed. Compatibility had to be tested extension by extension.
The 70% figure describes one maintainer test in July 2024. It is not a current compatibility rate and does not identify every tested extension or environment.
New model demands reshaped the UI
FLUX models were larger and could require separate diffusion, VAE and text-encoder files. The older single-checkpoint assumptions were no longer enough.
Forge documented BitsAndBytes NF4, GPU Weights and swap controls, then added a VAE/text-encoder interface and native paths for full FLUX and GGUF combinations.
Users with limited VRAM gained multiple loading routes, but also had to understand quantization, offload trade-offs and companion-file placement.
Later FLUX and fork features must not be projected back onto every 2024 build. Each claim needs the original Forge commit and model path it was tested against.
Integration replaced part of the old extension model
After the rewrite, users needed to know which older extensions still belonged in Forge and which jobs were now integrated or had temporary alternatives.
An official temporary extension replacement list documented the new compatibility landscape. NEWS later recorded a Flux sampler, a contributed SD3.5 branch and plans for Flux ControlNet and Gradio 5.
The correct question became “is this job integrated, replaced or still extension-dependent?” rather than “does every A1111 extension install?”
A branch or roadmap entry is not proof that work reached main. The inspected sources do not verify completion of the Gradio 5 plan.
Activity became dated, while the family split
Original Forge continued receiving model and workflow fixes, while downstream maintainers addressed different compatibility and continuation needs.
The inspected main history includes 2025 changes for LoRAs, GGUF BF16, Chroma, FLUX sampling, fp8 scaled, soft inpainting and SD Upscale. The latest inspected main commit remains dfdcbab from 26 June 2025. reForge, Forge Classic and later Forge Neo developed under different owners or branches.
“Forge” no longer identifies one interchangeable download. Users must resolve owner, repository, branch and commit before following a guide or moving a workflow.
No official abandonment statement was found. Silence does not prove future intent, and downstream activity cannot be credited to original Forge.
Announcement, release and commit are different events.
A plan describes intent. An announcement changes expectations. A release or commit changes code. Reading those as one event is how both “Forge died in June” and “nothing changed” became plausible but wrong summaries.
Inspect main historyRepository created
GitHub repository metadata
VERIFIEDRelease page tagged latest published
Release record; current assets were uploaded later
VERIFIEDDevelopment Plan and backend clarification published
Maintainer announcements
VERIFIEDNeverOOM controls documented
Maintainer announcement
VERIFIEDExperimental-repository warning published
Maintainer announcement; no same-day code change implied
VERIFIEDShutdown interpretation rejected
Maintainer update in the same announcement
VERIFIEDPrevious build route, Gradio 4 and Canvas arrive
Release and maintainer announcements
VERIFIEDFLUX/NF4, GPU Weights, split encoders and GGUF documented
Maintainer technical guides
VERIFIEDTemporary extension replacement list published
Maintainer announcement
VERIFIEDSampler, SD3.5 branch and future plans recorded
NEWS.md; plans remain plans
STALE SNAPSHOTFive latest inspected main commits land
Named main-branch commit history
STALE SNAPSHOTNo main commit newer than dfdcbab found
Fresh GitHub API check
STALE SNAPSHOTSix shortcuts the evidence does not support.
History becomes useful when it prevents a bad operational decision. These are the most common leaps between a true event and an unsupported conclusion.
| Claim | Verdict | Evidence-based reading |
|---|---|---|
| “Forge was abandoned in June 2024.” | Rejected | The 27 June clarification explicitly denied elimination, and substantial Gradio 4/FLUX work shipped afterward. Current maintenance is a separate, dated question. |
| “Nothing really changed; it was only wording.” | Rejected | The Gradio 4 rewrite, Canvas, extension compatibility change and FLUX loading architecture were material shipped changes. |
| “Forge stopped being based on A1111.” | Too broad | Forge retained a familiar WebUI lineage, but its backend, integrated features and Gradio-dependent extension surface diverged. Identify the exact subsystem. |
| “Every extension broke after Gradio 4.” | Rejected | The maintainer reported partial compatibility, while community issues document real failures. Compatibility was mixed and extension-specific. |
| “The forks are newer official Forge versions.” | Rejected | reForge, Classic and Neo are downstream projects with separate owners or branches. They are historical responses and continuations, not original releases. |
| “The 2024 release date means no code changed in 2025.” | Rejected | Release pages and main-branch commits are separate evidence streams. The inspected main branch contains 2025 commits. |
One lineage split into different maintenance promises.
The 2024 compatibility disruption created real demand for different balances: preserve the older Forge behavior, keep syncing upstream, or continue toward newer models. Community maintainers built downstream projects around those jobs.
That explains the names. It does not merge their evidence. A feature added by reForge, Classic or Neo remains a feature of that project until original Forge independently proves it.
Identify each Forge repositoryOriginal Forge
lllyasviel / stable-diffusion-webui-forge / mainThe only product whose history this page attributes to lllyasviel.
reForge
Panchovix repository; separate maintenance and branches.
Forge Classic
Haoming02 repository; older-line continuation.
Forge Neo
neo branch in the Classic repository; newer continuation.
Turn the timeline into the next safe action.
Do not update, roll back or migrate merely because one date looks newer. Start from the job that is failing or missing.
My old Forge still works
Keep the working environment pinnedRecord remote, branch, commit, Python/Torch, launch arguments and extensions before testing any change.
An update removed tabs or broke the UI
Treat it as an extension/Gradio regressionStart clean, verify the core UI, then return extensions one at a time or use the documented rollback route.
I need FLUX or split encoders
Use guidance matched to the chosen commitDo not apply old pre-rewrite folder screenshots to a newer FLUX build. Verify model, encoder and VAE paths together.
A guide says “use Forge”
Resolve the repository identity firstCheck the GitHub owner, repository, branch and commit. A screenshot or folder name cannot distinguish original Forge from a fork.
I need a newer model only a fork lists
Test the fork as a separate productInstall beside the working original tree and do not import the fork’s support claims into original Forge documentation.
I am deciding whether Forge is maintained
Use the current status snapshotHistory explains how the project arrived here; current commit, release and maintainer evidence answer the maintenance question.
Forge history, without the folklore.
Answers refer to original lllyasviel/stable-diffusion-webui-forge unless a downstream project is named explicitly.
Why did Stable Diffusion WebUI Forge change direction in 2024?
The maintainer said upstream WebUI had resolved several earlier performance bottlenecks, while some Forge systems were costly to integrate into that ecosystem. Forge therefore prioritized experimental work such as Gradio 4 and newer memory-management research. This changed the compatibility trade-off, not the original goals of easier development, resource optimization and experimentation.
Was Forge abandoned on 8 June 2024?
No abandonment or shutdown was announced. The June post recommended that many production users consider upstream WebUI and warned of disruptive changes. On 27 June, the maintainer explicitly said the repository was not being eliminated. Gradio 4 and FLUX work shipped afterward.
Why did Forge recommend going back to AUTOMATIC1111?
The June announcement said upstream had improved performance and described Forge’s next work as experimental and likely to disrupt extensions. The recommendation was aimed especially at users who needed a production-oriented, A1111-compatible daily environment.
What changed between old Forge and the Gradio 4 version?
The July 2024 line moved to Gradio 4 and introduced Forge Canvas. That provided richer image editing but changed the UI framework used by extensions. The later FLUX phase also added low-bit, swap, GPU Weights and separate VAE/text-encoder workflows.
Why did extensions stop working after a Forge update?
Many extensions depended on A1111-era Gradio calls or UI assumptions. The maintainer identified the Gradio-version boundary as the main compatibility risk. Some extensions continued working, some required small changes, and others needed replacement or removal. There was no universal compatibility result.
Did all A1111 extensions break in Forge?
No. The July announcement reported that about 70% of the extensions in one maintainer test still worked. That dated estimate is not a guarantee for any particular extension, Forge commit or operating environment.
When did Forge add FLUX support?
The major official FLUX/BitsAndBytes guide was published on 11 August 2024. A 13 August guide documented full FLUX and GGUF loading with separate VAE, CLIP and T5 selections. Later commits changed FLUX behavior further, so the exact commit still matters.
Why does newer Forge have separate VAE and text encoder controls?
Modern model layouts such as FLUX can separate the diffusion model, VAE, CLIP and T5 files. The older single-checkpoint-oriented VAE interface was not sufficient, so Forge extended it while keeping the surrounding WebUI familiar.
Did Forge switch to ComfyUI as its backend?
The original maintainer published a dedicated February 2024 clarification stating that Forge was not using ComfyUI as a backend. Shared concepts or adapted code do not make the two applications the same backend.
Why were reForge and Forge Classic created?
They are downstream community projects that appeared while users wanted different combinations of older-line compatibility, upstream changes and continued development. Their existence is part of the ecosystem history, but their maintainers, releases and features are separate from original Forge.
Is Forge Neo the new official version of Forge?
No. Forge Neo is the neo branch in Haoming02/sd-webui-forge-classic. It is a downstream continuation and must not be presented as a release by lllyasviel or as proof of original Forge support.
What was the last verified activity in original Forge?
At the 31 Aug 2026 check, the latest commit returned for the original main branch was dfdcbab from 26 June 2025. The repository was public and not archived. These are dated facts; they do not prove future maintenance or abandonment.
Did the planned Gradio 5 upgrade happen?
NEWS.md described planned attempts in 2025, but the inspected evidence for this page does not establish a completed Gradio 5 migration on main. It remains UNKNOWN here rather than being inferred from a roadmap.
Should I install the previous Forge version to keep extensions working?
Only when a known-good older environment is necessary for a named workflow. Keep it separate from a newer install, record the exact commit, and understand that an older build may lack later fixes and model support. Use a clean extension test before choosing.
How can I tell which generation of Forge a tutorial covers?
Look for the publication date, repository owner, branch, commit or startup version, Gradio generation, presence of Forge Canvas, and FLUX VAE/text-encoder controls. If those details are absent, treat the tutorial as a dated clue rather than exact installation guidance.
Every phase points back to the original record.
Official discussions, repository metadata, releases and named commits establish product history. Community reports were used to discover user language and failure questions—not to define Forge features.
Local research catalog used · 10 grouped records
Project definition, feature baseline and status context.
Public launch, asset dates and official rollback boundary.
Roadmap-vs-shipped distinction and dated later activity.
Initial purpose, A1111 relationship and myth correction.
Memory-first identity, experimental warning and clarification.
The concrete post-announcement rewrite phase.
Modern model loading and UI changes.
Post-rewrite compatibility and integration boundary.
Community interpretation and abandonment-language intent only.
Fork lineage and name-confusion context only.
No downstream feature is attributed to lllyasviel’s repository.
Current maintenance and future work remain UNKNOWN without a current maintainer statement.
NEWS and announcement plans are not treated as completed main-branch work.
Extension percentages and status claims retain their 2024 context.