Glonce

Gradio Workflow rebuilds AUTOMATIC1111 as a 73-node canvas

toolsThe Glonce editorsHugging Face🔥63Glonce rating63Impact60Novelty50Relevance85Surprise35Players75Credibility85
Gradio Workflow rebuilds AUTOMATIC1111 as a 73-node canvas

Hugging Face's Gradio team has published a blog post walking through Workflow1111, a gr.Workflow canvas that rebuilds most of AUTOMATIC1111's stable-diffusion-webui feature set. The canvas is a graph of 73 nodes organized into eleven media pipelines: text-to-image, hi-resolution fix, image-to-image, an LLM-based prompt writer, a VLM and ViT image-to-prompt reader, detection-to-inpaint masking, prompt-matrix grids, ControlNet-style annotators, upscaling and background removal, PNG Info metadata, and image-to-video. Every node is one of four operator kinds: an fn node runs a plain Python function, a model node calls a model through Hugging Face's InferenceClient, a space node calls another Gradio Space on the Hub, and a dataset node pulls a row from a Hub dataset. Visitors can run any pipeline by signing in with a Hugging Face account or supplying an access token, after which the model calls draw on that visitor's own quota.

The text-to-image pipeline is the core of the canvas and carries the controls familiar from A1111's txt2img tab: negative prompt, steps, CFG, seed, width, height, and a model_id field for the checkpoint. A prompt-builder fn node appends a style preset and cleans the text before a model node calls the checkpoint through Inference Providers, and a post-process fn node writes the generation parameters into the output PNG's metadata. Hi-resolution fix, which in AUTOMATIC1111 upscales the output and then runs a second denoising pass, becomes a two-node detour here: the text-to-image result goes to a FLUX.1-Kontext model node carrying the instruction to 'enhance fine detail and micro-texture, keep the composition identical.' The same Kontext node doubles as the image-to-image tab, taking an uploaded image and a text instruction and returning the edited result.

Two pipelines turn text and images into each other. Starting from a rough prompt such as 'A lighthouse in a storm,' a Qwen3-4B model node expands it and an fn node caps the result at forty tags, for example 'stormy sea, wet rocks, dramatic composition, low angle shot, volumetric lighting, ominous tone'; the post notes that wiring an LLM node straight into a diffusion node this way needs no custom node in Gradio Workflow, unlike in ComfyUI. Run in the other direction on a night-market photo, a Qwen2.5-VL node writes a prompt that could have produced the image, while a ViT classifier node reads the same image and returns labels: restaurant 51.9%, tobacco shop 15.6%, toyshop 9.1%. Because both nodes share one image input, gr.Workflow runs them in parallel, so both answers come back in roughly the time one alone would take.

For inpainting, a DETR node detects six objects in a street photo (three people, a dog, a bicycle, and a car), and the workflow then branches: one path draws the boxes on the original image, the other turns them into a mask for a downstream inpaint pipeline. Only the detection call itself leaves the machine; the box-drawing and the mask creation both run locally with Pillow and NumPy. The prompt-matrix pipeline pairs a base prompt, 'a lone oak tree,' with four suffixes (at sunrise, in a thunderstorm, under the Milky Way, in autumn fog), sends each variant to its own text-to-image node, and stitches the four results into one contact sheet. Because gr.Workflow has no loop operator, the four text-to-image nodes sit side by side at the same depth on the canvas, so all four images generate at once.

An Extras-style pipeline offers two upscaler nodes on different routes: a local Lanczos resample running entirely inside an fn node with no network call, and AuraSR, a ×4 upscaler and the canvas's first space node, which calls a Hub Space and treats the result like any other node output. Background removal works the same way through a BRIA RMBG-2.0 space node. The five ControlNet-style annotators (Canny, line art, sketch, luma-depth, and posterize) are each a plain-NumPy fn node with no model behind them, and on a pre-loaded building-facade example each one takes about half a second on CPU. In this section the post separately counts 36 operator nodes for the app, 32 of them fn nodes and 22 of those running entirely in-process with no network call, so roughly two-thirds of the canvas keeps working if the connection drops; it does not reconcile this 36-node figure with the 73-node total it states elsewhere for Workflow1111.

PNG Info reads back the generation parameters that the text-to-image pipeline's post-process node wrote into the file: prompt, negative prompt, steps, CFG, seed, image size, and model. This mirrors AUTOMATIC1111's own PNG Info tab. The same reference image also feeds a Wan 2.2 I2V A14B node for image-to-video; in the post's demo example, a sleeping fox wakes up and starts moving, and since one reference node can feed several downstream pipelines, a single upload gets both its metadata read and its animation rendered. Every model call described so far runs on someone else's hardware through Inference Providers or a Space, which is why Workflow1111 needs no GPU of its own. The post also shows an fn node loading and running a model locally instead: FastVideo/fastvideo-fasth3-preview, a separate gr.Workflow app, runs FastH3, a four-step distillation of MiniMax-H3, and generates video with a soundtrack on Hugging Face's ZeroGPU, which hands the bound function a GPU only for the duration of each call and releases it afterward. gr.Workflow itself does not need to know that any of that is happening.

