It’s Broken… The Claude Code Vs Codex Debate Is Finally Over

For a long time, everyone's go-to model for coding was clawed. Not only because it performed well, but because there weren't other options on the same tier. Then GPT models stepped up and closed the gap, especially with the release of GPT 5.5, which brought it down to almost none. To compare the two, we needed to put them in the environments designed best for them, which means their own CLIs. So, we're putting Opus 4.7 and GPT 5.5 to the test to see how they perform against each other. We'll test them across nine categories to find out which one actually comes out on top and by the end you'll know which one earns the spot in your workflows. Usability is where claude code starts breaking down for us. We've been using it for most of our tasks coding and non-coding but it was only good until the 2.1.0 update. After that things started going downhill for clawed code. The UI is the most frustrating part because it has the biggest impact on the experience. the terminal glitches, rendering breaks, and a lot of what used to feel polished now feels off. It used to be one of the best TUIs, but only until it started being vibe coded. It now feels more broken with multiple bugs like rendering issues, cachy leaks, about which not only us were complaining. The bigger problem is that they removed the dangerously skip permissions mode and replaced it with auto mode by default. We used to run bypass permission mode for most of our tasks with hooks set up for whichever files we didn't want Claude to touch. Now it asks for permissions on even that mode. When we gave Claude a prompt to create a skills, shifted to another Claude session to do something else and only later found that the skill creation was blocked by permission prompt for writing to theclaude folder the entire time. We came back expecting the skills to be created and it was just sitting there waiting. Codex handles this better because its yolo mode doesn't ask for any permissions the way Claude codes auto mode does. The CLI is built on Rust, so the UI is much smoother than Claude Code's React-based setup. And even after a long session, nothing breaks. Personality configuration is another spot where Codeex pulls ahead. We can set the personality to a more direct and concise language. This is because GPT 5.5 is significantly more sycophantic and is agreeable with every prompt than Opus 4.7 is. This is why changing the personality in codeex prevents that default behavior in the model. To make Opus 4.7 direct, we have to rely on instructions in Claude.m MD, while Codex does that with just a setting change. Pre-installed skills are another difference. Codeex ships with many that Claude code doesn't have, including the agent browser skill. That matters for anyone building apps because in Codeex, we don't need to explicitly connect MCPS for browser verification. It does that automatically after implementing any feature. It also has a built-in skill creator. So when we want a new skill, it generates a complete one with the right structure and reference files. In Claude, we'd need to install the skill creator separately to get a properly structured skill. Otherwise, it just writes an MD file. Now, there are still two things Claude Code does better. Codex doesn't offer rewinding, which is a feature we use the most. So, not having it is a real downside. Claude Code also lets us view its thinking by expanding it with control plus O, which Codeex doesn't do well. Viewing the reasoning is helpful because we can correct the approach mid task instead of waiting for the implementation to finish and then redoing it. So looking at how Claude Code's user experience degrades with each new update, Codex gets a point for usability. On [snorts] cost, Claude Code is the more expensive tool by a wide margin. Not in terms of actual prices, but by usability per same price. Claude Code is not available on the free tier at all and is only available starting from the pro and max plans. The plans have nearly identical pricing. The Pro plan is basically unusable for any good scale application because it hits its limits on just a few tasks. We can't even properly use Opus 4.7 for any meaningful task on Pro. The limits run out very quickly even on the max plan that we use. Codeex is in a better position from the start. It's available even on the free plan with limited usage. Both use a similar 5-hour window mechanism. So to see which one gets more work done, we ran them on tasks of the same scale. Claude Code already has a context command that visualizes how many tokens a session has used, but Codeex doesn't have a built-in equivalent, so we had to find a workaround for the comparison. Both tools store their sessions as JSON files, just organized differently. So, we built a small tool that reads them and counts the tokens used in each session. On the same app and a similar level of debugging, Opus 4.7 burned through 173,000 tokens, while GPT 5.5 used only 82,000. This is because GPT 5.5 gets work done in fewer tokens and far fewer retries. So, Codeex lasted significantly longer and turned out to be far more costefficient for the same work. But before we move forwards, let's have a word by our sponsor, Stream. You're building an app and your users need to talk, stream, and connect. You try handling that yourself 3 months later, you're still debugging instead of shipping. Stream skips all of that. Stream gives you everything out of the box from inapp chat and video calling to activity feeds and AI moderation. So you're shipping features, not building infrastructure from scratch. We're talking WhatsApp style messaging, Zoom style video calls, and Instagram style feeds, all builtin. What really stands out is Stream's new launch, vision agents. You can build intelligent AI agents that see, hear, and act on live video and audio. All in Python with just a few lines of code. Everything runs on a global edge network for low latency everywhere. From startups to scaling apps, leading platforms across social, fitness, and community, rely on Stream to power over a billion end users. If you're a developer building the next big app, Stream scales with you from day one. Start for free at getstream.io. Links in the pinned comment. The real test for the two models is on how they build products. As we said before, GPT 5.5 is faster and consumes fewer tokens, so it ships working apps quicker. Opus 4.7 spends more tokens on thinking, plans deeper, and iterates on all aspects of the app at the same time. Planning was the first thing we wanted to test. We've been using Claude Code's planning mode for a long time. It covers most things, has some flaws, but is still quite usable. So, we wanted to see how GPT 5.5 performs at planning because OpenAI claims it does better at planning tasks and executing them. We enabled plan mode and opened it in a folder that already contained a backend for an app, an API built using fast API and asked it to build the front end for it. It explored the project thoroughly and asked a few questions, but the questions were fairly simple. It could have gone deeper into how we wanted the front end to look because for front-end work that matters. The plan it produced was very simple. It included a summary of the main flow, the key changes, the pages to add, and how to test them. The one thing it did well was clearly separating its assumptions so we knew exactly what it was taking for granted. We told it to proceed and it finished in about 8 minutes. The same task on clawed code took 24 minutes, but Opus 4.7's plan was much more in-depth, considered more aspects of the application and even pulled in shaden UI to improve the user experience. So Opus 4.7 does better in terms of planning. Next, [snorts] we wanted to test both on a green field app. We gave them the same prompt that is to create a monor repo with a Python flask backend and a nex.js front end along with the full pipeline and key requirements for how the app should work. Claude code switched into planning mode by itself because of its harness design. Codex did not switch into planning mode and instead started implementing directly. It finished much faster than claude code which took around 16 minutes because of the planning step. GPT 5.5's version of the app had a much simpler UI and mainly focused on making sure the app worked. It didn't work properly at the start, so we debugged it. One thing we noticed was that the interview prompts were hard-coded because we hadn't provided any API key. The prompt specified using the Gemini API as a backend, but since no key was available, it implemented a fallback so the app wouldn't crash completely. Codex had actually used local follow-up questions without any explicit prompting. We like this because fallback mechanisms like these are useful in production since they prevent crashes. After a few iterations and adding the API key, the app's flow worked properly even though the UI was still simple. So, GPT 5.5 looked at the edge cases and implemented mechanisms to fill in the gaps. Opus 4.7 on the other hand asked us to give it the API key before it started implementation and built the entire app around that. So, Opus 4.7 unlike GPT 5.5 didn't prepare for fallbacks and just needed everything available up front. Due to this, when the API wasn't actually there, the app had no fallback and just gave an error. Claude code does focus on user experience and functionality together. So, its implementation looked more realistic. This is Opus 4.7's UI strength showing up, which we covered in our previous video where we said Opus 4.7 is way better at handling the UI, but its implementation also had issues. When we asked it to debug, it didn't directly inspect the implementation like Codeex did. Instead, it started asking us questions about what might be causing the problem and relied on our testing. It added debug points like indicators in the UI and console logs and asked us to check states and report back. After a back and forth, it eventually fixed the issue and the interview feature worked. We preferred how Codeex used the agent browser to debug on its own. So, in terms of autonomous working, Codeex's implementation was better. And in terms of user experience, Claude Code did a way better job. We also wanted to test how both handled the init command. Claude codes in it runs without expanding the prompt inline. It creates a simple claude.md file that's around 90 lines and includes architecture, app flow, front end and backend structure and all required commands to run the app. A lot of that information is redundant and doesn't really benefit the agent, which is why it isn't always necessary to keep all of it. Codex's setup was more refined. It included commit guidelines, pull request guidelines, and security instructions properly while keeping the project structure section brief instead of overloading it with detail. Neither was perfect, but Codex handled agents.mmd better. [snorts] Now, we also wanted to test how both perform on code review. We gave the same prompt for a reliability review to both codeex and claude code, asking them to document the review in separate files while working on the same codebase. Once both had generated their reports, we opened a new session and asked Claude to output the diff between the two files, comparing the findings. Claude's review was much more detailed. It organized every finding by priority and included components, the exact code snippets behind the issues. Codex's report mentioned line numbers but did not include the actual code snippets. Both reports were thorough, sharing several findings while each caught a few, the other missed. Claude Code also reported security issues like a leaked API key and a vulnerability. The task was a reliability review, though, and those issues were outside the scope. Claude Code reported every extra problem it ran into along the way, while Codeex stayed strictly on reliability. So Codeex's report was more aligned with the original request while Claude codes was broader but less focused on the specific task. If we had to describe both in terms of building, GPT 5.5 feels more like a back-end engineer focused on getting the application's functionality delivered correctly first, while Opus 4.7 feels more like a full stack engineer trying to balance both functionality and user experience. [snorts] On context management, Codeex performed much better than Claude Code. Claude code has insession context editing which removes tool calls and reasoning steps that no longer matter from the conversation. It clears redundant information from the session to avoid bloat. The compaction isn't perfect, but at least it doesn't keep unnecessary parts in the context while compacting. Codeex doesn't edit their context. It compacts the entire conversation just as it took place. The one thing it does better is preserving the last 20,000 tokens in memory and not compacting that portion at all. that helps prevent performance degradation in codeex after compaction so that the conversation can flow smoothly from the next prompt onward. We tested its performance and codeex performed better after compaction than claude code did. So even though claude code follows a more detailed multi-step compaction process, CEX's preserved tail keeps the agent more useful in practice. Memory works differently between the two. Claude Code's harness is mostly stateless across sessions, meaning each session starts without any context from the previous one. It now has a memory feature that can store persistent preferences or instructions. So if we tell it to avoid doing something a certain way, it stores that and applies it again later within the same project. That helps when working repeatedly in a single project. But the memory is project scoped. So switching projects loses that stored behavior. Codeex takes the opposite route. It consolidates information from multiple sessions over time and builds a global memory across interactions. So it can retain patterns beyond a single project that can help consistency across different tasks. So in short, claude code keeps memory more contained within a project while Codex takes a more cross- session cross project approach which changes how each of them adapts over time. Since Claude code has been around for longer and is being developed constantly to improve developer experience, it has more to offer compared to codeex. Claude Code has a hook system which lets us run our own scripts at specific points in the agents life cycle like before or after a tool runs among other points for things like blocking unsafe commands, running formatterers, and more. We can also run sub aents in a dedicated work tree so their performance doesn't affect each other. We can control the effort level for the models and we can even use keywords like ultraink to push reasoning to its maximum on a specific task. None of that has an equivalent in codeex right now. The ecosystem is the other clear win for cla code. We can run sessions through the cla desktop app and delegate tasks from the mobile app. across clawed code, the desktop app, web app, and browser extensions. The surface is much wider than codecs, which mainly consists of a web app and a desktop app that was only recently released and didn't feel as strong at the time we tested it. Sessions also move between environments more easily on clawed code, which makes it more convenient to work across different interfaces. Codeex also has many interesting features. In the cloud, it has an attempt flag that runs the same task end times. It produces several implementations and selects the best one. Claude code can do something similar but only through configurations and instructions not as a flag. The other codec only feature which sets it apart from the rest is its integration with OpenAI's image models. It can use them directly in the CLI to generate images for the websites it's working on. Claude relies mostly on SVGbased generation for visuals which doesn't even compete on quality because it doesn't have any image model yet. If we're building a UI that needs real imagery, Codeex is the only one of the two that does it without even being explicitly told to. Also, if you are enjoying our content, consider pressing the hype button because it helps us create more content like this and reach out to more people. Both [snorts] use sub aents even though the concept was introduced by Claude first. Since it came first in Claude Code, its integration is more mature because it has been agentcentric and focused on the coding experience for way longer than OpenAI. It supports agents that can be orchestrated through remote sessions while Codex mainly supports multi-agent workflows inside the terminal environment. The biggest difference is how each invokes sub aents. Clawed code can spawn agents without explicit invocation, while Codeex only creates an agent if we explicitly ask for one in the prompt. When Codeex spawns agents, it names them and pass them a proper prompt as well. In coding performance, the two are fairly similar, but the design choices behind them are different. Claude Code sub agents use an explicit allow list, meaning the parent agent defines exactly which tools the sub aent can access, while codec sub aents inherit tool access from the parent by default. Claude code also gives every sub aent a completely fresh context window. A sub aent doesn't have access to the conversation history and only sees the prompt from the parent plus the system prompt and any global rules because Claude focuses on context isolation. Codex CLI does the opposite. It forks the full history into the sub agent session with the parents prompt layered on top. Codex agents retain more context about what's already been discussed which does help improve their performance. In practice, Claude codes strict isolation hurt our research sub agents. When we used them, the results weren't good enough because they only saw the immediate prompt and didn't have any prior context. Codeex agents get the whole history, can iterate more effectively, and perform better on tasks where continuity matters. That brings us to the end of this video. If you'd like to support the channel and help us keep making videos like this, you can do so by using the super thanks button below. As always, thank you for watching and I'll see you in the next one.