Four Commit Messages at the Reviewer’s Terminal

Four Commit Messages at the Reviewer’s Terminal

A commit message is a tiny handoff to the next person debugging your code. Usually, that person is you, three weeks later, staring at git log between two failing test runs. For this comparison, the reviewer’s question is simple: which message explains the change without inventing a larger story?

This is an illustrative four-model review exercise, not a measured benchmark. The messages below are authored examples, not recorded model responses. Two lanes use shelf models as concrete configuration examples: Claude Sonnet 5.5 and GPT-6.1 Sol. The remaining lanes stay anonymous. The verdict ranks these drafts, not the underlying models.

The Staged Diff: Retry Only HTTP 429 Responses

Imagine a TypeScript API client whose request helper currently retries every failed HTTP response. The staged patch changes that behavior: retry only HTTP 429 responses, allow at most three total attempts, and wait 500 milliseconds between attempts. Other HTTP failures return immediately. Tests cover a successful retry, exhausted attempts, and a non-retryable 401.

That boundary matters. The patch does not add exponential backoff, inspect Retry-After headers, or make requests idempotent. A reviewer should reject any message that quietly promises those features.

Each lane gets the same staged diff, the same instruction, and no repository history: “Write a commit subject under 72 characters and a short body. Explain the behavior change using only evidence in the diff. Do not claim performance improvements or broader reliability guarantees.”

Four Drafts Beside the Same Diff

• Lane A, configured for Claude Sonnet 5.5, illustrates a broad draft: “Improve API retry handling.” Its body mentions transient failures and better resilience, but leaves the retry boundary unclear.
• Lane B, configured for GPT-6.1 Sol, illustrates a precise draft: “Retry HTTP 429 responses up to three total attempts.” Its body states the fixed delay and immediate return for other failures.
• Lane C, an anonymous comparison lane, illustrates an inflated draft: “Add exponential backoff for rate-limited requests.” Its body also claims Retry-After support, which the patch does not contain.
• Lane D, another anonymous comparison lane, illustrates a terse draft: “Fix retries.” Its body lists the added tests without explaining what changed for callers.

These are deliberately different failure modes. Lane A sounds reasonable while hiding the important condition. Lane C sounds technical while being wrong. Lane D avoids false claims but makes the reviewer reconstruct the behavior from the diff.

The Reviewer’s Verdict: Lane B Wins This Exercise

Lane B wins because it preserves the operational boundary. It names the status code, describes the attempt limit unambiguously, and leaves unsupported capabilities out. “Three total attempts” is especially useful: “three retries” would imply four attempts, including the original request.

Lane A needs a rewrite, not a few extra adjectives. “Better resilience” is an interpretation; “only retries HTTP 429” is observable behavior. Lane D is accurate but incomplete. Lane C fails outright because a confident description of nonexistent behavior is worse than an unhelpful subject.

The ranking is B, A, D, C. That is a verdict on the submitted text. Establishing a model winner would require actual runs across multiple diffs, repeated samples, and blinded review.

A Repeatable Review Loop Through Fluxo

In practice, I would save git diff --cached once and feed that exact snapshot to every candidate. Keep the prompt and output limit fixed, record each model identifier, then hide those identifiers before scoring. Judge factual accuracy first, useful context second, and style last.

Fluxo makes that switching workflow less fiddly: one key and one base URL, https://api.fluxorelay.com, provide access to its model shelf. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. Billing follows real tokens, including cache reads and writes, with no monthly fee, so repeated comparisons still need a token budget.

If you want to repeat this exercise on your own staged changes, you can create a Fluxo account. Users also earn a referral share when people they invite pay; that arrangement should stay separate from any reviewer scorecard.

The practical takeaway is small: choose the message that tells the truth about the diff. Keep the model label out of the decision until the review is finished.