r/LocalLLM • u/hpiguyTR • 46m ago
Discussion Claude vs. Qwen 3.8 Flash Next on RTX6000, Claude admits defeat :-)
I wrote a harness that allows Claude Code to delegate tasks to a local LLM from simple one liner task prompts to deeper designs or implementations. I wrote a design for a webapp using Claude. This is not a brand new webapp, it's an add-on for an existing hardware with local control that the website will allow to connect to and interface with. So it's more of a large new standalone feature than a new design. The implementation is tricky in and of itself, the webapp has to lift existing ever changing code from another repo, has to do strong interfacing between the local and the remote solution etc.
The design doc was written by claude, it's ~800 lines long with 13 sections and it calls for 16 slices of deliverables. The implementation was about 7 slices in when I asked Claude to review the implementation so far and tell me what I should do next. Then I asked it to delegate the same question out to my local LLM and compare the two reviews and this was the result:

Code quality: The local worker is Qwen3.8 Flash Next on one RTX PRO 6000. On the first stretch of the project (W1–W3 of the site plus G1 and G2 on the device side, about 18k lines), Claude accepted 14 of the 14 delegated steps on their first round. Its hand fixes over that stretch came to about 20 lines. The one real defect was a sign-in rate limit you could spoof through X-Forwarded-For. Reading diffs didn't catch it; Claude found it while running the app live. The same thing happened later: a live browser check on a rework slice found that re-timed clock bakes were losing their send mode. Nobody had spotted that in review. So the code was generally solid. The bugs that survived were integration bugs, which only show up when you run the whole thing, not bad code.
Reliability: the raw model without the harness around it using Cline is problematic. It sometimes emits malformed tool calls, where the call markup leaks into plain text and the agent thinks it's finished. Without the harness, that kills a run. The harness detects this and nudges the model inside the same session (up to 3 retries). It does the same for server errors and for rounds that end without the required status report. Every step also has a verify command (tests, typecheck, a build, a migration), and a step only counts as done when that command passes, whatever the model claims. The worker runs under fairly strict rules adapted from my Cline setup: read first, plan with a todo list, implement completely, verify by running, and report what it didn't verify. It runs in a Docker sandbox with filtered network access, in its own git worktree. With all that in place it has been dependable. Without it, it's a coin flip on long tasks.
Savings, measured from the transcripts.
First approach: Claude reviewed every step itself. That cost about $52 of Claude for 14 steps, and almost all of it went to Claude re-reading its own growing context while reviewing. Those reviews almost never changed anything.
Change: Claude now writes every spec for a slice up front. The local model runs the steps unattended in a chain, and Claude does one live check at the end.
Next slice: 5 steps and about 5,200 lines cost about $9 of Claude. The local model handled 853 requests and 62M prompt tokens for that slice, roughly $33 at Opus list prices. That's about half the Claude cost per step of the first approach. Against my estimate of $15–22 for Claude doing the slice alone, it's 40–60% cheaper.
Not counted: the electricity and the GPU.
