DeepSeek sought & found: 4c bugfix considered a fair wage in a post- Copilot-Loophole world
4 views
Skip to first unread message
Ben Hutchison
Jun 11, 2026, 9:44:03 PMJun 11
to Melbourne Compose Group
Until a few days ago, a Microsoft Copilot subscription could be rorted to guzzle vast amounts of Claude's precious brain juice on the base copilot subscription. I had been programming with Claude Sonnet for 12 months via this method and never exhausted my quota, with Microsoft (in their benevolence, I presume) picking the Anthropic bill on my behalf.
Unfortunately, someone at MS noticed the howling of money flying out the door and closed the hatch a few days ago. Under the new billing model, my monthly quota was exhausted in the first 30 minutes.
If your $work is picking up your AI bill, you can enjoy being blissfully numb to the costs of consuming AI services. But as someone gloriously unemployed and living off my wits and dividends, minimizing AI development spend is something I care about considerably.
Losing access to Claude at a price I could afford necessitated an immediate search for a replacement. I appear to have found it in DeepSeek v4 Pro. This thing groks functional Scala like a boss. And demonstrates strong reasoning capability, tracing subtle bugs that would defeat senior engineers, by static reasoning alone.
Today DeepSeek tracked down a subtle race condition bug in about 10 minutes, for US$0.04 total cost. Previously, Claude Sonnet 4.6 had spun wheels on this issue for 10 minutes until it exhausted my quota, although I expect Claude would have solved it eventually, too.
To give you a sense of the level, here's its final writeup:
Analysis: Self-Cancellation Race in OperationRunner
Root Cause
The bug is a self-cancellation race. Here's the exact chain:
User clicks "Create Module" submit button
The onClick handler fires doSubmit in a background fiber that's allocated within the form component's resource scope (via listenEventStream → .compile.drain.background)
doSubmit → onSubmit(args) in OperationRunner:
runningRef.set(Some(Running)) ← this triggers the signal change
execute(args).attempt.flatMap(...) ← starts execution
runningRef changes None → Some(Running) → dynKeyChildren key changes [false] → [true]
KeyedReconciler swaps children: unmounts the form, mounts the outcome component
Unmounting the form releases its resource scope, which cancels the click handler's background fiber — the very same fiber still running onSubmit!
Cats Effect handles fiber cancellation internally — CancellationException is not caught by .attempt
runningRef.set(Some(Success(...))) never runs → outcome stays "Running…" forever
repoRef.set(newRepo) may not run → module never appears in the list
I am going to experiment with DeepSeek with a PAYG API-key approach for a while. I'm not yet convinced it has Claude's elusive "good design taste", but a strong mechanical understanding of how concurrent, functional Scala works is a solid foundation.
-Ben
Unfortunately, someone at MS noticed the howling of money flying out the door and closed the hatch a few days ago. Under the new billing model, my monthly quota was exhausted in the first 30 minutes.
If your $work is picking up your AI bill, you can enjoy being blissfully numb to the costs of consuming AI services. But as someone gloriously unemployed and living off my wits and dividends, minimizing AI development spend is something I care about considerably.
Losing access to Claude at a price I could afford necessitated an immediate search for a replacement. I appear to have found it in DeepSeek v4 Pro. This thing groks functional Scala like a boss. And demonstrates strong reasoning capability, tracing subtle bugs that would defeat senior engineers, by static reasoning alone.
Today DeepSeek tracked down a subtle race condition bug in about 10 minutes, for US$0.04 total cost. Previously, Claude Sonnet 4.6 had spun wheels on this issue for 10 minutes until it exhausted my quota, although I expect Claude would have solved it eventually, too.
To give you a sense of the level, here's its final writeup:
Analysis: Self-Cancellation Race in OperationRunner
Root Cause
The bug is a self-cancellation race. Here's the exact chain:
User clicks "Create Module" submit button
The onClick handler fires doSubmit in a background fiber that's allocated within the form component's resource scope (via listenEventStream → .compile.drain.background)
doSubmit → onSubmit(args) in OperationRunner:
runningRef.set(Some(Running)) ← this triggers the signal change
execute(args).attempt.flatMap(...) ← starts execution
runningRef changes None → Some(Running) → dynKeyChildren key changes [false] → [true]
KeyedReconciler swaps children: unmounts the form, mounts the outcome component
Unmounting the form releases its resource scope, which cancels the click handler's background fiber — the very same fiber still running onSubmit!
Cats Effect handles fiber cancellation internally — CancellationException is not caught by .attempt
runningRef.set(Some(Success(...))) never runs → outcome stays "Running…" forever
repoRef.set(newRepo) may not run → module never appears in the list
I am going to experiment with DeepSeek with a PAYG API-key approach for a while. I'm not yet convinced it has Claude's elusive "good design taste", but a strong mechanical understanding of how concurrent, functional Scala works is a solid foundation.
-Ben
Reply all
Reply to author
Forward
0 new messages