The Hugging Face Gradio team just published Workflow1111, a full recreation of AUTOMATIC1111's stable-diffusion-webui as a single gr.Workflow canvas.
This isn't a UI wrapper. It's a graph of 73 nodes spanning eleven media pipelines: text-to-image, hi-res fix, image-to-image, prompt matrix grids, VLM interrogation, detection-to-inpaint masks, ControlNet-style annotators, background removal, PNG Info, and image-to-video. You can run any of these by signing in with your Hugging Face account. The model calls use your own quota, so the Space itself holds no API keys and runs no inference on its own GPU.
What makes this interesting is that it's a working example of a pattern we've been watching emerge: multi-model pipelines as composable graphs, where each node can be a function, a model call, a Space, or a dataset row. The whole thing runs in a browser, generates REST endpoints automatically, and exposes MCP tools for AI assistants—all from the same graph definition.
The Four Operator Kinds
Gradio Workflow builds everything from four primitives:
fn: a Python function that runs locally or on your own GPUmodel: a model called throughInferenceClient(i.e., Inference Providers)space: another Gradio Space on the Hub, called as a nodedataset: a row from a Hub dataset
Workflow1111 has 36 operator nodes. Of those, 32 are fn nodes, and 22 of them run entirely in-process without a network call. Roughly two-thirds of the canvas keeps working if you lose your connection.
This is a subtle but important design choice. In ComfyUI, if you want a custom preprocessing step—say, a Canny edge detector—you install a custom node. In gr.Workflow, you write a function. Since these are regular Python functions, you can test them directly with no canvas, server, or GPU involved.
What's Actually on the Canvas
Text-to-Image
This is the core pipeline. It has the controls you'd expect from AUTOMATIC1111's txt2img tab: negative prompt, steps, CFG, seed, width, height, plus a model_id field for choosing the checkpoint.
The prompt goes through a prompt-builder fn node first, which appends the selected style preset and cleans up the text, then into a model node that calls the checkpoint through Inference Providers. A post-process fn node writes the generation parameters into the PNG's metadata on the way out.
Hi-Resolution Fix and Image-to-Image
In AUTOMATIC1111, hi-res fix upscales the txt2img output and runs a second denoising pass. Here it's a two-node detour. The text-to-image result goes into a FLUX.1-Kontext model node with a refine instruction ("enhance fine detail and micro-texture, keep the composition identical") and comes back sharper and larger.
That same Kontext node doubles as the image-to-image tab. Upload an image, describe the change you want, and it returns the edited image.
LLM-Generated Prompts
Start with a rough prompt like "A lighthouse in a storm." This pipeline sends it to a Qwen3-4B model node, and a small fn node turns the reply into a clean list of tags, capped at forty: "stormy sea, wet rocks, dramatic composition, low angle shot, volumetric lighting, ominous tone."
There's no custom node involved. The LLM and the diffusion model are both ordinary model operators on the same canvas. You can connect any diffusion model node to this output to render the image.
VLM Interrogation
This is like AUTOMATIC1111's Interrogate button, but with a VLM doing the interrogating instead of CLIP. Qwen2.5-VL looks at a night-market photo and writes a prompt that could have produced it. A ViT classifier node reads the same image and returns labels: restaurant 51.9%, tobacco shop 15.6%, toyshop 9.1%.
Both nodes use the same image input, so gr.Workflow runs them in parallel and you get both answers in roughly the time it takes to run one.
Detection to Inpaint Mask
AUTOMATIC1111 makes you paint an inpaint mask by hand. This pipeline generates one from a detector instead.
DETR finds six objects in a street photo (three people, a dog, a bicycle, and a car), and from there the workflow splits into two branches: one draws the detected boxes on the original image, the other turns them into a mask you can feed into an inpaint pipeline downstream.
The drawing and the mask creation both happen locally with Pillow and NumPy. Only the detection call leaves the machine.
Prompt Matrix
This is like AUTOMATIC1111's prompt matrix. A base prompt, "a lone oak tree," gets combined with four suffixes (at sunrise, in a thunderstorm, under the Milky Way, in autumn fog) by an fn node, and each variant goes to its own text-to-image node. A final node stitches the four results into one contact sheet.
gr.Workflow has no loop operator, so the four text-to-image nodes sit side by side on the canvas. Since they're at the same dependency depth they run in parallel, and all four images start generating at once.
Upscale and Background Removal
This is like the Extras tab in AUTOMATIC1111. There are two upscaler nodes, and they take different routes.
The first is a local Lanczos resample in an fn node, which needs no network call and finishes as fast as Pillow can resize. The second is AuraSR ×4, and it's the first space node on the canvas: it calls a Space on the Hub and treats the result like any other node output.
Background removal works the same way. BRIA RMBG-2.0 is another space node, so the whole model lives in its own Space and this canvas just calls it in.
Annotators
Canny, line art, sketch, luma-depth, and posterize are the preprocessors you'd normally get from the ControlNet extension in AUTOMATIC1111. Here, each one is an fn node written in plain NumPy, with no model behind it.
On a pre-loaded example photo of a building facade, each annotator takes about half a second on CPU.
PNG Info and Image-to-Video
AUTOMATIC1111 stores generation details in the PNG's parameters text chunk, and the PNG Info tab reads them back. Workflow1111 does the same. The post-process node on the text-to-image pipeline writes the metadata, and this pipeline reads it back out, including the prompt, negative prompt, steps, CFG, seed, image size, and model.
The image node that PNG Info reads from also feeds a Wan 2.2 I2V A14B node, which animates it. In the demo example a sleeping fox wakes up and starts moving. There's no second upload box because one reference node can feed as many downstream pipelines as you need, so a single upload gets its metadata read and gets animated on the same canvas.
Running Models on Your Own GPU
So far every model call has gone to someone else's hardware, through Inference Providers or a Space. That's why you can build and run something like Workflow1111 without a GPU of your own.
An fn node is just Python, though, so it can equally load a model locally and run it on your own GPU.
The blog post cites FastVideo/fastvideo-fasth3-preview as an example. It runs FastH3, a four-step distillation of MiniMax-H3, and generates video with a soundtrack on ZeroGPU. The whole app comes down to one bound function:
@spaces.GPU(
duration=get_duration,
size=GPU_SIZE
)
def _generate(
prompt_embeds,
text_token_tags,
height, width,
num_frames, seed
):
...
gr.Workflow(bind={
"generate": generate,
"status": status
}).launch()
ZeroGPU gives the function a GPU when it needs one, then releases it when the call is done. gr.Workflow doesn't need to know about any of that. It just calls the fn node.
This isn't specific to Spaces either. Point bind= to a function that loads a local checkpoint, run .launch() on your own machine, and the Workflow1111 canvas can drive your own GPU.
Every Output Is an API
Every output node on the canvas becomes a REST endpoint, with no routes written by hand. Workflow1111 exposes nine of them: /image, /edited_image, /generated_prompt, /recovered_prompt, /detected_objects, /x_y_grid, /upscaled_local, /annotator_map, and /png_info.
from gradio_client import Client
client = Client(
"ysharma/Workflow1111",
oauth_token="hf_..."
)
image, params, hires = client.predict(
"a red fox in a snowy pine forest", # Prompt
"", # Negative prompt
"Cinematic", # Style preset
"enhance fine detail", # Hires refine instruction
api_name="/image",
)
The same endpoints are also MCP tools. Launch with mcp_server=True and every output node shows up as a tool an AI assistant can call. Point Claude Code, Cursor, or any MCP client at the server URL, and an agent can generate an image, read a prompt back out, or run detection as steps in a larger task, with no glue code.
Each caller sends their own token in the X-HF-Token header, so the Space holds none of its own.
Where This Sits Next to ComfyUI
AUTOMATIC1111 gave the feature list, but the tool gr.Workflow really gets compared to is ComfyUI, since both are node graphs.
For a lot of what people want to build and ship, gr.Workflow covers the same ground:
- A node can be hardware you don't own. It can run through Inference Providers, call any Space on the Hub or any API, or pull from a dataset. That's how Workflow1111 runs without a GPU of its own.
- Every output becomes a typed REST endpoint. The endpoints are generated from the graph.
- Visitors can run workflows under their own identity. Turn on OAuth, share the public URL, and anyone can sign in and use the app without installing anything.
- Mix models and modalities on the same canvas. Diffusion models, LLMs, VLMs, detectors, and video models can all be part of the same workflow.
- Need something custom? Write a function. A custom node is a Python function, so it can do whatever Python can.
The result is a multi-model pipeline that people can open in a browser, sign into, use right away, and call from code.
Build Your Own
Workflow1111 has 73 nodes, but it started with just this:
import gradio as gr
def your_function(text: str) -> str:
pass
gr.Workflow(bind=[your_function]).launch()
bind= turns your functions into nodes, edges= connects them, and .launch() opens the canvas in your browser so you can keep editing there. When it's ready, gradio deploy puts the whole thing on a Space.
If you'd rather start from something that already works, open Workflow1111, hit Duplicate, and pick one of the eleven pipelines to change: delete nodes, swap models, rewire the flow.
The fact that this entire AUTOMATIC1111 clone is a single deployable artifact—no extensions, no plugin system, no environment setup—feels like the direction this space is heading. Whether gr.Workflow becomes the standard or just a forcing function for the ecosystem, the pattern is clear: graphs beat scripts, composability beats monoliths, and OAuth beats API key management.