Lightning-AI/pytorch-lightning · error · ValueError

`save_to_log_dir=False` only makes sense when subclassing Sa

Error message

`save_to_log_dir=False` only makes sense when subclassing SaveConfigCallback to implement `save_config` and it is desired to disable the standard behavior of saving to log_dir.

What it means

SaveConfigCallback normally writes the parsed config to the log dir; save_to_log_dir=False exists only so subclasses that fully override save_config() can opt out. The constructor raises ValueError if save_to_log_dir=False is set on the base class (or a subclass that does not override save_config).

Source

Thrown at src/lightning/pytorch/cli.py:256

    def __init__(
        self,
        parser: LightningArgumentParser,
        config: Namespace,
        config_filename: str = "config.yaml",
        overwrite: bool = False,
        multifile: bool = False,
        save_to_log_dir: bool = True,
    ) -> None:
        self.parser = parser
        self.config = config
        self.config_filename = config_filename
        self.overwrite = overwrite
        self.multifile = multifile
        self.save_to_log_dir = save_to_log_dir
        self.already_saved = False

        if not save_to_log_dir and not is_overridden("save_config", self, SaveConfigCallback):
            raise ValueError(
                "`save_to_log_dir=False` only makes sense when subclassing SaveConfigCallback to implement "
                "`save_config` and it is desired to disable the standard behavior of saving to log_dir."
            )

    @override
    def setup(self, trainer: Trainer, pl_module: LightningModule, stage: str) -> None:
        if self.already_saved:
            return

        if self.save_to_log_dir:
            log_dir = trainer.log_dir  # this broadcasts the directory
            assert log_dir is not None
            config_path = os.path.join(log_dir, self.config_filename)
            fs = get_filesystem(log_dir)

            if not self.overwrite:
                # check if the file exists on rank 0
                file_exists = fs.isfile(config_path) if trainer.is_global_zero else False

View on GitHub (pinned to 9fed5c27d2)

Solutions

1. Subclass SaveConfigCallback, override save_config(self, trainer, pl_module, stage), and pass it via LightningCLI(save_config_callback=MySaveConfig)
2. Or disable saving entirely: LightningCLI(save_config_callback=None)
3. Keep save_to_log_dir=True if the standard behavior is acceptable

Example fix

# before
cli = LightningCLI(MyModule, save_config_kwargs={"save_to_log_dir": False})  # ValueError
# after
class MySaveConfig(SaveConfigCallback):
    def save_config(self, trainer, pl_module, stage):
        pass  # custom persistence (or nothing)
cli = LightningCLI(MyModule, save_config_callback=MySaveConfig)
# or: cli = LightningCLI(MyModule, save_config_callback=None)

from lightning.pytorch.cli import SaveConfigCallback
from lightning.pytorch.utilities.model_helpers import is_overridden

def can_disable_log_save(cb_cls) -> bool:
    return is_overridden('save_config', cb_cls('f', {}, False), SaveConfigCallback) if False else \
           'save_config' in cb_cls.__dict__  # subclass overrides save_config
# simplest guard: only set the flag in subclasses that define save_config

from lightning.pytorch.cli import SaveConfigCallback

def may_set_save_to_log_dir_false(cls) -> bool:
    return isinstance(cls, type) and issubclass(cls, SaveConfigCallback) and 'save_config' in cls.__dict__

When it happens

Trigger: LightningCLI(..., save_kwargs={'save_to_log_dir': False}) without a custom SaveConfigCallback subclass overriding save_config.

Common situations: Users wanting to silence config dumping for cleanliness by just flipping the flag, without implementing their own persistence.

Related errors

• {self.__class__.__name__} expected {config_path} to NOT exis
• {_JSONARGPARSE_SIGNATURES_AVAILABLE}
• Cannot add arguments from: {lightning_class}. You should pro
• `{self.__class__.__name__}.add_configure_optimizers_method_t

AI-assisted analysis of Lightning-AI/pytorch-lightning@9fed5c27d2 (2026-08-28). Data as JSON: /api/errors/49491038e9aab417. Report an issue: GitHub.