I wrote one prompt for GLM 5.3-flash (Ox Alpha). This is what shipped.

For about a week there was a model on OpenRouter called Ox Alpha. No lab attached, free while it lasted, and the usual thing happened: people posted screenshots, argued about whether the benchmarks meant anything, and waited for the reveal. It turned out to be GLM 5.3-flash.

Free and unnamed is a good combination for a test I had been putting off. I do not use OpenCode. I wanted to know whether I could write a plan precise enough that a single execution prompt would carry it to a deployed site.

That is a different question from whether the model is any good. Most of my time on agent work goes into the gap between what I meant and what I wrote down. If the plan closes that gap, the time disappears, and whatever is left over is the part no plan can carry. I wanted to see the shape of what was left.

The plan is the work

It ran 1,153 lines, and writing it took longer than the build.

The rule I held to was that every number in it had to be measured rather than preferred, and every decision had to arrive with its reason attached, because a reason survives into the code where an instruction alone does not. A few lines look absurd out of context:

• Prices arrive per instance, per node, in cents, or per GPU. Never trust a source's own per-GPU field.
• One historical dataset flags 38,620 of 46,589 rows as CPU-only. Without that filter the median is zero.
• Skip unknown hardware names. Never guess one. A mapper that guesses corrupts a series; one that skips leaves a gap that is visibly a gap.

None of that is knowledge about GPUs. It is knowledge about the specific ways four specific price feeds are wrong, and it came out of a research phase that ran before a line of the plan was written. The plan opens with that instruction to itself: look first, then plan, assume nothing.

The other thing the plan front-loads is the decisions that cannot be retrofitted. Whether the app renders on the server or in the browser sets the ceiling on its Lighthouse score, and you cannot move it later without rewriting the shell. Lint rules only bite if generated code is excluded from the first commit rather than the fortieth. Both went in at the top, as constraints, not as closing tasks.

The prompt did not work alone

One execution prompt does not mean one worker. It delegated, and the delegation left a paper trail: fifteen investigations came back as written reports, across thirteen domains. A TanStack review against the framework's own best practices, a performance report, an animation pass, an end-to-end audit, a design-engineering audit, a search and answer-engine review, a deploy report, a prerendering finding, three separate reports on crawler data quality, and two production-readiness audits.

Seven named skills set the review standard, five of them motion and design-engineering rulebooks: emil-design-engineering, animation-performance, animation-accessibility, web-animation-design and transitions-polish, plus grill-me for interrogating the brief before it was written and improve-animations for the audit pass over what came out.

Naming them is the part that does work. "Make the animations nicer" is an opinion, and an agent can agree with it and change nothing. "Every animation ships two variants and reduced motion is one of them" either holds in the diff or it does not. An audit against a named rulebook is a read-only pass with a pass or fail per rule, which is why the design-engineering audit is a document rather than a conversation.

The other rule was that the reviewer was never the agent that wrote the code.

What came out

Three days and a site that runs: cmpinf.com, a daily median price index for GPU rental, LLM tokens and wholesale electricity. Around 29,000 lines of source across 57 commits, 110 unit tests, 43 end-to-end tests in 8 suites, 12 routes, three Cloudflare Workers.

I counted rather than trusted, which took a second pass on the end-to-end number. Only 31 tests are written out. The other twelve are generated in a loop over the route list, so the suite reports 43 and the file shows 31, and both are correct.

Lighthouse on the deployed site, three runs, median:

performance 100   accessibility 100   best-practices 100   seo 92
LCP 589ms         TBT 0ms             CLS 0.002

The eight missing SEO points are Cloudflare writing a Content-Signal line into robots.txt, which Lighthouse does not recognise and reports as an error. Those signals are a reservation of rights under Article 4 of the EU copyright directive. They are worth more than eight points, so they stay.

One thing did interrupt the run, and it was not the plan. A free preview model with that much attention on it times out, so a few times I came back and told it to keep going. That is a transport failure, not a brief failure, and it is worth counting separately or you cannot tell which one you are looking at.

What a plan cannot reach

Here is the part I actually wanted. Everything the plan did not cover had one thing in common: it is only visible once the thing is deployed.

The clearest case is a preload optimisation. The document preloads the four API calls the landing page makes, so they leave with the HTML instead of after the bundle has parsed. Those hints carried crossorigin only when the API sat on a different origin, on the reasoning that a same-origin fetch sends credentials an anonymous preload entry would not match.

That reasoning is wrong, and worse, it was untestable where it was written. In development the API runs on its own port, so the conditional always took the cross-origin branch and the end-to-end test passed. On the deployed site the API is same-origin, all four hints reported "preloaded but not used", and the whole optimisation was inert while looking like it worked. Fixing it took LCP from 600 ms to 464 ms.

No plan could have specified that. It is not a missing requirement. It is a fact about the difference between two environments, and it does not exist until both environments do.

Three more of the same kind, all found by driving the deployed site rather than by reading the code:

1. The linter was checking a file Playwright writes after every run, so linting went red on output no human had produced.
2. Playwright's default worker count killed the dev proxy. Eight workers on a sixteen-core machine took it down in three runs out of three, response times climbing from 60 ms to 890 ms before every later request was refused. The suite had been reporting a machine limit as a product failure.
3. The browser suite declared no dependency on the app it tests, so its cache key never included the frontend. Editing a component and running the tests printed a pass without executing anything. It went green on a broken chart and on the fix for that chart alike.

That last one is the one to be frightened of. It is why I now treat a gate I have never seen fail as untested, a rule I arrived at the expensive way and wrote about in the post about moving from writing code to checking it.

What I would tell someone trying this

Put the irreversible decisions at the top of the plan, not at the end. Rendering model, lint scope and anything touching money or accounts all set constraints that everything else is then built against, and none of them can be added afterwards without tearing something up.

Then accept that a plan closes exactly one gap: the one between what you meant and what you wrote. It closes none of the gap between your machine and production. Budget for the second one instead of being surprised by it.

Next

The same plan has been rewritten with everything this run turned up, and pointed at a different product. There are no commits on it yet, so there is nothing honest to report until it has run.

If you try this yourself, the number I would ask you for is not the model's score on anything. It is your own count: how many of your follow-up messages were the plan failing, and how many were something you could only have learned by deploying. If the second number is the larger one, your plan is doing its job and your staging environment is not.