unslothai/unsloth · error · RuntimeError

The executable at {binary} is not stable-diffusion.cpp: its

Error message

The executable at {binary} is not stable-diffusion.cpp: its --help output does not identify the project. Point SD_CLI_PATH at a stable-diffusion.cpp build from master-812-ea7f0c8 or newer, or UNSLOTH_SD_CPP_PATH at the directory holding one{_h3_replacement_hint(binary)}.

What it means

Raised by the managed-binary validation gate when the executable resolved for sd.cpp generation runs --help and the output does not identify the stable-diffusion.cpp project. The gate exists because the H3 capability marker is absent from every non-sd.cpp program, so misreporting it as an 'old build' would send users hunting for updates to something they never installed (issue #8507, where Debian/Ubuntu's `sd` find-and-replace tool was picked up). Because the binary is not managed (it came from SD_CLI_PATH / UNSLOTH_SD_CPP_PATH, an in-tree developer build, or a PATH `sd-cli`), the backend refuses to overwrite it and stops.

Source

Thrown at studio/backend/core/inference/sd_cpp_backend.py:502

    # the class of program #8507 was about -- through SD_CLI_PATH instead of PATH. Upstream added
    # H3 eight months after print_usage started with the project banner, so a genuine H3 build
    # always answers both.
    identified = help_text_identifies_sd_cpp(help_text)
    if identified and help_text_supports_minimax_h3(help_text):
        return binary
    # What is wrong with it, for the log lines on the managed path below: a managed copy that is not
    # sd.cpp at all is still deleted and reinstalled, but calling it an old build would be false.
    fault = "does not advertise MiniMax-H3 support" if identified else "is not stable-diffusion.cpp"
    if not is_managed_binary(binary):
        # Not an old sd.cpp -- not sd.cpp at all. Worth its own message: the H3 marker is missing
        # from EVERY program that is not stable-diffusion.cpp, so reporting the capability verdict
        # here sent users hunting for a newer build of something they never installed (#8507, where
        # the binary was Debian/Ubuntu's `sd` find-and-replace tool). Discovery already skips an
        # unrelated PATH `sd`, so what reaches this line came from somewhere the identity gate does
        # not cover -- an SD_CLI_PATH / UNSLOTH_SD_CPP_PATH override, an in-tree developer build, or
        # a PATH `sd-cli`. None of them is ours to overwrite, so all four say so and stop.
        if not identified:
            raise RuntimeError(
                f"The executable at {binary} is not stable-diffusion.cpp: its --help output does "
                f"not identify the project. Point SD_CLI_PATH at a stable-diffusion.cpp build from "
                f"master-812-ea7f0c8 or newer, or UNSLOTH_SD_CPP_PATH at the directory holding one"
                f"{_h3_replacement_hint(binary)}."
            )
        raise RuntimeError(
            f"The stable-diffusion.cpp binary at {binary} does not advertise MiniMax-H3 support "
            f"(its --help does not list the H3 options), so generation would fail on it. "
            f"Point SD_CLI_PATH at a build from master-812-ea7f0c8 or "
            f"newer, or UNSLOTH_SD_CPP_PATH at the directory holding one"
            f"{_h3_replacement_hint(binary)}."
        )
    if not allow_install:
        # Ours, but replacing it is exactly what auto-install is switched off for.
        logger.warning("managed sd.cpp binary %s %s", binary, fault)
        return None
    # Deleting it is a WRITE to the managed tree, so it takes the same admission an install does.
    # An image one-shot may be executing this very file: on Linux the running child survives the

View on GitHub (pinned to 203007d190)

Solutions

1. Point SD_CLI_PATH at a genuine stable-diffusion.cpp executable built from master-812-ea7f0c8 or newer (or UNSLOTH_SD_CPP_PATH at the directory holding one).
2. Run `<binary> --help` yourself and confirm it identifies stable-diffusion.cpp; if it does not, replace or rebuild that binary.
3. Unset the override so the backend installs its own managed copy: unset SD_CLI_PATH UNSLOTH_SD_CPP_PATH.
4. If a PATH `sd-cli` is the culprit, remove/rename it so discovery skips it.

Example fix

# before
export SD_CLI_PATH=/usr/bin/sd  # Debian find-and-replace tool

# after
export SD_CLI_PATH=/opt/sd.cpp-build/sd-cli  # real stable-diffusion.cpp build >= master-812-ea7f0c8

import subprocess

def is_stable_diffusion_cpp(binary: str) -> bool:
    try:
        out = subprocess.run([binary, '--help'], capture_output=True, text=True, timeout=15)
    except Exception:
        return False
    return 'stable-diffusion' in (out.stdout + out.stderr).lower()

try:
    engine = backend._resolve_engine()
except RuntimeError as e:
    if 'is not stable-diffusion.cpp' in str(e):
        raise SystemExit('Fix SD_CLI_PATH/UNSLOTH_SD_CPP_PATH to point at a real sd.cpp build')
    raise

When it happens

Trigger: Setting SD_CLI_PATH or UNSLOTH_SD_CPP_PATH to a directory containing an unrelated binary named `sd`/`sd-cli` (e.g. the Debian `sd` sed-clone); having an in-tree developer build that is actually a different program; a PATH `sd-cli` that is not stable-diffusion.cpp. Any call that reaches _resolve_engine()/ensure_sd_cpp_binary() with such a binary on a generation or load path.

Common situations: Installing the Debian/Ubuntu `sd` package (find-and-replace tool) which shadows the expected name; copy-pasting an export SD_CLI_PATH=... line pointing at the wrong directory; a broken or truncated binary whose --help emits nothing recognizable.

Related errors

• The stable-diffusion.cpp binary at {binary} does not adverti
• sd-server binary is present but not runnable.
• sd-cli binary is present but not runnable.
• sd-cli (stable-diffusion.cpp) binary is unavailable.
• sd-cli (stable-diffusion.cpp) binary not found. Build it or

AI-assisted analysis of unslothai/unsloth@203007d190 (2026-08-15). Data as JSON: /api/errors/bf837ae1fc17f623. Report an issue: GitHub.