Three web apps with no prototype, built by GPT-6 Sol, GPT-6 Astra, and Claude Opus 5.5
The three event guides could all save a concert plan. But opening My plan revealed a more interesting difference. Astra and Sol introduced the page with another large event hero. Opus put the planned sets and their clashes first, including the minutes of overlap and choices for resolving it. At a venue, that ordering matters more than whether the poster looks good.
Earlier frontend work had left me expecting Opus to do better than GPT-5.6 Sol when the screen itself needed designing. With GPT-6 Sol and Astra now available, I wanted to know whether that gap had closed where a prototype does not exist: in deciding what the screen should show, how it should behave, and what deserves the user's attention. A build check or a feature checklist could not answer that question by itself.
I gave GPT-6 Astra medium, GPT-6 Sol xhigh, and Claude Opus 5.5 high the same English briefs. These were the settings I would consider for delegation, so reasoning effort and cost were not matched. Each model started from the same minimal React, TypeScript, and Vite setup, with no prototype or design system. They could not use web search, external design references, generated images, or custom skills. Each produced one working app per brief: a delivery exception desk, a concert guide called NIGHT LOOP, and a warehouse inspection app for a small Android terminal. For the warehouse task, all three received the same three orders and the same API, including its delayed responses, connection failures, and competing edits from another worker.
I looked at the same screen states and widths, including the first view, details, errors, and conflicts. I kept returning to what each model had decided the user needed to see next.
In all five comparison images, the panels run left to right: GPT-6 Astra, GPT-6 Sol, Claude Opus 5.5 high.
The delivery desk is for people working through cases with deadlines. Astra and Sol put a heading, introductory copy, and summary cards ahead of the case list. Opus grouped cases by due day. Its first phone screen already showed the beginning of the queue, with urgency built into the list itself.
The first two designs tell an operator about the desk; the third helps them decide which case to open. On a desktop, the difference is less clean cut. Astra and Sol use a useful list and detail layout, while Opus leaves much of its detail area empty until a case is selected. Opus's advantage is strongest on the phone, where it turns the selected case into a dedicated screen with a back action at the top. Sol keeps the surrounding page furniture above the detail, leaving its back action much farther down.
Sol separates notes from status changes and labels the change reason as required. Opus uses large status choices, identifies the current one, and changes the save action to match the selection. It makes the choice easy to read; Sol makes the requirement hard to miss. Opus also puts the action before much of the case history, which may cost context when an operator needs to review previous responses.
NIGHT LOOP is the one brief where I preferred Astra's visual direction. Its performer cards use a family of line drawings, including rings, bars, waves, and geometric curves, on muted lavender, sage, sand, teal, and salmon backgrounds. Sol made a bold acid-yellow poster. Opus used a more familiar neon gradient. I would start with Astra if the job were to explore the event's visual identity.
The visitor came to find a set. Astra and Sol both spend most of the first phone screen on the event treatment; Opus brings times, stages, and several performers into view. The difference grows on My plan. Astra and Sol repeat the large hero, pushing the saved sets and clashes down. Opus opens on the plan, describes the overlap, and offers concrete choices: keep either set or split the time. Its stage colors and timetable help people orient themselves, though some controls are small and a toast can cover the plan and bottom navigation.
Expression earns its place when it helps someone recognize an act, a stage, or a decision. It becomes expensive when the user has to scroll past it every time they revisit their own plan.
Astra and Sol even arrived at almost the same headline, “Find your frequency.” That is a small sample, but it made me less willing to equate a forceful poster treatment with an original concept. Astra's performer artwork has more character than either headline.
The warehouse worker handles hundreds of jobs on a narrow Android terminal, often while wearing gloves.
Opus puts the first order near the top. Astra brings the same brand-style wrapper seen in the delivery desk: a slogan, summary cards, and small supporting text before the orders. Sol is more restrained. Both GPT-6 apps have search and status filters in the queue; Opus omits them. Three fixture orders make its short list feel elegant, but hundreds of daily jobs would make finding a particular order part of the work.
Opening W-101, I preferred Opus's inspection screen at first glance. Large quantities and a prominent scan result are easy to check at a glance. Undo last scan and manual entry stay close to the thumb. An unknown barcode gets a conspicuous message that says what to do with the item. A shortage becomes an unmistakable “On hold — do not ship” state.
The more serious issue appears when another worker changes an order. In W-103, that worker records one flashlight while this device scans one too. Astra shows the server's count beside this device's change, but visibly s scanning during review; a worker who scans then must scan again afterward. Sol asks the worker to review the conflict and holds new scans until they choose what to keep. Opus silently treats the two flashlight scans as one recorded unit and returns to Saved. No one gets to say whether they were the same physical item.
That failed the conflict item in the 11 predefined warehouse checks; Astra and Sol passed all 11. Scanning during conflict review was an additional observation, so Astra's visible did not affect its check result. Opus also silently replaces damaged local saved data in the warehouse app.
This changed my reading of the earlier comparisons. A screen can direct attention well through the normal path and fail to represent a consequential exception. In a warehouse, Saved is a claim about physical work, not a decorative status label. Sol gives a more trustworthy account of what happened when the network or another worker intervenes.
For me, the blank-screen test now has two questions. Before the first scroll, what decision has the model made easy for the user? When a save, a scan, or another worker's edit changes the state, does the screen tell the truth about it? Delivery and NIGHT LOOP made the first question visible. W-103 made the second impossible to ignore. TypeSafe's judgment model Jev compared unnamed rendered HTML and CSS, with screen pairs shown in both orders. It favored Opus's hierarchy in delivery and NIGHT LOOP but Sol's warehouse list and inspection layout, contrary to my first impression of Opus's compact order screen.
I have not checked Jev's visual judgments against human ratings. I knew which model made each screen, and each model had one attempt per brief. These empty projects also did not test how they would extend an existing product.
I would still give Opus high an open-ended delivery or event screen when the structure itself needs inventing. Its handling of conflicts and damaged data would need close review. For a warehouse-like workflow, Sol xhigh is the better starting point from these attempts: it keeps scans during conflict review, preserves damaged local data, and gives workers search and filters. Astra medium is worth asking for visual exploration, with the task's first screen and scanner behavior checked before using the result. The observed list-price equivalents were $6.86 for Opus high, $1.58 for Sol, and $5.67 for Astra. Opus cost about four times Sol in these sessions; the different CLI harnesses and caching limit what that ratio predicts elsewhere.
Opus made the stronger first-screen decisions in delivery and NIGHT LOOP; Sol outperformed it on the warehouse task. The question I will carry into the next frontend comparison is this: when the brief leaves the design open, does the model spend the first screen on the user's next decision, and does that clarity survive when the state becomes uncertain?