Three AI coding agents, one specification, the same website: Claude Code with Opus 5, OpenAI Codex with GPT-5.6 Sol, and Cursor with Grok 4.5 in a direct comparison.

Introduction

Since my comparison of OpenAI Codex vs. Claude Code in April 2026, the market for AI coding agents has once again moved on significantly: Anthropic released Opus 5 in late July, OpenAI rolled out the GPT-5.6 family in Codex in early July, and Grok 4.5 has emerged as a new, serious contender in the coding segment. It is time for an updated comparison. I also need to correct or at least expand on several statements from my earlier posts.

The Candidates

Claude Code with Opus 5

I introduced Claude Code in detail in my April post. Since then, Anthropic has improved coding performance once again with Opus 5, released in late July 2026. The context window is 1,000,000 tokens, and Claude Code can now work with a browser out of the box, allowing it to launch, operate, and visually inspect implemented features on its own.

OpenAI Codex with GPT-5.6

Codex is also familiar from my earlier posts. What is new is the GPT-5.6 model family, which OpenAI rolled out in Codex in early July 2026. It includes the Sol, Terra, and Luna variants, as well as the flagship Sol Ultra. For this test, I used GPT-5.6 Sol with the reasoning level set to “High.” Codex can also work automatically with a built-in browser and inspect its results visually.

Cursor with Grok 4.5

I have not covered Cursor in my previous posts, so here is a slightly more detailed introduction. Cursor is a development environment based on Visual Studio Code, created by the startup Anysphere, which was founded in 2022. It is one of the most commercially successful AI development tools available. Like Amazon Kiro or Google Antigravity, Cursor is not a conventional IDE with an AI plugin. Instead, it was built around AI agents from the ground up: In addition to familiar code completion, it provides an “Agents Window” in which multiple local and cloud agents can work in parallel, a native plan mode, and the option to start agents from a browser or even a smartphone. Pricing for the Pro plan starts at about USD 20 per month.

The current consolidation in the market is notable: In June 2026, SpaceX, which had merged with xAI in February 2026, announced plans to acquire Anysphere for USD 60 billion. Grok 4.5, released in July 2026, is already a product of this collaboration: According to xAI, it was developed jointly with Cursor and trained in part on real Cursor sessions. Through the xAI API, Grok 4.5 offers a context window of 500,000 tokens. However, the Cursor Grok 4.5 variant used in this test is, according to Cursor, a separate configuration with a context window of 256,000 tokens. The “High Fast” setting I used combines high reasoning effort with the faster, more expensive serving tier. In terms of functionality, Cursor is comparable to Codex and the Claude Code app and includes, for example, an integrated browser for validating web applications. xAI explicitly positions the model against Anthropic’s Opus models: comparable coding quality, but significantly faster and less expensive. We will see whether that claim holds up.

The Test

The Task

For the test, I used my private street photography website, photo.guntherpopp.de. The original is a conventional React SPA that has been running in production for some time. I created a separate documentation repository for the test that describes the website completely without prescribing its implementation. It contains no code at all, only:

• architecture documentation
• a semantic data model containing the central concepts of the domain
• various feature specifications
• the actual content, including the photos, metadata, and image descriptions

The specification describes a bilingual, image-centered portfolio: a gallery with a Series filter, detail pages containing the photo’s metadata (exposure time, aperture, and so on) and description, Carousels, an About page, and various legally required pages. The site uses no tracking and requires no cookies. The Carousel feature specification gives a good sense of the specifications’ style and level of detail.

The Setup

I copied the specification repository three times, giving each agent an identical working copy. Apart from the workspace assignment, AGENTS.md was identical in all three workspaces. Among other things, the file requires an implementation plan before implementation begins and browser tests to validate the layout and navigation. All three agents then received the same deliberately concise prompt:

Please read and understand the architecture and the features of the
planned photo site. Then make a proposal on how to implement it.

