The Web UI as a Platform: Scripts, Extra Networks, and API Automation

AUTOMATIC1111/stable-diffusion-webui becomes a platform when a new capability can attach to an existing processing stage instead of requiring the core interface to be rewritten. The focus here is how scripts, callbacks, extra networks, extensions, and the API cross that boundary. Understanding where each surface enters lets a reader choose the least surprising way to change a workflow—and recognize that every new capability also adds compatibility and trust decisions.

The important distinction is between adding a control and adding a new participant. A built-in setting changes a request the core runtime already understands. A script can add controls and modify a processing object. An extra network can turn prompt markup into a model-side operation. An extension can add a page, settings, callbacks, or routes. An API client can invoke the same pipeline without using the browser. These surfaces overlap, but they do not own the same state or carry the same maintenance burden.

Extensions attach to stages, not just screens

The extension system begins before an image request. AUTOMATIC1111 scans its built-in and external extension locations, reads metadata, applies enabled or disabled state, and checks declared relationships. Script files can declare requirements and ordering constraints. The loader resolves those relationships and topologically orders the scripts before the runtime creates the script runners used by text-to-image, image-to-image, and post-processing. A script that depends on another script is therefore not merely a file that happens to load later; it is a participant in an ordered lifecycle.

A script can be selectable or always-on. A selectable script contributes controls that appear when the user chooses it, then receives those values when it runs. An always-on script stays attached to the relevant processing path and can act at defined points even when no separate dropdown selection is made. Both kinds can expose their controls to the API. That distinction matters operationally: a selectable script is easier to reason about as an explicit intervention, while an always-on script can affect every request that reaches its lifecycle.

The script contract is organized around moments in the job. A script can create UI components and register fields for generation information. It can modify the processing object before work begins, change prompts or seeds for a batch, act after extra networks are activated, run before each sampling pass, inspect samples before decoding, transform images after decoding, participate in mask blending, or finalize a processed result. It can also add components before or after selected UI elements. The exact hook names are less important than the ownership question: a script that runs before conditioning changes a different cause from one that runs after the image has been decoded.

Callbacks provide a second route into those moments. The project defines callback categories for events such as application start, model load, UI construction, image saving, sampler-related work, component creation, infotext pasting, and optimizer or UNet discovery. Extensions register functions into those categories.