Workflow1111 Reconstructs AUTOMATIC1111 Features on Gradio Workflow Canvas

Workflow1111 Reconstructs AUTOMATIC1111 Features on Gradio Workflow Canvas Hugging Face's Workflow1111 rebuilds the core capabilities of AUTOMATIC1111's stable-diffusion-webui across a single canvas comprising 73 nodes and 11 distinct media pipelines. Powered by four core operator types, the setup enables multi-modal generation, automated API endpoint exposure, and flexible execution across cloud APIs, local GPUs, and MCP tool clients. Workflow1111 features 73 nodes and 11 media pipelines built from four core operator types: fn (Python function), model (InferenceClient), space (Hub Gradio Space), and dataset. The application integrates text-to-image, hi-res fix, image-to-image, prompt expansion via Qwen3-4B, visual prompt interrogation with Qwen2.5-VL and ViT, object-detection masking using DETR, and Wan 2.2 image-to-video. Local processing is handled heavily by Python and NumPy, allowing 22 out of 32 fn nodes to execute in-process without network requests. Pipelines automatically expose typed REST endpoints and can act as Model Context Protocol (MCP) tools for AI agents, passing authentication via user-provided Hugging Face tokens. Functions can execute locally on user hardware or ZeroGPU, differentiating gr.Workflow as a zero-install, multi-modal node alternative to ComfyUI. Architecture and Core Operators Workflow1111 translates the diverse feature set of AUTOMATIC1111 into a unified graph constructed from four node primitives: Python functions (fn), models called via InferenceClient (model), external Hugging Face Spaces (space), and dataset rows (dataset). The full graph contains 73 nodes, including 36 operator nodes. Notably, 32 of these are fn nodes and 22 run entirely in-process without network access, ensuring roughly two-thirds of the canvas functions even when disconnected. Users authenticate with their own Hugging Face account tokens to utilize their personal inference quotas. Image Generation, Refinement, and Matrix Processing The core text-to-image pipeline manages prompts, style presets, checkpoints, and parameters while embedding generation metadata directly into PNG outputs. Rather than relying on separate UI tabs, hi-resolution fixes and image-to-image workflows route directly through a FLUX.1-Kontext node. Because gr.Workflow executes nodes at the same dependency depth in parallel without traditional loop constructs, prompt matrices run multiple text-to-image calls concurrently before stitching the outputs into a single contact sheet. Multimodal Pipelines and Local Processing A variety of specialized tasks are delegated to modular nodes without custom software extensions. Qwen3-4B refines raw prompts into tag lists, while Qwen2.5-VL and a ViT classifier run in parallel to interrogate uploaded images for descriptive prompts and classification labels. Inpainting masks are generated automatically by DETR detecting objects and converting bounding boxes via NumPy and Pillow, while ControlNet-style annotators (such as Canny, sketch, and depth) run in plain NumPy on the CPU. External models like AuraSR upscaling and BRIA RMBG-2.0 background removal are integrated seamlessly via space nodes. Local Execution, REST APIs, and MCP Integration While Workflow1111 can operate without dedicated local hardware by relying on inference providers, fn nodes can be bound to local functions or ZeroGPU decorators to run proprietary checkpoints or distilled models like FastH3. Every output node automatically becomes a typed REST endpoint across nine distinct routes. Setting mcp_server=True further surfaces these outputs as Model Context Protocol tools, enabling external assistants such as Claude Code or Cursor to trigger image generation, detection, or metadata extraction directly.

