In Keras, when do you use ReduceLROnPlateau instead of LearningRateScheduler?

## Two different questions Both callbacks change the learning rate during `fit()`, but they answer different questions. `LearningRateScheduler` answers "what should the rate be at epoch *n*?" — the answer is known before the run starts. `ReduceLROnPlateau` answers "has progress stalled, and should I cut the rate now?" — the answer depends on what the run does. ## LearningRateScheduler `keras.callbacks.LearningRateScheduler(schedule, verbose=0)` takes a callable. Keras invokes it in `on_epoch_begin` with the zero-based epoch index and the current learning rate, and assigns the returned float to the optimizer. Because it is your function, any epoch-indexed shape is available: ``` def step_decay(epoch, lr): return lr * 0.1 if epoch in (30, 60) else lr ``` The granularity is per epoch, not per step. If you want a rate that changes every batch — a warm-up over the first 500 steps, say — a per-epoch callback cannot express it, and you want an optimizer-level schedule instead. ## ReduceLROnPlateau `keras.callbacks.ReduceLROnPlateau(monitor="val_loss", factor=0.1, patience=10, mode="auto", min_delta=1e-4, cooldown=0, min_lr=0.0)` runs in `on_epoch_end`. It keeps a best value and a wait counter exactly like `EarlyStopping`: improvement by more than `min_delta` resets the counter, and when the counter reaches `patience` the callback multiplies the current rate by `factor` (0.1 by default — an aggressive order-of-magnitude cut; 0.5 is the more common hand-set value), clamps it at `min_lr`, and enters a `cooldown` period during which the counter is not incremented. Cooldown exists because a rate cut takes a few epochs to show up in the metric, and without it the callback would fire again immediately and drive the rate to `min_lr` in a handful of epochs. Because the mechanics mirror EarlyStopping, the same configuration errors apply: `mode` must match the metric direction, the `monitor` key must actually exist in the epoch logs, and `min_delta` must be large enough that noise does not count as improvement. ## Using both, and the ordering with EarlyStopping ReduceLROnPlateau and EarlyStopping are frequently used together on the same metric, and the only rule that matters is that the reducer's patience must be shorter than the stopper's. If EarlyStopping has `patience=3` and ReduceLROnPlateau has `patience=5`, the run always stops before the rate is ever cut, and the reducer is dead code. A typical pairing is `patience=3` on the reducer and `patience=8` on the stopper, giving the model two or three rate cuts to escape a plateau before the run is abandoned. ## The conflict with optimizer-level schedules Keras offers a second, independent mechanism: `keras.optimizers.schedules` objects such as `ExponentialDecay` or `CosineDecay`, passed as the optimizer's `learning_rate`. These are evaluated by the optimizer itself on every step, using the iteration counter, which is why they can express per-step warm-up and decay that a per-epoch callback cannot. The two mechanisms do not compose. A schedule object *is* the value of `optimizer.learning_rate`; a callback that assigns a float there replaces the object, so the schedule stops applying from that moment on. Likewise `LearningRateScheduler` reads the current rate to hand to your function, and a schedule object is not a plain float. The resulting behaviour is confusing rather than obviously broken — hence the rule: either the optimizer owns the schedule, or the callbacks do. Never both. ## How to verify what is actually happening The rate is readable in a callback as `self.model.optimizer.learning_rate`, so a three-line custom callback that appends it to the logs dict in `on_epoch_end` puts the true rate into `history.history` and into any CSV log. Both built-in callbacks accept `verbose=1`, which prints on each change. Given how easy it is to configure a scheduler that silently never fires, printing or logging the rate is worth the two lines on any run where the schedule matters. ## Which to reach for Use a fixed schedule when you are reproducing a known recipe, when the run is long and well-characterised, or when you need sub-epoch shaping like warm-up. Use ReduceLROnPlateau when you are exploring, when the dataset is new, or when run length varies — it needs no tuning of the decay points, only a sensible `factor` and a `patience` shorter than your stopping rule.