#playwright

I downgraded my Claude subscription from $200/mo to $100/mo and started paying Cursor $60/mo instead. The trigger was Wednesday's Claude outage, but the real reason is that GLM-5.2 through Cursor has been fast enough and good enough that the math stopped favoring Opus. If a model is 80% as good as Opus 5 but roughly 7x faster, I'll take the speed and pay for the 80%.

The unscientific test

Same workspace, same CLAUDE.md/AGENTS.md, high effort on both. The prompt was "make a quick tetris game as an html file," followed immediately by "now use cyberpunk colors."

Two setups: Cursor running GLM-5.2, and Claude Code running Opus 5.

GLM finished in 53 seconds. Opus took 7 minutes 5 seconds, though a good 2-3 minutes of that was Opus testing the game with Playwright, which GLM didn't do.

The visuals came out mostly the same. Opus edged it on the blank-slate UI, which tracks with my experience. I trust Opus more when there's nothing on screen to anchor a design. The generated code was close to identical in structure.

Adding Kimi to the pile

For a third data point, Cursor with Kimi K3 on max effort: 4 minutes 3 seconds.

Visuals are fine. The code has a bug, the game doesn't auto-start, and the structure feels a step down: a big list of global variables where Opus and GLM both scoped things more tightly. Again, totally unscientific, but Kimi felt buggier and the code quality "felt" lower.

The 7x

Experiencing near-Opus quality at 7x the speed is genuinely a different thing than reading about it. The loop tightens. You ask, you get an answer, you ask again, all before you've lost the thread.

If this is what 7x feels like, I'd like to see 70x.

Coding agents that produce visual output need a way to look at what they made. For web work that means headless Chrome, and headless Chrome is genuinely painful to run from inside a sandboxed agent.

Chromium and Firefox both rely on Mach-O quirks, macOS entitlements, and Crashpad behavior that don't survive most sandboxes. I run my agents inside nono.sh profiles per project, and Chrome under that setup is a non-starter.

The workaround

Playwright runs fine outside the sandbox. So it lives on a high port and Claude is told, in its instructions, to always talk to the Playwright MCP server there:

$ npx @playwright/mcp@latest --headless --isolated --browser chrome --port 8931

The sandbox just needs to reach localhost:8931 and the visual-review loop works. Claude renders the local service, takes a screenshot, looks at it, iterates.

That mostly works. What it does not solve: stale processes, hanging Chrome instances, zombies. Every so often Chrome spins out and eats all 64 GB of RAM on my M4 MacBook Pro before I notice.

Lighter options

There has to be something simpler than babysitting a browser. Two things caught my eye recently.

Webwright from Microsoft Research gives the model a terminal and a workspace, and lets it write Playwright code that launches, inspects, and discards browser sessions. The output is a reusable script, not a chat transcript. It scores 60.1% on Odysseys against base GPT-5.4's 33.5%, which is a real jump.

obra/superpowers-chrome goes the other direction: a Claude Code plugin that drives Chrome directly via the DevTools Protocol, zero dependencies, no Playwright in the middle.

When you actually need real Chrome

Advanced bot fingerprinting is the case for keeping a full browser around. If the task is logging into a hostile site or completing a real-world flow, real Chrome with a real profile is the only thing that works.

But most of my use is smaller: render a local dev server, screenshot it, ask Claude if the layout looks right. For that, a 64 GB RAM-eating Chromium feels like the wrong shape of tool. I suspect this gets cleanly solved within a year, probably by something CDP-direct and disposable rather than a long-lived browser process I have to nanny.