Every output node on the canvas becomes a REST endpoint automatically, 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, all callable through the gradio_client Python library. Launching with mcp_server=True turns the same endpoints into MCP tools that an assistant such as Claude Code or Cursor can call directly, with each caller sending its own token in an X-HF-Token header so the Space itself holds no credentials. The post places Gradio Workflow against ComfyUI as covering similar ground for a lot of what people want to build and ship: a node can be hardware the builder does not own (Inference Providers, a Hub Space, any API, or a dataset row), OAuth lets visitors run a workflow under their own identity, diffusion models, LLMs, VLMs, detectors, and video models can share one canvas, and a custom node is just a Python function, free to do whatever Python can do.

To build a workflow from scratch, the post reduces the pattern to a few lines: write one or more plain Python functions, pass them to gr.Workflow(bind=[your_function]), and call .launch() to open an editable canvas in the browser, with gradio deploy publishing the finished app to a Space. Readers who would rather start from something working are pointed to Workflow1111 itself, which can be duplicated and rewired pipeline by pipeline, or to five smaller workflows from the team's previous post, each said to take about a minute to get running.

Key facts

  • Workflow1111 recreates most of AUTOMATIC1111's feature set as a single canvas of 73 nodes across eleven media pipelines, from text-to-image and hi-resolution fix to detection-to-inpaint masking and image-to-video.
  • Every pipeline runs on someone else's hardware through Inference Providers or a Hub Space under the signed-in user's own quota, so the canvas needs no GPU of its own; a separate app, FastVideo/fastvideo-fasth3-preview, runs the same fn-node pattern against a local GPU instead, generating video with FastH3, a four-step distillation of MiniMax-H3, on Hugging Face's ZeroGPU.
  • Workflow1111 exposes nine auto-generated REST endpoints, and launching with mcp_server=True turns the same endpoints into MCP tools that Claude Code, Cursor or any MCP client can call, with each caller sending its own token in an X-HF-Token header so the Space holds no credentials of its own.
  • The post's Annotators section separately counts 36 operator nodes for the app (32 fn nodes, 22 of them running entirely in-process without a network call), a figure it never reconciles with the 73-node total stated elsewhere in the same post for Workflow1111.
  • Nodes at the same dependency depth run in parallel: the VLM-interrogate and ViT-classifier nodes answer on one shared image at once, and all four text-to-image variants in the prompt-matrix pipeline generate simultaneously, because gr.Workflow has no loop operator.

Why it matters

AUTOMATIC1111's stable-diffusion-webui is the completeness benchmark the Gradio team picked for gr.Workflow, its node-graph builder inside Gradio; the tool it says gr.Workflow is usually compared against is ComfyUI, since both are node graphs. Showing that eleven of AUTOMATIC1111's pipelines fit into 73 nodes, with every model call running through Inference Providers or a Hub Space rather than local hardware, demonstrates that a full node-based image and video tool no longer needs its builder to own a GPU: the same nodes can call rented compute, another Space, an API, or a dataset row, and still add up to one working canvas.

Who it affects

Anyone assembling a multi-model image or video pipeline and weighing gr.Workflow against ComfyUI or a set of hand-rolled scripts; Hugging Face Space builders who want a canvas that generates REST endpoints on its own instead of routes written by hand; and developers wiring AI agents, since the same endpoints can be exposed as MCP tools that Claude Code, Cursor or another MCP client can call directly.

How to use it

Running the published pipelines needs only a Hugging Face account or an access token; once signed in, calls draw on the visitor's own quota, and the post gives no separate price for that quota or for self-hosting a model on a personal GPU instead. To build a canvas from scratch: wrap Python functions as fn nodes, pass them to gr.Workflow(bind=[your_function]), and call .launch() for an editable canvas in the browser, then run gradio deploy to publish it to a Space. Setting mcp_server=True exposes every output node as an MCP tool, and turning on OAuth lets visitors run the workflow under their own identity rather than the builder's. Readers can also duplicate Workflow1111 itself and rewire one of its eleven pipelines, or start smaller with five workflows from the team's previous post, each said to take about a minute to get running.

How solid is it

The account comes from Hugging Face's own Gradio team, on the company's blog, describing its own tool with code samples and worked examples rather than from an independent tester, and the post does not name an individual author. It is also not fully consistent with itself: the Annotators section puts the app's node count at 36 (32 fn nodes, 22 of them local), a figure that sits next to the 73-node total the post states twice elsewhere for Workflow1111, with the two never reconciled. The concrete numbers given, such as the ViT classifier's confidence scores or the half-second annotator timing, come from single worked examples rather than from benchmarks run across images or hardware.

Risks and caveats

The reported annotator speed, about half a second on CPU, comes from one pre-loaded building-facade photo, not from a benchmark across other images, resolutions, or hardware, so it should not be read as a general performance figure. Turning on mcp_server=True keeps the Space itself free of stored credentials by having each caller send its own X-HF-Token header, but it also means every calling agent now holds and transmits a live Hugging Face token of its own. The post carries no calendar date for its own publication, so there is no way from the text alone to judge how current the described endpoints, model choices, or node counts still are.

“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.”

— Hugging Face's Gradio team