Classic Multi-Paxos funnels every decision through a stable leader. That's simple to reason about, but it makes the leader the bottleneck: every client request pays a round-trip to the leader before consensus even begins. Cooperative Paxos lets followers do useful work on the leader's behalf — accepting proposals, forwarding batches, or pre-voting on values — so the leader spends its bandwidth on committing, not on shepherding.

The core idea: replace the strict "leader proposes, followers accept" flow with a delegated one. Followers close to clients accept writes into a local staging log, forward batched proposals to the leader with a pre-computed ballot number, and the leader only needs to run the Accept phase against the remaining quorum. The Prepare phase is amortized across many values (like Multi-Paxos), and the leader's per-request work drops from "handle N clients" to "commit N batches."

Concrete example: A distributed KV store with 5 nodes across 3 regions. Leader is in us-east. A client in eu-west writes a key. In classic Multi-Paxos: client → eu-west follower → us-east leader (80ms) → quorum accept (80ms) → ack (80ms) = 240ms. In Cooperative Paxos: eu-west follower accepts locally, batches with 20 nearby writes, forwards to leader with pre-assigned slot numbers. Leader runs one Accept phase for the whole batch (80ms) and acks. Per-write latency drops to ~120ms amortized, and leader CPU drops proportionally to batch size.

Rule of thumb: Cooperative Paxos pays off when your leader is CPU-bound or when clients are geographically far from the leader. If your leader sits idle at 10% CPU and clients are co-located, the added protocol complexity buys you nothing — stick with Multi-Paxos.

The tradeoffs are real:

• Ballot ordering gets harder. Followers pre-assigning slot numbers means you need a coordination mechanism (usually a leader-issued lease of slot ranges) or you'll get conflicts that force expensive re-proposals.
• Failure modes multiply. If a follower crashes mid-batch, the leader must reconcile which slots were durably staged versus lost. This usually requires a per-follower recovery log.
• Correctness proofs are subtler. Any deviation from Lamport's original protocol needs a formal argument that safety holds. Bugs here don't manifest as errors — they manifest as split-brain.

When to reach for it: Geo-distributed consensus, write-heavy workloads where the leader is the bottleneck, or systems where clients demand low write latency and can tolerate slightly weaker read-your-writes guarantees during handoff. For everything else, Multi-Paxos or Raft is the right default.