None of the agents had access to the original website or its code during implementation. The original served solely as my personal benchmark for its look, feel, and functionality. I did not expect to receive a replica. In fact, a technically superior alternative would have been very welcome.

My role during the test was limited to approving the implementation plans and answering questions.

Observations During Implementation

All three agents first analyzed the documentation and submitted an implementation plan for approval. Only then did they implement the website. They therefore followed the process required by AGENTS.md throughout. The differences in speed and thoroughness are particularly interesting:

Claude Code created its plan in about seven minutes and asked several questions, each accompanied by a reasoned recommendation. These covered the build stack, the publishing workflow, meaning the process used to prepare the images, and the testing approach, among other topics:

The implementation took about 80 minutes in total. Opus was by far the slowest, but it also handled the task most thoroughly: It not only implemented the website but also took care of quality assurance, including end-to-end tests with Playwright, accessibility scans, and visual reviews using the integrated browser. In the process, the agent independently found and corrected layout issues, noting, for example: “The mobile detail page pushes the photo below four navigation buttons. Let me put the image first on narrow screens.” At the end, it also explicitly verified the privacy requirements against the build output, including the absence of external hosts and cookies. The only drawback was that Claude Code stored the implementation plan outside the workspace, so it was not version-controlled. I explained why I consider this a disadvantage in Best Practices: Implementation Plan.

Codex invested about 13 minutes in research and planning and also asked questions, including one about the visual direction:

For the implementation, which took about 35 minutes, Codex independently used a website-building skill, addressed the publishing workflow, and implemented various tests. However, these were considerably less comprehensive than Claude Code’s tests. Overall, the implementation was less careful; more on that below in “The Results.”

Cursor was in a league of its own in terms of speed: After only about ten minutes and around 5% of my monthly Pro plan budget, the complete result was ready, including both the plan and the implementation. Cursor also used subagents for tasks such as analyzing the documentation and assets in parallel.

A nice touch: The implementation plan could be saved as a Markdown file in the workspace with a single click.

As the results below show, however, Cursor’s speed came at the expense of quality assurance.

The Results

The Same Architecture Three Times

All three agents independently selected Astro as their technology stack. The original is a React SPA, and the specification is deliberately technology-neutral. Nevertheless, all three reached the same conclusion and justified it in nearly identical terms: Statically generated pages are more SEO-friendly and deliver their content directly in the initial HTML without requiring a client framework to run. The three results are also practically identical in other respects, including routing, sitemap structure, and the bilingual implementation. In 2026, the difference between agents apparently no longer lies in whether they can understand and implement the requirements, but in aspects such as layout and test coverage.

Claude Code: Ready to Ship

Claude Code’s result comes closest to my benchmark: a dark, image-centered layout that looks remarkably similar to the original, even though the agent had never seen it and I had not explicitly requested such a layout. The image stage is sized correctly, navigation works on all devices, and the interface is intuitive.

All core requirements are implemented and work correctly: the Series filter, two-level navigation, keyboard controls, swipe gestures, Person Notices, and language switching. It also includes features beyond the task itself: an Architecture Decision Record with documented dependency vetting, a complete command-line toolchain for my publishing workflow (import, metadata extraction, validation, and publication), and a total of 155 automated tests.

In fact, the version created by Claude Code has been running in production at https://photo.guntherpopp.de since the test, with a few small cosmetic adjustments (for example, I made some further improvements to the navigation on the detail page). These changes would not have been necessary for deployment: Even the initial version was already fully functional and visually polished.

Codex: Convincing, with Minor Weaknesses

Like the Claude Code version, the Codex version is dark and image-centered. It immediately appealed to me and also comes quite close to my benchmark. Overall, it is well implemented both functionally and technically.

During my manual test, however, I noticed two weaknesses. The first involved routing: The Astro configuration expected URLs without a trailing slash (trailingSlash: "never"), while the homepage redirect, language selector, canonical URLs, and sitemap pointed to /en/ and /de/. In the delivered version, this mismatch caused several key navigation paths to end on a 404 page. The end-to-end tests did not catch the problem because the preview server developed for them special-cased these two URLs. This is not a fundamental architectural problem, but it demonstrates the importance of making the local test environment reflect the eventual hosting behavior as closely as possible.