Hugging Face 推出 Workflow1111：基于 Gradio Workflow 重建 AUTOMATIC1111 功能 Hugging Face 介绍了基于 gr.Workflow 构建的 Workflow1111，通过 73 个节点搭建出包含 11 条媒体处理管线的单个工作流画布，完整重现了 AUTOMATIC1111 的核心功能，并支持免本地 GPU 运行及自动生成 API 和 MCP 工具接口。 Workflow1111 包含 73 个节点和 11 条媒体管线，基于 Python 函数、模型推理、Hub 空间和数据集四种算子构建。 集成了文生图、高分辨率修复、图生图、LLM 扩写提示词、VLM 反推、目标检测生成蒙版、提示词矩阵及图生视频等功能。 无需本地 GPU 即可运行远程推理，同时也支持绑定本地 GPU 或 ZeroGPU 进行模型计算。 画布的每个输出节点均自动生成 REST 端点并支持 MCP 协议，便于开发者与 AI 助手直接调用。 画布架构与核心功能管线 Workflow1111 画布完全采用 fn（Python 函数）、model（模型接口）、space（其他 Gradio Space）和 dataset（数据集）四类算子构建。在文生图流程中，提示词经函数预处理后由模型生成，并写入 PNG 元数据。系统使用 FLUX.1-Kontext 实现高分辨率微调与图生图，借助 Qwen3-4B 进行提示词标签扩展，使用 Qwen2.5-VL 与 ViT 并行反推图像内容，并利用 DETR 目标检测在本地用 Pillow 和 NumPy 自动生成修补蒙版。此外，还涵盖了基于平铺并行运行的提示词矩阵、AuraSR 与 BRIA RMBG 超分与去背、NumPy 实现的无模型预处理器，以及驱动 Wan 2.2 I2V A14B 的图生视频功能。 算力支持与开发者接口集成 工作流通过 Hugging Face 账号登录使用个人配额，调用云端推理提供商或外部 Space，因此无需本地独立显卡；若要使用自有显卡，只需将 fn 节点绑定到本地函数或 ZeroGPU 环境中。画布无需手动编写路由即可将输出转换为类型化 REST 端点，共暴露 9 个常用接口。同时，系统支持开启 mcp_server 选项，使输出节点成为 Claude Code、Cursor 等客户端可直接调用的 MCP 工具，调用者可通过请求头传递专属 Token。 相较于 ComfyUI 的定位与开发体验 与同样采用节点图设计的 ComfyUI 相比，Gradio Workflow 允许节点直接依托远端云硬件或 API 运行，天然具备无需部署本地算力的特性。借助内置的 OAuth，访客可直接登录使用而无需本地安装环境。此外，开发者只需编写常规 Python 函数即可快速创建自定义节点，并且整个多模态管线可直接通过浏览器交互，或使用 gradio deploy 快速发布至 Hugging Face Space。

In our last post , we built five small gr.Workflow graphs and hinted at what it would take to build something as complex as AUTOMATIC1111's stable-diffusion-webui . In this post we walk you through Workflow1111 , where we have rebuilt most of AUTOMATIC1111's feature set as a single workflow canvas. Workflow1111 is a graph of eleven media pipelines built using seventy-three nodes . It brings together SOTA models for text-to-image, hi-resolution fix, image-to-image, prompt-matrix grids, VLM interrogate, detection-to-inpaint masks, ControlNet-style annotators, background removal, PNG Info storing, and image-to-video. You can run any of these pipelines by signing in with your Hugging Face account or providing an access token. Once you sign in, the model calls use your own quota. 👉 Try Workflow1111 , or duplicate the Space and start rewiring it for your own use case. Let's walk the canvas. What's on the canvas All the media pipelines are built from the same four operator kinds covered in our last post and the official guide . Each node on the canvas wraps one operator, and the operator's inputs and outputs become the ports you connect edges to. As a quick reference on our four operator kinds: fn is a Python function, model is a model called through InferenceClient , space is another Gradio Space, and dataset is a row from a Hub dataset. Let's go through the pipelines one by one. Text-to-image This is the core pipeline. It has the controls you'd expect from A1111's txt2img tab: negative prompt, steps, CFG, seed, width and 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, which is what the PNG Info pipeline reads back later. Hi-resolution fix In Automatic1111, hi-resolution fix first upscales the txt2img output and then runs a second denoising pass. Here it's a two-node detour instead. 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. Image-to-image 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. Let an LLM write the prompt 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." You can connect any diffusion model node to this output to render the image. There's no custom node involved, unlike in ComfyUI. In a Gradio workflow the LLM and the diffusion model are both ordinary model operators on the same canvas. Read an image back into a prompt This is like AUTOMATIC1111's Interrogate button, 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 a 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 a 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. There are 36 operator nodes in the app, 32 are fn nodes, and 22 of those run entirely in-process without a network call. Roughly two-thirds of the canvas keeps working if you lose your connection. Since these are regular Python functions, you can also test them directly, with no canvas, server, or GPU involved. PNG Info 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. Image-to-video 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. A fn node is just Python, though, so it can equally load a model locally and run it on your own GPU. FastVideo/fastvideo-fasth3-preview is a gr.Workflow app that does exactly that. 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 ( guide ) 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: { "mcpServers" : { "workflow1111" : { "url" : "https://ysharma-workflow1111.hf.space/gradio_api/mcp/" , "headers" : { "X-HF-Token" : "hf_..." } } } } Now 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 us the feature list, but the tool Gradio 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. The gr.Workflow guide has the full details, including the JSON schema and every operator type. 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. If you'd rather start smaller, the previous post has five workflows you can get running in about a minute each. Whatever you build, post it on X and tag @gradio . We'd be happy to amplify your workflows.