Boris Cherny had two models port HAProxy from C to Rust
Both models passed nearly all of HAProxy's tests, but one got there faster and cheaper.
Boris Cherny had Claude Opus 5.5 and Claude Fable 5.1 each port HAProxy, the C load balancer, to Rust. Both passed nearly all of HAProxy's tests. Opus 5.5 finished in 9.5 hours against Fable 5.1's 12, and did it for 51% less cost.
Opus 5.5 is a really good model. It's been my daily driver the last few weeks.
The run landed alongside the announcement of Opus 5.5, which Anthropic's Claude account describes as the first model in the Claude 5.5 family, performing at the level of Claude Fable 5.1 for most tasks and costing 40% less to run than Opus 5. The HAProxy port is the shape of evidence that claim needs, one task, two models, same finish line, with wall clock and cost both reported.
It performs at the level of Claude Fable 5.1 for most tasks, and costs 40% less to run than Opus 5.
What the number actually covers
A language port is an unusually clean head to head. The target is fixed, the existing test suite is the grader, and neither model gets to negotiate the spec. That makes "passed nearly all of HAProxy's tests" a real result rather than a vibe, and it makes the 9.5 versus 12 hours comparable in a way that two different agents on two different feature requests never are.
It also leaves the interesting part unmeasured. Cherny does not say which tests failed, how large the resulting Rust is, or whether either port is code anyone would maintain. Passing a C project's tests after a translation tells you the behavior survived. It does not tell you the output is idiomatic Rust, or that the memory safety you nominally bought by moving off C is actually there rather than parked behind unsafe blocks. Nobody has published that detail yet.
For working engineers
This is one person's run on one codebase, and the person works on Claude Code, so treat it as a demo with numbers attached rather than an independent benchmark. What makes it worth more than a vendor chart is that the task is a real C program with a real test suite, and the losing model is the same vendor's previous flagship rather than a convenient competitor.
The cost line is the one to sit with. A 51% gap on a job that takes half a working day of agent time is the difference between running a port speculatively and putting it in a planning doc. If the pattern holds on other large ports, the bottleneck on a legacy migration stops being the model bill and goes back to being review capacity, which is where several engineers have already said it was.
Cherny's own summary of Opus 5.5 is less about the port than about the weeks before it.