Skip to content

Rate Limit and Cooldown Rule

A control rule — instantiates Coupling Latency and Time-Delay Effects

Caps how often and how hard a loop is allowed to react, forcing a wait after each action so a delayed effect can land before the next correction piles on.

A Rate Limit and Cooldown Rule constrains a loop's reaction rather than its perception: it caps how frequently, and often how strongly, the loop is permitted to act, and it imposes a mandatory quiet period after each action. What makes it this mechanism and not its siblings is that it fights delay-driven overshoot by turning the response down, not by measuring or predicting the delay. The cooldown embodies a simple discipline: after you act, wait long enough for the effect to arrive before you judge whether to act again — so that a delayed system isn't corrected three more times for a change that has already taken hold.

Example

A cloud service auto-scales its server fleet against CPU load. But a newly launched instance takes ≈4 minutes to boot, join the pool, and start absorbing traffic. Without restraint, the scaler sees high CPU, adds servers, still sees high CPU (the new ones aren't ready yet), adds more, and by the time all of them are live the load has dropped — so it tears them all down, then the next spike repeats the thrash. A cooldown rule breaks the cycle: after any scaling action, the scaler is forbidden from acting again for ≈5 minutes — comfortably longer than the boot delay — so it always evaluates load after its last decision has actually taken effect. A companion rate limit caps how many instances a single action may add, so no one reading overreacts. The loop settles instead of hunting, at the cost of responding a little more slowly to a genuine spike.

How it works

  • Cap the response magnitude. Limit how large a single correction can be, so one alarming (and possibly stale) reading can't provoke a huge swing — this is the gain limit.
  • Impose a cooldown after acting. Forbid the next action until a fixed interval has passed, chosen to exceed the delay before the last action's effect is observable. The loop is thereby prevented from correcting a change already in flight.
  • Bundle repeated stimuli. Coalesce a burst of triggers arriving during the cooldown into a single considered decision, rather than one reaction each — so repeated signals don't consume unbounded attention or actions.
  • Tie the cooldown to the delay, not to a round number. The quiet period is meaningful only if it outlasts the coupling's dead time; set below it, the rule does nothing.

Tuning parameters

  • Cooldown length — the central dial: longer guarantees the last action has landed before the next (killing oscillation) but slows genuine response; too short and the loop thrashes as if the rule weren't there. Set relative to the measured delay.
  • Rate cap — how many actions per window are allowed. Tighter is stabler and cheaper on attention but can throttle a legitimate sustained need.
  • Magnitude limit — the maximum size of one correction. Smaller prevents over-swing on a stale reading but takes more steps to reach a large genuine change.
  • Burst handling — drop, queue, or coalesce stimuli during the cooldown. Coalescing preserves information without acting on each; dropping is simplest but can lose a real signal.

When it helps, and when it misleads

Its strength is that it directly quells the overshoot and oscillation that delayed feedback produces, and it does so cheaply — no model, no prediction, just restraint keyed to the delay. It also protects the loop's decision-maker from being swamped by repeated stimuli, bundling a storm of triggers into one measured response.[1]

Its failure modes are the mirror of its strength: restraint is sluggishness. A cooldown that outlasts a genuine emergency delays the response the system actually needed, and an aggressive rate cap can throttle a real, sustained demand into starvation. The rule also does nothing about the delay itself — it accommodates the lag rather than shortening or compensating it, so it can entrench slowness. And a cooldown set to a comfortable round number instead of the true delay is theatre. The discipline is to size the cooldown from the measured dead time, keep an escalation path for real emergencies that the rule would otherwise mute, and pair it with delay measurement so the restraint is calibrated, not guessed.

How it implements the components

The rule fills the two restraint components:

  • response_gain_limit — capping how hard and how often the loop reacts is limiting its gain, the direct lever against delay-driven over-correction.
  • phase_or_cadence_alignment_window — the cooldown paces actions to a cadence keyed to the delay, aligning each decision to arrive after the previous one's effect rather than on top of it.

It does not measure how much delay margin the loop actually has (delay_sensitivity_assessment, system_time_constant_profile) — that's the Phase Margin or Dead-Time Test — and it does not predict the delayed effect to act correctly *now (predictive_feedforward_model), which is the Smith Predictor or Model-Predictive Compensation's approach.*

References

[1] Repeated over-correction of a delayed loop producing a persistent oscillation around the target is known in control engineering as hunting; lowering loop gain and spacing corrections are its standard remedies. ↩