Two passes over a shared retry wrapper

Who is on the listEN2026-10-30

A shared retry wrapper is a useful place to compare Claude Opus 5.5 and Claude Sonnet 5.5. The change looks small: replace duplicated retry loops in three API clients with one helper. The difficulty is preserving the differences that matter, including cancellation, attempt counting, and which failures may safely trigger another request.

This notebook entry describes a controlled comparison, not a measured benchmark. Without recorded runs, there is no basis for declaring either model faster, cheaper, or more reliable on this task. The useful comparison starts with the same repository state and ends with patches a maintainer can inspect.

§ The same starting point

Give each model a fresh checkout at the same commit. Use identical instructions, tool permissions, tests, and acceptance criteria. Keep the execution environment fixed and record any differences in reasoning settings or context limits. Do not let the second run see the first patch.

The task should be narrow: extract shared retry mechanics without changing public interfaces or observable behavior. Specify that existing timeout and cancellation semantics must remain intact. Ask for tests covering the extraction and a short explanation of any behavior the model cannot confidently establish.

Claude Opus 5.5: Work independently from the baseline, with access to the relevant clients and their tests.
Claude Sonnet 5.5: Use the same baseline and access, without additional hints supplied after inspecting the other patch.

If clarification becomes necessary, record it. A helpful human intervention is part of the cost of producing the patch, even when it does not appear on the token bill.

§ Compare the abstraction, not its polish

For both patches, inspect what the helper owns. Delay calculation and attempt counting may belong together. Deciding whether a request is safe to repeat may need to stay with the caller. A compact helper that silently retries a non-idempotent operation is not an improvement.

Claude Opus 5.5: Check whether any broader abstraction is justified by the existing clients. Additional configuration needs an actual caller, not a possible future use.
Claude Sonnet 5.5: Apply the same standard. Check whether a smaller extraction genuinely preserves behavior rather than leaving important inconsistencies hidden in callbacks.

These are review questions, not predictions about either model. Grade the resulting code without rewarding a particular style in advance. Both over-generalization and excessive duplication can increase maintenance work.

§ Read the tests beside the patch

Run the existing suite before and after each refactor. Then inspect the new tests for boundaries: no retry after cancellation, no delay after the final attempt, and no extra request when the retry budget is exhausted. Confirm whether the original code counts attempts or retries; those conventions differ by one request.

Apply the same checklist to both outputs. Test volume is a weak signal if every case exercises the happy path. Where practical, use fake timers and deterministic failure sequences so a passing test demonstrates behavior rather than favorable timing.

Also read each model’s final explanation against the diff. A claim that cancellation is preserved should point to code or tests that support it. Uncertainty stated clearly is more useful than an unsupported assurance.

§ Count the work after generation

Record elapsed time, token usage, failed test runs, clarification turns, and reviewer corrections separately for each run. Do not reduce the comparison to response length or the time until the first patch appears. A quick draft that requires substantial repair can take longer to merge.

Vana API can provide a common access layer for this exercise. Its endpoint at https://api.vanaapi.com is OpenAI-compatible and also supports the Anthropic Messages and Gemini native protocols. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs. Billing is per real token with no monthly fee, making recorded usage a practical input to the comparison. Create an account to run the two trials through one service.

§ A decision limited to this refactor

Prefer the patch that preserves behavior, exposes fewer unnecessary concepts, and needs less reviewer correction. If the results are close, repeat the exercise on another representative change before adopting a default. One retry-wrapper refactor can inform a workflow choice; it cannot establish a universal model ranking.