unslothai/unsloth · error · RuntimeError

The stable-diffusion.cpp binary at {binary} does not adverti

Error message

The stable-diffusion.cpp binary at {binary} does not advertise MiniMax-H3 support (its --help does not list the H3 options), so generation would fail on it. Point SD_CLI_PATH at a 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 when the binary's --help DOES identify stable-diffusion.cpp but does not list the MiniMax-H3 options, i.e. it is a genuine but too-old build. The backend refuses to proceed because generation with H3 options would fail on that build, and since the binary is user-provided (not managed) it cannot be silently replaced.

Source

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

    # 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
    # unlink but the next image in the batch can no longer resolve it, and on Windows the unlink
    # fails outright and the H3 load is refused. Held only across the unlink -- ensure_sd_cpp_binary
    # below claims the tree itself, and the claim is not reentrant.
    with _tree_claimed_for_install() as claimed:
        if not claimed:
            logger.warning(

View on GitHub (pinned to 203007d190)

Solutions

1. Rebuild/re-download stable-diffusion.cpp from master-812-ea7f0c8 or newer and point SD_CLI_PATH (or UNSLOTH_SD_CPP_PATH) at it.
2. Unset the override and let the backend auto-install its managed binary, if auto-install is permitted.
3. Verify with `<binary> --help | grep -i h3` that the new build advertises the H3 options before retrying.

Example fix

# before
export SD_CLI_PATH=/opt/sd.cpp-old/sd-cli  # pre-H3 build

# after
git checkout master-812-ea7f0c8 && cmake --build build
export SD_CLI_PATH=/opt/sd.cpp/build/sd-cli

import subprocess

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

When it happens

Trigger: SD_CLI_PATH / UNSLOTH_SD_CPP_PATH / in-tree developer build / PATH sd-cli pointing at a stable-diffusion.cpp build older than master-812-ea7f0c8, then triggering a load or generation that requires H3 support.

Common situations: A previously-working pinned build after the H3 requirement was introduced; a distro or container image shipping an older sd.cpp; a stale developer build in the tree after pulling new backend code.

Related errors

• The executable at {binary} is not stable-diffusion.cpp: its
• sd-server binary is present but not runnable.
• sd-cli binary is present but not runnable.
• sd-server img_gen returned a non-JSON submit response: {exc}
• deadline reached before {method} {_redact_url(url)}

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