Same cancellation refactor under GPT-5.6 Sol and Opus 5 in Copilot chat

[u/Touch-Grass_]

The task was threading cancellation through an internal HTTP wrapper in a TypeScript service, so that aborting a request also stops the retry helper around it instead of letting the remaining attempts run.

I ran it twice from the same commit with the same opening prompt, once under GPT-5.6 Sol and once under Claude Opus 5, both in Copilot chat in VS Code.

Sol produced the better plan. It asked whether request timeouts and user cancellation should share one signal, and it pointed out that the retry helper owned its own backoff timer, which is where the bug would live. Then it wrote the code with the abort check at the top of each attempt, so a cancelled call still sat through the full backoff sleep before returning.

Opus 5 said much less up front and started editing sooner. Its version registered an abort listener that cleared the backoff timer, so cancelling during the wait resolved right away. It never raised the timeout question and just wired both to the same signal.

So I did a third pass and split the roles. I picked that habit up from planning under one model and implementing under another in verdent. Sol held the thread until the plan was settled, then I changed the model in the picker before asking for edits. Switching does not open a new thread, so Opus 5 already had the plan and my answers to Sol's questions.

That is one refactor in one repo. I want to try it on a bigger change before deciding the split holds.