AttributeError: ‘NoneType’ Object Has No Attribute ‘Sd_Checkpoint_Info’ | Fast Fixes That Work

Guide / By

This Stable Diffusion error means no checkpoint is loaded; choose a valid model, update WebUI and add-ons, then reload to restore sd_checkpoint_info.

When Stable Diffusion WebUI (AUTOMATIC1111 or Forge) throws attributeerror: ‘nonetype’ object has no attribute ‘sd_checkpoint_info’, the app is trying to read model metadata from an object that is None. In plain terms, the checkpoint never loaded or got unloaded mid-run, so anything that queries sd_checkpoint_info fails. The same pattern shows up across issue threads where shared.sd_model is None, breaking attributes like sd_model_hash as well (older A1111 swap error, runtime history).

Because the UI runs in a long-lived process, one failed load can poison later calls that try to reuse the same handle. That is why a model switch followed by one successful generate often clears the state. You are forcing the app to rebuild the internal objects, so calls that expect sd_checkpoint_info finally receive a real object.

AttributeError: ‘NoneType’ Object Has No Attribute ‘Sd_Checkpoint_Info’ — What It Signals

Quick context: The error points to a missing or invalid checkpoint object. Typical triggers include an interrupted load, a corrupted or half-downloaded file, an extension that hooks the model too early, or a switch between incompatible models. Community reports match this pattern: users see the message after a model swap or a failed state-dict load, then every job errors until a different checkpoint is selected and generated once (Forge cache behavior, Forge issue).

On the Python side, a NoneType attribute error always means you’re calling a property or method on None instead of a live object. The fix is to restore a valid object before anything uses it, which here means making sure a real checkpoint is loaded and ready (general Python explanation).

Common Causes And Symptoms

Match your symptom to a likely cause, then jump to the fix. These are the patterns people run into with this Stable Diffusion error.

Cause Typical Symptom Direct Fix
Checkpoint not fully loaded Error appears on first generate after launch Select a different checkpoint, generate once, then switch back
Corrupt or partial model file Model loads forever or fails; later calls break Re-download or replace the file; verify checksum
Extension conflict Error starts after installing/updating an add-on Disable extensions; re-enable one by one
Incompatible model family Swapped SDXL/SD2/SD1 without clean reload Pick a supported pair (base+VAE); reload UI
Stale cache/state Stuck until you change models Load different model, generate once, then return (Forge cache note)
Bad ControlNet/Preprocessor files Preprocessor fails, then model reads break Remove incomplete files and reinstall (ControlNet fix)

Fixes That Solve It Fast

  1. Load A Known-Good Checkpoint — Open the checkpoint dropdown and pick a standard, verified model (e.g., SD 1.5 pruned or SDXL base). Hit Generate once. If it works, switch back to your target model and try again. This pattern clears the stale state reported by users in Forge and A1111 threads (Forge cache behavior, A1111 swap error).
  2. Verify The Model File — Check that the .safetensors or .ckpt isn’t partial. If you pulled from a slow mirror or the download was interrupted, remove it and re-download. Broken files cause loads to succeed partially, then explode the moment the app reads sd_checkpoint_info. The same goes for ControlNet preprocessors: delete incomplete pytorch_model.bin files and reinstall (example).
  3. Update WebUI And Extensions — Bring A1111 or Forge to current versions, then update add-ons. Many threads were closed after upstream fixes and extension updates. In GitHub history you can see related attribute errors when switching checkpoints or reading model hash (checkpoint switch error).
  4. Restart Clean — Close the app and any Python processes, then relaunch with a fresh console. Cached model state can stick around until a full restart. This general step resolves NoneType attribute cases across Python projects (why they happen).
  5. Disable Extensions Temporarily — Start WebUI with the extensions folder renamed to extensions.off. Add items back one at a time until the error returns. Once you find the trigger, check its repo for updates or open issues.
  6. Match Model Family — Keep SDXL models with SDXL text encoders/VAEs, SD2 with SD2, and SD1.x with SD1.x. A mismatch can leave shared.sd_model unset, leading to the same message. Community threads around SDXL setup stress using matched base, refiner, encoders, and VAE (model listing quirks).
  7. Clear Broken Hires/Flux Settings — If the message began after turning on Hires Fix or a Flux workflow in Forge, switch Hires off, generate once on base settings, and then re-enable. Users have seen the exact text tied to Hires Fix on Flux in Forge (Forge Hires Fix thread).

Read The Console For Clues

Open the launch console and watch the first 50 lines. Messages about “state dict,” “missing keys,” or “encoder not found” will narrow the cause fast. When the loader skips a file due to shape or family mismatch, the UI can still draw, but the in-memory model stays None until a clean load finishes.

Check Folder Layouts

Make sure checkpoints live under models/Stable-diffusion, VAEs under models/VAE, and LoRAs under models/Lora. Mixed folders confuse pickers and scripts. Keep SDXL refiner separate from base and verify both appear in menus before you enable workflows that depend on them.

Sampler And Hires Settings