The image stage on the detail page was not yet properly tuned for every screen size either. On desktop, a container that was too short partially cropped the photo:

On a smartphone, the opposite effect occurred: The photo appeared relatively small within a large black area. During the initial load, this could briefly create the impression that the image was not yet available.

After brief feedback to Codex, both issues were corrected within minutes. It is nevertheless worth noting that, unlike the other two implementations, the originally delivered version was not production-ready.

Cursor: Solid and FAST

The Cursor version is the only one with a light, magazine-style design and serif typography. This layout differs most from the benchmark, but it is cohesive and well implemented overall. The image stage is sized correctly, navigation works on all devices, and the interface is intuitive.

Despite the extremely fast implementation, the result is functionally complete. However, there are clear differences in quality assurance compared with the other two. Grok created only minimal tests and did not automatically verify the layout using the browser. Cursor at least documented the latter point in its automatically generated validation report, which explicitly states that browser interaction tests were not possible in the environment and should be completed manually. I did not investigate this further. In principle, Cursor should also be capable of running the browser tests independently; the browser tools were enabled in the configuration.

The publishing workflow was also kept very minimal: The original JPEGs are served directly, with no metadata extraction, validation, or generation of optimized image sizes. This is acceptable for a private website, and the missing steps can be performed manually if needed. In fact, I generally prefer lean solutions that can be expanded when necessary. Even so, I ultimately chose the considerably more heavyweight Claude Code version because it fully automates the publishing workflow and therefore saves me work.

Corrections to Earlier Posts

The test corrects or expands on several statements from my earlier posts:

• In my April comparison, I wrote that Codex felt more “polished and mature” overall than Claude Code. The overall picture has since shifted: Ironically, Codex was the only agent in this test to deliver a result that was not ready to ship, while Claude Code completed the task in full, including quality assurance. Anthropic has also caught up in terms of tooling: The Claude Code desktop app is now on the same level as the Codex app.
• By contrast, the test confirmed my earlier assessment that the Opus models are “slightly ahead” in pure coding. It also confirmed my conclusion from the Copilot comparison that Anthropic’s models are particularly strong at frontend and layout tasks.
• In my Antigravity post, I described native browser integration as a unique selling point and complained that other tools forced me to resort to manually created screenshots when dealing with layout issues. As of August 2026, that statement is outdated: All three tools tested here now offer native browser integration.

Conclusion

A single test involving a single task is not a benchmark, and a greenfield task with unusually good documentation cannot be extrapolated to everyday project work. With that caveat in mind, the three runs paint the following picture:

Claude Code with Opus 5 is thorough and self-critical and performs its own quality assurance, but is correspondingly slow and expensive. Where correctness and traceability matter more than budget, it is currently the first choice.

Codex with GPT-5.6 works considerably faster than Opus 5 and delivers results at a comparable level. In this test, however, its review of its own work was not as thorough as Claude Code’s. The practical consequence was that the Codex version was not fully functional and could not be shipped without some manageable corrections. Even so, Codex remains a good choice in my view when speed and cost matter alongside quality.

Cursor with Grok 4.5 surprised me the most. A functional, lean, specification-compliant result in ten minutes at a fraction of the cost resets expectations for what the combination of a fast model and strong tooling can deliver. The limitations, namely fewer tests, no browser verification, and a minimal publishing workflow, are clearly visible but acceptable. In my view, xAI’s positioning of the model as “comparable to Opus, but much faster” is still somewhat too optimistic, but the direction is right. Cursor is currently the first choice when speed and cost are the main priorities.

My recommendation from the earlier posts therefore applies more than ever: Do not commit to a single tool. Instead, combine their strengths deliberately and continue to watch the market closely. The landscape is being reshuffled every few months.