Beat Paxos

As I mentioned in my previous blog post, I recently got my hands on Claude Code. In the morning, I used it to build a Hybrid Logical Clocks (HLC) visualizer. That evening, I couldn't pull myself away and decided to model something more ambitious. 

I prompted Claude Code to design a Paxos tutorial game, BeatPaxos, where the player tries to "beat" the Paxos algorithm by killing one node at a time and slowing nodes down. Spoiler alert: you cannot violate Paxos safety (agreement). The best you can do is delay the decision by inducing a series of well-timed failures, and that is how you increase your score.

Thinking of the game idea and semantics was my contribution, but the screen design and animations were mostly Claude’s. I do claim credit for the "red, green, blue" theme for the nodes and the colored messages; those worked well for visualization. I also specified that double-clicking a node kills it, and that the player cannot kill another node until they double-click to recover the down node. I also instructed that the player can click and hold a node to slow its replies. These two captures the standard distributed consensus fault model; no Byzantine behavior is allowed, as that is a different problem and algorithm. I include my full prompt at the end of the post.

I was surprised Claude got this mostly right in one shot. Most importantly, it got the safety-critical part of the implementation right on the first try, which is no small feat. I used the Opus model this time because I wanted the extra firepower.

Here is the game, live, for you to try.

What needed fixing

There were timing issues again. The animation progressed too quickly for the player to follow, so I asked it to slow down. But more serious problems emerged, especially around the leader timeout.

The leader timeout felt wrong. I was seeing dueling leaders even in fault-free runs. After some back and forth, I found a deeper issue: even a single leader could timeout on itself, start a new ballot, and end up dueling itself. This was clearly a bug in the timeout logic. After I pointed it out, Claude fixed it, and things were good.

My red, blue, green idea was a good design choice, but Claude did not follow my intent. It colored any message sent by blue as blue, even when it was a response to a green leader. I reminded Claude that messages should be colored by the ballot leader’s color to clearly show how different ballots interleave, and this was sufficient to fix the issue.

Takeaway

This was a lot of fun, again. I feel like a kid in a candy store. It’s now trivial to build great learning tools with Claude Code. As I mentioned in my previous post, people need hands-on, interactive learning, not static figures. They need to play with algorithms, explore corner cases, and see how they behave.

A LinkedIn follower, after seeing BeatPaxos, prompted his Claude Code to translate it to Raft. The result is BeatRaft: same logic, but with Raft messages. Check it out if that’s more your vibe.

Here is the original prompt as I promised. 

let's design a paxos tutorial game, maybe we name it BeatPaxos, because the player will try to make the Paxos algorithm violate safety, spoiler alert it is not possible to.

There will be three columns, to denote N=3 nodes, let's call them red, green, blue, and we can then use the consistent color theme in the messages they send. The current leader may have a crown image on top of its box.

The single synod Paxos protocol will be implemented: p1a, p1b, p2a, p2b, p3 messages. if there is nothing learned in p1, red would want to propose red, blue would propose blue, and green would propose green. But of course the implementation follows the Paxos protocol.

The player will be given only a set of actions. It can kill one node a time, by double clicking on it. if a node is down, then doubleclicking on another node does not work. but double clicking on the down node recovers it.

The red, green, blue nodes are rounded-corner rectangular boxes in respective color. When a node gets to p2, it gets a crown, denoting it thinks it is the leader. So there can be two nodes with crown, it is possible under Paxos rules. Only one would have the highest ballot number. We can display the ballot number of a leader in its box. When a node has to return to p1, it loses the crown.

for the visualization layout I am thinking of these three lanes, lined up below red, green, blue, it just lists the messages it sent. For red, this could be p1a (ballotnum) to blue, p1a (ballotnum) to green, p2a ("red", ballotnum) to blue, p2a ("red", ballotnum) to green and blue may have p1b (ballotnum, [val]) to red etc.

The player can also click-and-hold on a node, to make that node slow to send its next message. Otherwise, messages scheduled according to Paxos, goes 5sec interval from each other.

If the leader node is down, or the player delays it by click-holding it, then a random timeout may make another node propose its candidacy by sending a p1 message.

The right pane may give the player the rules, and add some explanation about the protocol. And display the safety invariant and its evaluation on the current state. If the player manages to violate the safety invariant, player wins! 

You can program this app on javascript on single page again, so I can deploy on Github Pages.