We benchmarked Opus 4.8 on single-turn Web Dev, and we found something rather surprising… it performs significantly worse compared to Opus 4.7, and all other Anthropic models for that matter.
Rather shockingly, Claude Opus 4.8 ranks 23rd overall on Design Arena’s Web Dev (Non-Agentic) evaluation, which is 20 placements lower than its predecessor Opus 4.7 and 22 places lower than the newly released Fable 5. This marks a notable regression from Fable (1st), Opus 4.6 (2nd) and Opus 4.7 (3rd), a model line that has held the top spots for months on our leaderboards and won more head-to-head matchups than any other model we track.
It’s important to note that this leaderboard explicitly evaluates single-turn, single-file web applications written entirely in HTML.
Curiously, **we did not notice the same dramatic regression on **
**Design Arena’s Full Stack Web Dev (Agentic)**evaluation. While still lower than its predecessor Opus 4.7, Opus 4.8 ranks (2nd) overall (Fable results are pending for this leaderboard at the time of writing).
It’s worth noting that the Design Arena’s Web Dev (Agentic) Full-Stack evaluates models’ ability to build multi-file React applications with multi-reprompts from users, backend integrations with Supabase, Vercel deployment, Google Auth, and many other Full-Stack features.
So why is it that Opus 4.8th doesn’t even make the top 20 for Design Arena’s Web Dev (Non-Agentic)?
To answer this question, we conduct a case-by-case error analysis on both single-turn and multi-turn deployments of Opus 4.8. This approach lets us identify how the error cases in the single-turn deployments bleed into multi-turn deployments, ultimately worsening Opus 4.8’s performance across the board.
Our analysis points to a potential underlying pattern: Opus 4.8 has dramatically regressed in single-turn settings. The model behaves as though it’s been optimized for multi-turn agents, showing shorter initial outputs, reduced dependency on outside sources, and deferred layout decisions that earlier Opus models handled upfront. This has left it with significantly worse single-turn performance, with unfixed dependency errors and missing layout changes that drop its win rate.
Model Behavior #1: Shorter, more hedged code outputs #
To start, Opus simply generates less than other models in single turn deployments. In the same workflow-based test conducted across 2,022 generations, Opus generates an average of 67% less lines of code and 61% less characters than its competitors on the same prompt, even with high effort enabled.
While this could be a marker of getting more done with less, Opus 4.8 just does less. This is a disappointing result, as Opus 4.8 performs extraordinarily well when it does generate more intricate codebases. Longer outputs with 50k+ characters have a 12.5 percentage point performance increase, but the model only generates them in less than 2% of generations.
This is one of the first signals of agent-based optimization, as shorter outputs lead to faster iteration times for agent deployments. We see this turn around directly in agentic settings, where Opus 4.8 calls 26% more tools than any model it competed against. It generated 11% longer plans, 5% more lines of code and 27% more files than its competitors on average in the agentic setting.
In fact, Opus 4.8 is one of the faster models on our leaderboard, working at about 1.5x the speed of Opus 4.7 and 2.3x the speed of Opus 4.6.
However, this comes at the cost of a significant quality drop, as the speed gain is partially due to generating less tokens per request. For design workflows where quality is utmost, this is a significant regression.
Model Behavior #2: Missing or Broken Outside Sources #
Opus 4.8 also exhibits degraded compatibility with outside libraries and inputs. For example, in hero images where other models interface with common CDNs like Unsplash, Opus 4.8 simply creates supersized emojis and uses them as hero images, showing up in over 18% of generations and dropping win rates by 35.2 percentage points.
It also tends to break navigation links, with over 52.2% of outputs having broken or dead links in their outputs.
These errors generally fix themselves in the fullstack arena, with dead navigation links only showing in 18.9% of generations and emojis never showing as hero images. Because the model gets the chance to revise its iterations, it replaces broken navigation links or hero images with more appealing references.
This extends beyond just CDNs and network calls. Opus 4.8 invokes dependencies regularly, but only sometimes uses them properly.
For example, in dashboard settings the model often imports recharts
or jspdf
, but creates stub configurations that produce empty chart containers or fail to render entirely. This appears as missing charts, dropping win rates by -18.3 percentage points.
However, it’s still able to use libraries like Bootstrap and GSAP to improve the quality of its visuals, and sees significant win rate lifts (up to +35.9 percentage points) when it does so.
In agentic settings, these errors are easily resolved, as the multiple iterations give the model multiple tries to get the previous result correct. The model loads in dependencies likely expecting to have another pass, but when it doesn’t have access it completely crashes.
Model Behavior #3: The Return of Anti-patterns #
We also see a significant regression in terms of the anti-patterns that Claude Opus 4.8 uses in comparison to Opus 4.7.
The model tends to use grid overlays (5.3% of generations) and floating/bobbing hero images (7.4% of generations), neither of which perform well in user tests. Grid overlays decrease win rates by 8.5 percentage points and floating/bobbing hero images drop them by 4.2 percentage points, creating highlightable error cases that users recognize.
On the agentic side, we see both of these, albeit in significantly reduced quantities, plus one more error case: writing foreign scripts as Unicode characters. This significantly drops Opus 4.8’s win rate, with a -14.4 percentage point drop.
This is a direct result of Opus 4.8’s over-optimization on tool use, as it almost never uses tools that write files directly and instead prefers to use bash
commands that directly create files. Since these commands require intricate escaping, it’s easy to make these sorts of mistakes, even with additional passes.
These small errors accumulate #
None of these error categories alone explain a 22 place drop, but they do add up, especially since a typical losing output combining several error categories. We find that it’s only in agentic settings, where the model spends more time to iterate on and reduce these errors, that it’s able to recover. But they’re still present, and their impact is enough to hold Opus 4.8 from claiming Opus 4.7’s #1 spot in Fullstack Arena.
But there is a bright spot: Backend! #
Opus 4.8 has real strengths in backend engineering, with database design, API scaffolding, and auth implementation, as is shown by holding the 1st position on Design Arena’s Agentic Web Dev Backend Evaluation. Since these are easily checked using deterministic tools (
tsx
, node
, etc) that can be ran in agentic settings, Opus 4.8’s optimization for the terminal brings its backend strengths to light.## What this means for model selection
Opus 4.8 is a step backward on for UI-focused, single-turn tasks. It's worse than Opus 4.7 in both workflow and agentic settings, and substantially worse in single-turn pipelines. The model appears oriented toward multi-turn iteration at the expense of single-pass quality, causing poor decisions to get stuck and drag down the final product.
For teams choosing a Claude model for design work, Opus 4.7, Opus 4.6, and Fable remain the stronger options for single-turn pipelines and any workflow where the model doesn't get a second pass. Opus 4.8 is worth considering for backend-heavy work in database design or API scaffolding but only in environments where it can iterate and self-correct like agents. We will continue monitoring Opus 4.8 performance and how it compares to other models. Congratulations to the Anthropic team on the launch, and try out Opus 4.8 for free on DesignArena.ai.
— Written with ♥️ by The Intelligence Company.
Appendix: Methodology #
Design Arena ranks models by head-to-head human preference, using rankings from our 4M+ users in 190+ countries. Users select desired categories alongside an input prompt and models are recruited at random to respond to the prompt.
For this examination, we compare along two commonly used forms of AI deployments: workflows and agents. Workflows, or single-turn deployments, were the first usage of LLMs in enterprises due to their scalability and limited capabilities of early models. They function as a fixed, single-pass flow: a prompt is composed (often with retrieved context or templated instructions), sent to the model in one shot, and the model's output is taken as the deliverable.
Agents, or multi-turn deployments, wrap the model in a loop and enable fully autonomous behavior. The model can plan, call tools, web search, inspect its own output, and revise across multiple turns before returning a result. Quality emerges from the entire trajectory rather than a single generation, so weaknesses in any one pass can be recovered through iteration.
Since agents can run for many steps (theoretically infinitely many) they’re extremely flexible and high quality, being used as coding tools, personal assistants and more. However, many mass data processing and legacy workflows use pipelines as they scale over millions or billions of documents.
To ensure a balanced evaluation, DesignArena tests both types. Specifically, we offer a workflow-based website leaderboard alongside agentic web apps, mobile apps, and fullstack leaderboards.
You can read more about our methodology at https://www.designarena.ai/about and the leaderboards we offer at https://www.designarena.ai/leaderboard.
Data updated on June 11th, 2026