A Single Prompt Ran an 85-Minute, $52.55 Website Refactor—and Hit the Quota Wall Before Finishing
Long-running autonomous AI coding tasks are now practical enough to do real site refactors, but they carry hard quota and cost ceilings that can interrupt work inches from the finish line. A two-phase prompt split is a concrete pattern to keep the bill visible and avoid hitting the 5-hour cap mid-task.
Running Claude Code with Claude Fable 5.2 on high effort, a developer set a single prompt to rebuild a product site: the repo was the model's, it should match award-winning design, and it should never stop to ask. Fable 5.2 read the brand docs, saved a 79-page baseline, scraped Awwwards-style references, and forked three sub-agents to prototype three homepage directions. After 20 minutes of polish on the winning "Atlas" concept, it rolled the design across pricing, gallery, and docs pages, fixing mobile click targets under 44px along the way.
The run burned 1 hour 25 minutes and $52.55 (with a 98% prompt cache hit rate), added 4,320 lines and deleted 421, before the 5-hour quota cap cut things off just short of final verification. The author then re-ran the test scripts manually and found SEO held at 91 pages with zero regressions, but four mobile pages loaded 0.1–0.3 seconds slower, so the prompt's speed requirement wasn't fully met. The lesson: don't hand a whole site refactor to one long task; split it into a comparison phase and a rollout phase with a fresh session.
A 98% prompt cache hit rate shows long tasks reuse enormous amounts of repeated context, but the dollar total is still steep enough that solo developers need to think of prompting as a budget decision, not just an automation win.
The model caught real usability issues like sub-44px touch targets and mobile overflow on its own, which suggests AI-driven QA is advancing, yet it still failed its own load-speed goal on mobile because it ran out of quota before final tuning.
Splitting a long task into two sessions isn't just a quality or cost-control measure; it's an explicit workaround for a hard platform limit that the vendor itself imposes on unattended runs.
The author's stated requirement that "no SEO item got worse" was met, but the
The author's stated requirement that "no SEO item got worse" was met, but the speed requirement was not fully satisfied, meaning the model's self-verification is only as good as the prompts that set the acceptance criteria.
The only substantive comment evaluates the refactor's cost and risk. It argues that the high-effort, parallel-agent approach is thorough but dangerously dependent on the quota tail, and recommends splitting the work into separate sessions with cache reuse to make it reproducible. The mobile performance regression is also flagged as a reason to test beyond static screenshots.
85 minutes, $52.55, 4,320 lines changed, and still hitting the 5-hour quota—this exposes the real issue: high effort with three-way parallel comparison does meticulous work, even self-checking the 44px click targets, but betting the acceptance on the tail end of a quota in a long task is too risky. Splitting it into a compare-and-decide phase and an implementation phase, each with a fresh session, plus a 98% cache hit rate, is the replicable approach. The 0.1–0.3 second slowdown on mobile is a reminder not to trust only screenshots.