Skip to content

Vibe Log #4: The difference between high, xhigh, and max reasoning

I realized after debugging django with qwen3.6 the other day that I was running Qwen3.6 on "high" effort. Just high effort. Out of context this might seem appropriate. But Opus4.7 runs almost permanently on xhigh effort.

I have no idea what this actually means in practice, but this deceptively simple frontend bug was the perfect excuse to try them out.

❯ Submitting an empty URL in /extract results in a 400 error appearing. Fix this workflow so that it displays a more appropriate validation error instead.

Extract 400 error on empty URL

One might say this is the expected outcome of submitting an empty URL. I agree. Still, it would be mighty kind of Diffy to offer some appropriate advice rather than dead end on a 400 error.

Wiring up a little isempty check is simple enough for most local models. Here's qwen3.6:35b's solution on high reasoning effort.

javascript
+        // Validate URL is not empty
+        if (!this.extractForm.url || !this.extractForm.url.trim()) {
+          this.extractForm.error = 'Please enter a URL.'
+          this.extractForm.isDisabled = false
+          return
+        }
TOKEN USAGE
  input tokens  122,376
  cached tokens 0
  output tokens 1,375

This looks alright, except that the progress bar now advances forever.

New conversation. Same original prompt. Same Qwen3.6:35b, now on xhigh reasoning.

javascript
+        // Check for empty URL
+        if (!this.extractForm.url.trim()) {
+          this.extractForm.error = 'Please enter a URL to extract.'
+          this.extractForm.errorHelp = ''
+          this.extractForm.isDisabled = false;
+          progressBar('start')
+          setTimeout(() => progressBar('stop'), 500)
+          this.toggleTab('testdriveResultsVisual')
+          return
+        }
TOKEN USAGE
  input tokens  156,700
  cached tokens 0
  output tokens 2,541

xhigh addresses the progress bar and form reset, but it failed to recognize that progressBar was already instanced earlier and progressBar('stop', 500) does not kill the original instance.

javascript
// Start the Progress Bar
var resultsLoader = progressBar('start');

It took max reasoning for Qwen3.6 to finally produce an acceptable solution.

javascript
+        // Check for empty URL
+        if (!this.extractForm.url || !this.extractForm.url.trim()) {
+          this.extractForm.error = 'Please enter a URL to extract.'
+          this.extractForm.isDisabled = false;
+          this.toggleTab('testdriveResultsVisual')
+          progressBar('stop', resultsLoader);
+          return
+        }
TOKEN USAGE
  input tokens  452,232
  cached tokens 428,401 [94%]
  output tokens 4,003

Note the cached tokens. Qwen3.6 hurt itself in its confusion, ending its turn before writing the code. A second turn triggered by "continue" got it to through the finish line.

Trying Qwen3.6 a second time on max net the same acceptable solution without the need for a second "continue" turn. So that might just be a one time fluke.

I could see max reasoning overwhelming Qwen3.6 again, but telling it to "continue" is a lot easier than debugging its code.

Notes

  • I switched from Claude Code to Forge for this exercise. I intend to run a bit more of a 1:1 comparison between the two. General vibes so far seems to be slightly less tokens consumed on Forge.

See you in Vibe Log #5!