Stray hires settings can trigger the issue right after launch. Turn off high-res steps, keep batch size to one, and pick a default sampler such as DPM++ 2M Karras for the first test. The goal is to build a small, known-good job that only touches the core model.

Checkpoints With Custom Metadata

Some converted models carry odd metadata. If you see the error tied to one file only, try a different build of the same model from a trusted source. Files with mismatched yaml configs or embedded links can trip loaders in older extensions. Upgrading the extension or the UI tends to remove that friction.

Windows, macOS, And Linux Notes

  • Windows — Paths with long names or non-ASCII characters can trip Python packages. Keep the install close to the drive root and avoid syncing folders while you test.
  • macOS — Apple Silicon builds need the right Torch. If Python grabs a CPU-only wheel, model loads crawl and time out. Reinstall Torch with the wheel recommended by your WebUI fork.
  • Linux — Package managers can hold older ffmpeg or xformers. Use the project’s setup script or the exact pip lines from the readme.

AttributeError: ‘NoneType’ Object Has No Attribute ‘Sd_Checkpoint_Info’ — Fix Steps By Order

Work top-down. Each step either restores a valid model object or proves what’s blocking it.

  1. Pick A Baseline Checkpoint — Choose SD 1.5 v1-5-pruned-emaonly or SDXL Base. Generate once.
  2. Switch Back To Your Target — Return to the model you want. If the error returns, keep going.
  3. Remove Partial Files — Delete any half-downloaded model or preprocessor files. Re-download from a trusted host.
  4. Update Everything — Git pull the WebUI and refresh all extensions.
  5. Start With Extensions Off — Launch with the extensions folder renamed. Test generation, then re-add add-ons one by one.
  6. Reset Hires/Flux Paths — Test with Hires Fix off and simple sampler settings. Re-enable later.
  7. Check Console Logs — Look for lines about “state dict,” “text encoder,” or “model not found.” A missing encoder or VAE can point straight to the cause (missing encoders note).

Why It Often Appears After A Model Swap

Issue threads describe a loop: you change models, the loader throws a warning about a missing state dict or shape mismatch, and the next request raises attributeerror: ‘nonetype’ object has no attribute ‘sd_checkpoint_info’. In Forge, the cache can hold invalid params until you load a different checkpoint and complete one image, which refreshes internal state; switching back then works (Forge cache behavior, related issue).

In A1111, people saw sibling errors like sd_model_hash on None after failed swaps; fixes landed over time, but the practical move is the same: switch to a known-good model, generate, then come back (older swap error).

Confirm With A Small Repro

Build a three-step repro: launch, pick a baseline checkpoint, and render a tiny 512×512 image with a simple prompt. Save the log. Then switch to the problem checkpoint and repeat. If the baseline succeeds and the second run fails with the same text, you have a model-specific cause. If both fail after enabling a certain extension, the add-on is your lead. This split saves time and reduces guesswork.

Prevention: Keep Your Setup Stable

  • Keep Models And Add-Ons Current — Pull updates for WebUI and extensions on a schedule. Many NoneType errors vanish in later builds (related runtime history).
  • Verify Downloads — Prefer .safetensors, check file sizes and hashes, and avoid mixed folders with partials.
  • Group By Family — Keep SDXL bits together; do the same for SD 2.x and SD 1.x.
  • Limit First-Screen Add-Ons — Load core WebUI first; enable heavy extensions later in the session.
  • Document A “Known Good” Baseline — Save a profile with a clean model and sampler so you can recover quickly.

Backups pay off: keep a small zip with your baseline config, a good checkpoint, and a note on the exact launch command. When something breaks, you can restore the trio in minutes. If you join extension betas, test them in a separate copy of the app so your main folder stays clean.

Keep downloads tidy: avoid duplicate model names with tiny differences. Use clear names that include family and size, such as sdxl_base_1.0.safetensors. That makes menu choices unambiguous and shortens troubleshooting.

Clean Reinstall Without Losing Data

If none of the fixes restore a valid model object, rebuild the app folder but keep your models:

  1. Back Up Models And Settings — Copy the models, embeddings, and extensions folders somewhere safe.
  2. Clone A Fresh WebUI — Pull a new copy of A1111 or Forge into a clean directory. Install Python/Torch versions they require. Fresh installs solve many generic A1111 “Error code 1” and loader loops (clean install walkthrough).
  3. Restore Only What You Need — Bring back checkpoints and core assets first. Launch and test. Add extensions after you confirm that base generation works.

When you rebuild, resist the urge to drop every old file back at once. Launch the fresh copy with only one small checkpoint first. If that start-to-finish run works, add your VAE, then your most used LoRAs, then the rest. If an extension is required for your workflow, install the newest commit and test a single feature before enabling its extras.

If you manage multiple forks, add a lightweight launcher for each with flags that match the fork’s guidance. Keep logs per fork so you can spot whether a failure belongs to the app, the model, or a plug-in.

For teams, write a short recovery checklist and keep it in the repo. A consistent routine prevents long sessions of guesswork and keeps you generating.