Qwen 3.8 27b is a amazing model, for the first time I see a local model found its own away to open a browser and test

I was testing this quantization IQ3_XXS from GSQ-RCO with PI. It is a heavy quantization case, the model is in IQ3_XXS and KV cache in (Q4_0, Q4_0). I asked it to make the flight simulator, using that popular prompt. For my surprise, when I went verify the session I saw some screenshots, but I don't have mcp or tools in the PI, it's an almost clean installation, only with some personal skills that dont have any mentions to browser testing. Investigating the session I have noted that it found its way to open a browser for test by itself. My daily harness is opencode, and for not spending the 7k tokens with the chrome mcp in each session, I let the mcp disabled and I only enable it if the session needs. But this experience make think that I probably only need line in the agents md saying that he can use the headless browser with CDP when it needs. https://preview.redd.it/wrgltip9rzph1.png?width=1952&format=png&auto=webp&s=0e54503c12b91ecdb622ae6c99dc359cc1d7cb1f OK, let me write the file. Also test: I can't easily run a browser here. But I can at least do a syntax check of the JS via node (extract the script? maybe parse with node --check). ---------------------- Now, final verification: run node --check again, and additionally do a simple DOM-less smoke test? Can't run three.js without a browser. Syntax check + math tests are enough. Could also try opening it in a headless browser if available? Check whether the machine has headless Chrome or playwright? That might be overkill; but if I could do an actual rendering check, I could catch runtime errors (e.g., shader compilation). Let me check whether headless Chrome is available. $ cd /tmp && awk '/<script type="module">/{f=1;next} /<\/script>/{f=0} f' /Users/[...]/zeroshot/Qwen3.8-27B-UD-IQ3_XXS_GSQ-RCO-pi-xhigh/index.html > sim.mjs && node --check sim.mjs && echo "SYNTAX OK" SYNTAX OK Took 0.1s $ ls /Applications/ | grep -i -E 'chrome|chromium' ; which chromium chrome google-chrome 2>/dev/null; ls ~/Library/Caches/ms-playwright 2>/dev/null | head ... (5 earlier lines, ctrl+o to expand) ffmpeg-1011 firefox-1532 firefox-1538 webkit-2311 webkit-2336 Took 0.0s Chrome is available, and playwright's chromium headless shell is also available. Let's do a headless smoke test: load the page, wait a few seconds, and capture console errors and screenshots. The page loads three.js from a CDN — the network needs to be working. Let's use playwright's chromium (does npx playwright exist? The fact that the ms-playwright cache exists means playwright is installed somewhere). Let me check if the playwright npm package is available globally, or use chrome directly with --headless. The simplest approach: use Chrome headless directly: /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --headless --disable-gpu --screenshot=/tmp/shot.png --window-size=1600,900 --virtual-time-budget=8000 file://... However, WebGL in headless Chrome: it works with SwiftShader (software GL) via --use-gl=swiftshader or --enable-unsafe-swiftshader. In newer versions of Chrome, the software fallback requires --enable-unsafe-swiftshader. Let's try it. Also, console errors: --enable-logging=stderr --v=1 will give us the console. Let me write a small node script using playwright if available. First, check the availability of node playwright. Chrome is available — let me do a headless smoke test to catch runtime/shader errors and grab a screenshot: $ node -e "try{require.resolve('playwright');console.log('playwright OK')}catch(e){console.log('no playwright')}"; ls ~/Library/Caches/ms-playwright/chromium-1234/ 2>/dev/null | head -3 no playwright chrome-mac-arm64 DEPENDENCIES_VALIDATED INSTALLATION_COMPLETE Took 0.1s There's no playwright module, but the Chromium headless shell exists. Either find the path to the headless shell binary and run it directly, or use Google Chrome in headless mode with SwiftShader. The path for Playwright's Chromium headless shell: ~/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-mac-arm64/chrome-headless-shell? Let me check the structure. $ find ~/Library/Caches/ms-playwright/chromium_headless_shell-1234 -name '*headless*' -o -name 'chrome*' | head; find ~/Library/Caches/ms-playwright/chromium-1234 -name 'Chromium' -o -name 'chrome' | head ... (3 earlier lines, ctrl+o to expand) s.pak /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/chrome-headless-shell /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/headless_lib_strings.pak /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/headless_lib_data.pak /Users/[...]/Library/Caches/ms-playwright/chromium_headless_shell-1234/chrome-headless-shell-mac-arm64/LICENSE.headless_shell Took 0.1s Use chrome-headless-shell — but to catch console errors and drive key input, we need CDP (Chrome DevTools Protocol). chrome-headless-shell supports --remote-debugging-port. I could also write a small Node script that speaks raw CDP over WebSocket... but that would need a ws client. Node doesn't have a built-in WebSocket client until Node 22+ (Node 22+ has a global WebSocket). What version of Node is it? Let me check. Node 24 (from the nvm path v24.21.0) — a global WebSocket exists. Plan: 1. Launch chrome-headless-shell with --remote-debugging-port=9222, --no-sandbox, --use-gl=swiftshader? For headless shell, WebGL via SwiftShader: --enable-unsafe-swiftshader flag; also --no-sandbox is needed? For headless shell, maybe --no-sandbox isn't necessary, but I'll add it just in case. Also, a new profile directory with --user-data-dir=/tmp/cdp-profile. 2. Node script: fetch http://127.0.0.1:9222/json/new?url=file:///... (PUT) to create a tab, connect via WebSocket to webSocketDebuggerUrl, and do the following: - Enable Runtime and Log - Collect console messages and exceptions - Wait about 6 seconds (let the first frame render) - Dispatch key events? Simulating keydown via CDP: Input.dispatchKeyEvent. Possible, but keyboard isn't required for the smoke test. - Page.captureScreenshot → save to PNG - Also, evaluate expressions: get the chunk count, and confirm the renderer is working? For example document.querySelectorAll('canvas').length, window.__stats... I haven't exposed the stats. I can evaluate JS in the page context: the module's scope isn't global, but I can check document.getElementById('alt').textContent (the HUD should show altitude after 0.12 seconds), and check the canvas pixel colors via toDataURL? Easier: check the HUD text + screenshot. 3. Report console errors. Let me write this script. I'll drive the headless shell over CDP with Node's built-in WebSocket to capture console errors and a screenshot: ------------ > why did you used a browser? did you already had any instruction about it? User's question: "Why did you use a browser? Was there any prior instruction to do so?" Honest answer: there was no prior instruction to use a browser. What I chose on my own was: 1. To do syntax checking with node --check (low cost, so I did that first). 2. Since a single HTML file with WebGL + CDN can't be fully verified without actually rendering it, I used a locally available headless Chrome (I found Google Chrome and Playwright's chromium headless shell on the machine). It's to catch runtime errors (shader compilation, WebGL failures, logic errors like the inverted bank direction), and to take screenshots as visual evidence. There's no instruction in AGENTS.md or in the skills that requires using a browser. There's nothing in the skill list that mandates it either (the qa-manual-guide skill is about writing a guide, and I didn't use it since it wasn't explicitly requested… actually, this skill says "when an implemented feature needs an evidence-based local manual testing guide…" — what the user asked for was a simulator, not a manual testing guide. My verification was a homegrown approach). Why I used it: a single-file browser game can't be verified with unit tests alone. Headless rendering would let me detect actual failures (e.g., I actually found an inverted A/D bank bug that a syntax check could never find), and screenshots let me verify the visual quality (mountain appearance, sun position, cloud scale) — the "beautiful and relaxing" requirement is inherently visual. I should answer concisely and honestly: no, there was no instruction. I discovered the browser on the machine and used it for evidence-based verification. The main findings were the inverted turn bug and visual confirmation. Also note that it was only used for testing and didn't modify any files inside the project. Keep the reply short and structured. No — there was no instruction to use a browser. That was my own choice for verification, not from AGENTS.md or any skill. Why I did it: - A single-HTML-file WebGL game can't be properly validated by syntax checks alone — the interesting failures (shader compile errors, WebGL context issues, sign errors in the flight math) only surface when it actually runs. - I noticed Google Chrome and Playwright headless Chromium were available locally, so I drove a headless shell over CDP: load the page, capture console/exception logs, simulate key presses, read the HUD values, and take screenshots.