# Claude Sonnet vs Opus: What Happens After 100 Rounds of "Make It Better" > Source: > Published: 2026-10-30 00:00:00+00:00 # Claude Sonnet vs Opus: What Happens After 100 Rounds of "Make It Better" A hands-on test told Claude Sonnet 5.5 and Opus 5.5 to improve a website 100 times each. Here's what changed, what broke, and what it cost. ## What happens when you tell Claude to improve a website 100 times? In a hands-on test, a deliberately ugly coffee shop website was handed to both Claude Sonnet 5.5 and Claude Opus 5.5 (medium effort, clean sessions with no memory or plugins) with one instruction repeated 100 times: look at the site, make one bold change, ship it. Sonnet produced a steadily improving but still restrained site for about $30 in API costs. Opus produced more features faster, spent around $137, and by round 100 had buried the site in competing widgets, broken functionality, and visual clutter. ## TL;DR - **Sonnet 5.5** made slower, more conservative changes across 100 rounds and finished at a usable, if busy, site for roughly $30 in API billing. - **Opus 5.5** moved faster early (video backgrounds, forms, and a QR-code ordering flow by round 32) but cost about $137 and ended up overengineered by round 100. - Both models front-loaded their best work: Sonnet’s major milestones landed by round 32, and Opus hit its last meaningful milestone at the same point before devolving into forced, low-value additions. - **Opus generated more media** (54 AI images and 3 videos versus Sonnet’s 11 images and 2 videos), which tracks with its higher cost per round. - Forcing a “ship something every round” constraint eventually produces **diminishing and even negative returns** : Opus broke working features (a language toggle, a pumpkin-carving interaction) while adding new ones. - Lines of code climbed steadily for both models even when visible quality plateaued, suggesting code volume is a poor proxy for actual improvement. - The experiment suggests vague, open-ended prompting (“make it better”) caps out well short of a polished result, and human taste or curation is still needed to get past that ceiling. ## How was the test set up? The creator started with an intentionally bad coffee shop website, then ran the same prompt against both models 100 times in a row: look at the site, think about user experience, make one bold change that improves conversions or feel (not a small tweak), ship a change every time. The instruction to force a change every round was necessary because, in earlier attempts, the model would stop around round 20 to 25 and declare that nothing more could be improved. Each run happened in a clean session: no custom instructions file, no skills, no plugins, no memory carried between rounds. That means each model was working from its own baseline training and built-in tools only, not from any accumulated project context or external guidance. The goal was to isolate how each model handles repeated, open-ended “improve this” instructions without human curation steering it toward a specific vision. ## What did Sonnet 5.5 do differently? Sonnet’s progress was gradual and milestone-driven. Round 1 delivered the first big jump: an AI-generated background image, the first JavaScript interaction, and mobile readiness. From there, Sonnet added features incrementally: a sticky order bar in round 2, a working product image in round 7, an AI-generated video background by round 24, and a functional order-ahead form by round 32. After round 32, the tool’s own milestone tracking showed nothing significant through round 100. Lines of code kept climbing in a roughly linear pattern, but the milestone log suggests most of that later work was incremental polish rather than meaningful change. Interestingly, Sonnet didn’t just add. At round 65, it had a navbar element that disappeared by round 100, meaning the model removed something it had previously built because it decided the feature wasn’t working. It also made small, seemingly arbitrary changes late in the run, like swapping the site’s font between rounds 74 and 100, which looks like the model straining to find something, anything, to ship once it had exhausted more obvious improvements. Total cost for the Sonnet run: $29.93 in API billing, producing 11 AI-generated images and 2 videos over the full 100 rounds. ## How did Opus 5.5 compare in output and cost? Opus moved faster out of the gate. Round 1 already included an AI-generated image, a first animation, and mobile readiness, similar to Sonnet but with slightly more built in from the start. By round 7, Opus had added an AI-generated video background and a darker, more stylized theme. Round 15 introduced a working form and a QR code that, when scanned, pre-filled a text message with the customer’s order details, a genuinely useful piece of functionality. Round 32 added a canvas/WebGL-based interaction (an HTML canvas element combined with a JavaScript graphics API that renders complex visuals directly in the browser), used here for a mood-based drink recommendation tool. ## Seven tools to build an app. Or just Remy. Editor, preview, AI agents, deploy — all in one tab. Nothing to install. That round 32 mark was also roughly where Opus’s meaningful milestones stopped. From there to round 100, the model kept shipping changes because the prompt forced it to, but the result was more volume, not more value. By the final round, the site had accumulated a background with falling leaves, a caffeine-timing tracker, a music selector, a seating reservation system, a Spanish-language toggle that didn’t actually translate anything, and an interactive pumpkin-carving feature that didn’t work correctly. A review section that existed in isolation was reasonably well done, but it was lost in the surrounding clutter. Total cost for the Opus run: approximately $137, more than four times Sonnet’s cost, with 54 AI-generated images and 3 videos. ## Is more iteration always better? No. Both models showed a pattern where early rounds (roughly up to round 30 to 32) produced the clearest, most usable improvements, and rounds beyond that point delivered shrinking returns. Opus illustrates the risk most clearly: by forcing a change every round with no human filter, it eventually broke features it had already built. A working interactive element stopped functioning, and a translation toggle did nothing when switched. Sonnet avoided outright breakage but padded its later rounds with cosmetic changes, like a late font swap, that don’t reflect genuine user-experience gains. This points to a practical ceiling for autonomous, open-ended “just make it better” prompting. Without specific direction or a person applying judgment about what to keep, both models tend to plateau in quality well before round 100, even as code volume and feature count keep growing. Getting from a decent result to a genuinely polished one seems to require a human in the loop making editorial calls, not just more iterations. ## Which model is the better choice for this kind of work? For straightforward, budget-conscious iteration, Sonnet 5.5 held up well: it made steady, mostly sensible changes, didn’t break prior functionality in a visible way, and cost about a fifth of what Opus charged for a comparable 100-round run. For teams that want faster early progress and more generated media per project, Opus 5.5 got to richer features (like the QR-code ordering flow) sooner, but its tendency to keep forcing changes past the point of usefulness led to a cluttered, partially broken final product and a cost more than four times higher. Neither model, when run completely autonomously with vague instructions, produced a final product better than its own mid-run state. That’s the core finding here: round 100 wasn’t the best version of either site. Something closer to round 30 to 65, depending on the model, likely represented the strongest trade-off between features and usability, which argues for a human checkpoint during iterative AI-driven builds rather than letting either model run unsupervised to a fixed round count. ## Frequently Asked Questions ### What’s the real difference between Claude Sonnet 5.5 and Opus 5.5 in coding tasks? Based on this test, Opus tends to generate more features and more media (images, video) per session and moves faster in early iterations, but at meaningfully higher API cost. Sonnet is more conservative, cheaper, and in this case avoided breaking previously built functionality, though it also padded later rounds with low-value cosmetic tweaks. ### Why did the website get worse after many rounds of “improve it”? Both models were forced to ship a change every single round, even after running out of genuinely useful ideas. Opus in particular began adding competing features (music selectors, caffeine trackers, a broken pumpkin-carving widget) that cluttered the interface and, in some cases, broke earlier functionality like a language toggle. ## Remy is new. The platform isn't. Remy is the latest expression of years of platform work. Not a hastily wrapped LLM. ### How much did each model cost to run 100 rounds of changes? The Sonnet 5.5 run cost $29.93 in API billing. The Opus 5.5 run cost approximately $137. Both ran at medium effort settings in clean sessions with no memory or plugins carried between rounds. ### Does this mean Opus is worse than Sonnet for website building? Not necessarily. Opus produced some genuinely strong features, like a QR-code-triggered text order system, and generated far more images and video (54 images and 3 videos versus Sonnet’s 11 images and 2 videos). The issue in this test was specifically what happens under forced, unsupervised iteration over many rounds, not a general capability gap. ### What’s the practical takeaway for people building with AI coding tools? Open-ended, vague prompts like “make it better” tend to produce strong early gains that plateau and can even reverse in quality if the model is forced to keep shipping changes. Reviewing output at intervals and applying human judgment about what to keep appears necessary to get a genuinely polished result, rather than letting an agent iterate unsupervised to a fixed number of rounds.