Claude Code vs Codex vs Cursor (an honest comparison)

Claude Code vs Codex vs Cursor (an honest comparison) ![rw-book-cover](https://img.youtube.com/vi/JMYspR42HFM/maxresdefault.jpg) 🔗 **Source:** [Claude Code vs Codex vs Cursor (an honest comparison)](https://www.youtube.com/watch?v=JMYspR42HFM) > [!note]+ Document Notes > tags: [ai-development-tools, coding-agents, developer-experience, anthropic-claude, openai-codex, cursor-ide] > author: Theo Browne > source: YouTube > reference: https://www.youtube.com/watch?v=JMYspR42HFM > date created: {{date:YYYY-MM-DD}} {{time:HH:mm}} > > # 🏷️ Title: Claude Code vs Codex vs Cursor (an honest comparison) >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - Theo Browne analyzes the philosophical differences between three major AI coding tools: Claude Code, OpenAI Codex, and Cursor - Claude Code prioritizes user engagement and "feeling productive" through flashy UI elements and token-intensive features, optimizing for social media shareability - OpenAI Codex focuses on practical functionality and efficiency, prioritizing real productivity over visual appeal - Cursor leads in cloud-based agent development with full graphical Linux environments for testing - Key differentiator: Anthropic employees use internal tools (Mythos) different from public releases, while OpenAI/Cursor dogfood their public products - Bottom line: Choose based on workflow needs - Claude Code for motivation/engagement, Codex for experienced developers wanting efficiency, Cursor for team collaboration and cloud agents ## 📖 Main Content The comparison reveals fundamental philosophical differences in how these companies approach AI-assisted development. **Claude Code Philosophy**: Anthropic designed Claude Code as both a developer tool and marketing vehicle. It prioritizes the "feeling" of productivity through animated UIs, token-burning sub-agents, and features optimized for Twitter screenshots. The terminal-based approach offers easy adoption without changing existing workflows, but recent model improvements (Opus 4.5) enabled more aggressive token usage for potentially better results. **OpenAI Codex Philosophy**: OpenAI focuses on practical efficiency and token conservation. Codex emphasizes real productivity over visual engagement, with features like computer use for verification rather than spinning up multiple agents. The team dogfoods their own public tools, ensuring consistency between internal and external experiences. **Cursor Philosophy**: Cursor bets on cloud-first development with full graphical Linux environments that agents can control via computer use. This enables testing changes in real browser environments and triggering development work from mobile devices or Slack, pointing toward a future where local development environments become optional. ### Model and Integration Differences Anthropic hasn't meaningfully improved public models since December (Opus 4.6-4.7 are arguably regressions), requiring feature additions to maintain competitive positioning. Meanwhile, OpenAI's progression from GPT-5.2 to 5.5 provided substantial capability improvements. Integration approaches differ dramatically: Anthropic discourages external integrations to maintain platform lock-in, OpenAI actively supports building on their tools (like the open-source Codex CLI), and Cursor shows interest but historically under-prioritizes developer APIs. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=JMYspR42HFM?t=0) Introduction - Philosophy over capabilities - Wants to break down philosophical differences, not just model intelligence comparisons - Personal experience switching from Claude Code to Codex changed development philosophy - Goals: explain how tools differ in core approach, not convince people to switch #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=JMYspR42HFM?t=192) Claude Code origins and adoption - Boris's vision: what if models were way smarter? How would coding look? - Built for terminal use - meets developers where they are - Easy adoption story: paste command, install CLI, start using without changing other tools - Shift from 90% of YC batch using Cursor to 70% using Claude Code #### ⏱️ [00:06:45](https://www.youtube.com/watch?v=JMYspR42HFM?t=405) The Opus 4.5 turning point - Model capability jump made terminal access more compelling - Could trust model enough to run in "bypass mode" - Industry shift as model caught up to this style of tool - Anthropic noticed what performs well on Twitter #### ⏱️ [00:09:18](https://www.youtube.com/watch?v=JMYspR42HFM?t=558) Claude Code as marketing tool - "As much a marketing tool as it is a developer tool" - Features optimized for Twitter screenshots (pet mode, sub-agents) - Sub-agent teams feel incredibly productive but burn tokens aggressively - UI optimized for feeling of productivity - loading states, animations, token counters #### ⏱️ [00:13:30](https://www.youtube.com/watch?v=JMYspR42HFM?t=810) Codex philosophy contrast - Much less visual stimulation - timer and minimal animation - Not trying to feel like "slot machine" - just trying to get work done - Feature focus on practical improvements, not flashy additions - Examples: Mac unlock-free computer use, diff marker settings #### ⏱️ [00:18:45](https://www.youtube.com/watch?v=JMYspR42HFM?t=1125) Token usage philosophies - Anthropic: if more tokens solve the problem, use more tokens - OpenAI: trying to be more token efficient while maintaining accuracy - Computer use for verification vs spinning up 15 checking agents - GPT-5.5 used half the tokens of previous models for better results #### ⏱️ [00:22:15](https://www.youtube.com/watch?v=JMYspR42HFM?t=1335) Cloud environment approaches - Claude Code cloud runners often don't work properly - Anthropic advice: "don't really need agent to run code, just throw tokens at it" - Codex hides cloud option, focuses on controlling local machine - Different bets: models vs environment configuration #### ⏱️ [00:25:40](https://www.youtube.com/watch?v=JMYspR42HFM?t=1540) Cursor's cloud advantage - Full graphical Linux instances with computer use testing - Can work on multiple things requiring computer use simultaneously - Slack integration: mention bot, get video of fix being applied - Far ahead of competition in cloud agent capabilities #### ⏱️ [00:30:22](https://www.youtube.com/watch?v=JMYspR42HFM?t=1822) Internal vs external tools - Critical difference: what employees actually use vs what customers get - Anthropic employees use Mythos model and custom Claude Code builds - OpenAI employees use same Codex app customers get - Cursor team dogfoods their public tools extensively - System prompt leaks reveal internal/external inconsistencies #### ⏱️ [00:36:50](https://www.youtube.com/watch?v=JMYspR42HFM?t=2210) Integration and building ecosystem - OpenAI actively encourages building on their tools (open source CLI) - Anthropic pushes away from external integrations, wants MCP lock-in - Cursor interested but historically under-prioritized developer APIs - T3 Code built successfully on Codex app server #### ⏱️ [00:42:10](https://www.youtube.com/watch?v=JMYspR42HFM?t=2530) Model improvement trajectories - Anthropic models haven't meaningfully improved since December - Opus 4.6-4.7 feel like regressions vs improvements - OpenAI: GPT 5.2 → 5.5 massive improvements while Opus got worse twice - Anthropic compensates with features since they can't release better public models #### ⏱️ [00:45:30](https://www.youtube.com/watch?v=JMYspR42HFM?t=2730) Final recommendations - Claude Code: for unmotivated devs or those wanting to feel productive - Codex: for skeptical engineers wanting actual productivity and good workflows - Cursor: for teams wanting cloud runners and Slack integration - All better than sidebar coding in VS Code - try the desktop apps ## 📚 References - [Claude Code CLI](https://claude.ai) - [OpenAI Codex](https://openai.com/codex) - [Cursor IDE](https://cursor.sh) - [T3 Code](https://t3.gg) - Theo's agentic coding app built on Codex - Macroscope AI code review tool - G2I engineering hiring platform ## 🗣️ Paraphrase Theo argues that the real differences between major AI coding tools lie not in their underlying models, but in their fundamental philosophies about developer experience and productivity. Claude Code operates as much as a marketing vehicle as a developer tool, prioritizing engagement and social media shareability through flashy animations and token-intensive features that create a "slot machine" feeling of productivity. OpenAI's Codex takes the opposite approach, focusing on practical functionality and token efficiency while maintaining the same experience for both internal employees and external users. Cursor stands apart by betting on cloud-first development with full graphical environments that enable sophisticated testing and team collaboration workflows. The most concerning revelation is that Anthropic employees use significantly different internal tools (including the unreleased Mythos model) compared to what customers receive, while OpenAI and Cursor teams dogfood their public products. This creates a disconnect between development priorities and user needs at Anthropic that manifests in reliability issues and feature misalignment. ## 📰 Newsletter **AI Coding Tools: Beyond the Model Wars** 🤖 This week, Theo Browne dropped a fascinating analysis that cuts through the typical "which model is smarter" comparisons to reveal the philosophical differences driving Claude Code, OpenAI Codex, and Cursor. The key insight? Your choice shouldn't be based on model capabilities alone, but on how these tools approach developer experience and productivity. **The Big Three Philosophies:** - **Claude Code**: Optimized for engagement and "feeling productive" - great if you need motivation or find coding intimidating - **Codex**: Built for efficiency and real productivity - perfect for experienced developers who want tools that stay out of their way - **Cursor**: Leading the cloud-first future with full graphical Linux environments for testing **WordPress Developer Takeaway**: If you're building WordPress plugins or themes, consider how these tools handle environment setup and testing. Cursor's cloud runners could be game-changing for testing across different WordPress configurations, while Codex's local-first approach might better match your existing workflow. **Worth Exploring**: [Macroscope's AI code review](https://soy.cope) for automated WordPress coding standards checks, and [G2I's vetted developer network](https://soy.g2i) for WordPress specialist hiring. The future of coding with AI isn't just about smarter models - it's about tools that understand how developers actually work. Choose accordingly! 🚀 ## ✅ Action Items #### DevRel - Research integration opportunities between WordPress development workflows and AI coding tools - Create content comparing AI coding tools for WordPress developers specifically - Develop workshops on incorporating AI agents into WordPress plugin development cycles #### WordPress - **Core**: Evaluate how AI coding tools can improve WordPress core contribution workflows - **Plugins**: Test AI tools for automated WordPress coding standards compliance checking - **Themes**: Explore AI-assisted responsive design testing across different environments - **Community**: Create guidelines for AI tool usage in WordPress development best practices ## 🧪 Hypotheses 1. **Tool philosophy predicts long-term adoption**: Developers will gravitate toward tools that match their experience level and productivity preferences, regardless of underlying model capabilities 2. **Internal/external tool parity drives quality**: Products where employees use the same tools as customers will have better reliability and feature alignment 3. **Token efficiency becomes competitive advantage**: As AI coding becomes mainstream, tools that achieve results with fewer tokens will have better unit economics and adoption 4. **Cloud-first development will dominate team workflows**: Remote development environments will become standard for collaborative coding projects 5. **Integration ecosystem determines platform lock-in**: Tools that encourage building on top of them will capture more developer mindshare than closed platforms ### 📊 Methodology - **Comparative user studies**: Test developer productivity and satisfaction across different AI coding tools with controlled tasks - **Token usage analysis**: Measure token consumption for equivalent coding tasks across platforms - **Integration ecosystem mapping**: Analyze third-party tool development and adoption rates around each platform - **Long-term adoption tracking**: Survey developer tool preferences over 6-12 month periods to identify switching patterns ### ❓ Questions - How do token costs impact developer tool selection as AI coding becomes more mainstream? - What role does visual feedback play in developer motivation and learning when using AI tools? - How will cloud-based development environments affect security and IP protection concerns? - Can token efficiency improvements offset the need for flashy engagement features? ### 🔮 Future Research - Impact of AI coding tools on junior developer skill acquisition and learning curves - Enterprise adoption patterns for different AI coding philosophies - Integration between AI coding tools and existing DevOps/CI-CD pipelines - Economic models for AI-assisted development at scale ### 💡 Implications - **Practice**: Developers should choose AI tools based on workflow compatibility, not just model performance - **Education**: Training programs need to consider how different AI tools affect learning and skill development - **Enterprise**: Companies should evaluate AI coding tools based on team collaboration needs and integration requirements - **Industry**: The AI coding tool market will likely fragment along philosophical lines rather than converging on a single approach ## 🧠 Learning Styles Assessment **Reading level estimate**: Grade 12 (Flesch-Kincaid) - technical content with clear explanations and concrete examples #### 👀 Visual learners - **Present**: Screenshots of different tool interfaces, token usage comparisons, feature demonstrations - **Improve**: Side-by-side workflow diagrams, decision tree for tool selection, visual token burn rate comparisons #### 🔊 Aural learners - **Present**: Video format with detailed narration and explanation - **Improve**: Audio-only version focusing on philosophical differences, podcast-style discussion format #### 🗣️ Verbal learners - **Present**: Clear definitions of tool philosophies, analogies (slot machine vs efficiency), terminology explanations - **Improve**: Glossary of AI coding terms, comparison tables with plain language descriptions #### 🧩 Kinesthetic learners - **Present**: Hands-on tool demonstrations, step-by-step usage examples - **Improve**: Interactive tool comparison checklist, downloadable trial workflows for each platform #### 🧠 Logical learners - **Present**: Clear categorization of tool philosophies, systematic feature comparisons, decision frameworks - **Improve**: Flowchart for tool selection, cost-benefit analysis template, integration compatibility matrix #### 🧑‍🤝‍🧑 Social learners - **Present**: Discussion of team workflows, collaboration features, community adoption patterns - **Improve**: Team evaluation worksheet, discussion prompts for developer teams, peer review guidelines #### 🧘‍♀️ Solitary learners - **Present**: Self-contained analysis, personal workflow considerations, individual decision framework - **Improve**: Personal tool evaluation worksheet, reflection prompts for workflow analysis #### 🌿 Naturalistic learners - **Present**: Tool ecosystem thinking, organic adoption patterns, natural workflow integration - **Improve**: Ecosystem impact analysis, sustainable development practice connections ## 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Video has clear verbal descriptions of UI elements and workflows - **Improve**: Full transcript with image descriptions, heading structure for navigation, alt text for tool screenshots #### Keyboard navigation - **Present**: Tools discussed generally support keyboard navigation - **Improve**: Specific accessibility comparison between AI coding tools, keyboard shortcut guides #### Contrast and readability - **Present**: Video content clearly visible - **Improve**: High contrast screenshots in documentation, text size guidance for tool interfaces #### Media and captions - **Present**: Full transcript available, clear audio narration - **Improve**: Time-stamped captions, downloadable transcript with section breaks #### Standards reference - **Gaps**: WCAG 2.2 AA compliance assessment needed for each tool's interface ## 🌍 DEIB Assessment #### Cultural breadth - **Present**: Focuses on developer workflows across different experience levels - **Improve**: Examples from different types of development (mobile, web, enterprise), global developer perspective #### Inclusive language - **Present**: Generally uses accessible technical language with explanations - **Improve**: Avoid terms like "bad devs," provide more welcoming language for beginners #### Neurodiversity support - **Present**: Structured comparison format, clear categorization - **Improve**: Consider how different AI tool interfaces support various cognitive styles and attention patterns #### Representation - **Present**: Focuses on tool capabilities rather than user demographics - **Improve**: Include perspectives from developers with different backgrounds and accessibility needs #### Psychological safety - **Present**: Respectful discussion of tool trade-offs without shaming user preferences - **Improve**: Emphasize that tool choice should match individual workflow needs without judgment ## ✅ Logical Validity #### Strong reasoning - **Deductive strength**: Clear categorization of tool philosophies based on observable features and company behavior - **Inductive evidence**: Multiple examples support claims about each tool's priorities (UI choices, feature development, token usage) - **Causal reasoning**: Links model improvement trajectories to tool development strategies effectively #### Fallacies - **Ad hominem tendency**: Some characterization of Claude Code as "slot machine" could be seen as dismissive rather than analytical - **Survivorship bias**: Focus on successful tools may miss lessons from failed AI coding experiments - **Confirmation bias risk**: Author's preference for Codex may color interpretation of comparative evidence #### Tone of voice - **Analytical but opinionated**: Technical expertise combined with clear preferences, maintains educational focus while expressing strong views about tool design philosophy ## 🛡️ DARVO Analysis No DARVO patterns detected. The analysis maintains focus on tool comparison without deflecting criticism or reversing accountability relationships. ## 🎯 Conclusion The choice between AI coding tools ultimately comes down to workflow philosophy rather than raw model capabilities. Claude Code excels at engagement and motivation through visually rich interfaces, making it ideal for developers who benefit from active feedback and gamification. Codex prioritizes practical efficiency and real productivity, better suited for experienced developers who want tools that enhance rather than distract from their existing workflows. Cursor leads in cloud-based collaboration and testing capabilities, pointing toward a future of distributed development environments. The most significant concern raised is the gap between internal and external tooling at Anthropic, which may explain reliability issues and feature misalignment in Claude Code. Organizations evaluating AI coding tools should prioritize platforms where the development team actively uses the same tools they're selling, ensuring better alignment between features and user needs. For WordPress developers specifically, consider how these tools integrate with your existing development environment and testing workflows. The future of AI-assisted development will likely involve multiple specialized tools rather than one-size-fits-all solutions. --- ## Full Transcript [00:00] This is not going to be my usual video. [00:01] I want to try and break down the real [00:03] differences between things like cloud [00:05] code, codecs, and cursor. Not in the [00:07] like how smart are they sense or what [00:09] tasks are they capable of sense. I want [00:11] to break down the philosophy differences [00:12] between these solutions because I find [00:14] that they are way more different than [00:16] people seem to think. I know that we've [00:18] all used cloud code and codecs and maybe [00:20] you've even tried out the cursor CLI, [00:22] maybe you use their IDE, maybe you use [00:24] their cloud environment. Whatever it is, [00:26] many of you guys have tried all of these [00:28] tools. Many of you haven't tried some of [00:29] them for a while. Many of you have one [00:31] that you really like and you don't [00:32] bother with the others. And if that's [00:34] the case, I get it. If you're already [00:36] using Claude Code and you're happy, I'm [00:38] not here to try and change your mind. I [00:40] want to try and explain philosophically [00:43] what all of these things are trying to [00:44] do and how they differ. My main reason [00:47] for doing this is my own philosophy has [00:49] changed around doing agent development [00:51] since I moved from Claude over to [00:53] Codeex. Obviously, it also changed when [00:55] I moved from cursor to cla code, but [00:57] it's changed in a way that I like a lot [00:59] more this time. And I find that when [01:01] people are talking about these things [01:03] about cloud code versus codecs, they're [01:05] often just talking about the model or [01:08] how the UI looks and not about how [01:10] different the core of these things are [01:13] and how differently the teams building [01:15] them are thinking about how we make [01:16] software. To be more direct, this video [01:18] is happening because this reply on [01:20] Twitter got way more attention than I [01:22] expected as I broke down some of the [01:24] philosophical differences between how [01:26] Anthropic and OpenAI are thinking about [01:28] their coding tools. But I wanted to go [01:30] way further than I did here. I want to [01:32] really break down how these tools [01:34] differ, how they can be applied [01:36] effectively in your work, and where I [01:38] think they might be going long term. I'm [01:40] going to do my absolute best to present [01:43] as unbiased as possible because again, [01:45] my goal here isn't to try and convince [01:46] you to switch to a different tool. It's [01:48] to try and help you understand what the [01:50] different tools are meant to be built [01:52] for and who they might be best used by. [01:55] I don't want to sell you anything, okay? [01:56] I do want to sell you one thing. Today's [01:58] sponsor. Today's sponsor is an AI code [02:00] review app. Wait, no, don't go. Trust [02:01] me, this one's actually different. [02:03] Macroscope's been blowing me and my team [02:04] away. It's quickly become Julius's [02:06] favorite tool that I've added to our [02:08] code bases. It's what we run on T3 Code [02:10] and Julius loves it there. But that's [02:12] not my favorite part. My favorite part [02:13] is all the cool status stuff they do. [02:15] Keeping track of what my team is doing [02:17] is hard as small as the team is because [02:18] Julius just ships so much. Not only does [02:21] it estimate how much time people are [02:22] spending coding, which gets broken by [02:24] Julius's absurd output. 413 hours sounds [02:27] insane, but when you see his commits, [02:28] you understand what it means there. The [02:30] thing that's way cooler that it gives me [02:32] is the status updates that show what my [02:34] team's been up to. Over the last week, [02:36] Julius has added multi-provider source [02:38] control for T3 Code, PI extensions, and [02:40] VS Code themes, T3 chat, model routing, [02:43] billing, and UX, desktop effect [02:45] framework rewrite. All of these things [02:48] that just I wouldn't know about because [02:50] it's hard keeping track of everything [02:51] moving on my team that it gives me as [02:53] the lead. It's super useful. And being [02:55] fully transparent, I've made hard [02:56] decisions about team structure stuff [02:58] around the results I got from this cuz [02:59] it gave me so much better insight on [03:01] what's going on. The review side's even [03:03] cooler, though. The run agents are [03:04] genuinely awesome. You can [03:05] programmatically set up specific like [03:07] lint rule style things you want in your [03:09] codebase as a directory and then it just [03:12] runs with macroscope. Just create the [03:14] file in macroscope, describe what you [03:16] want it to do and what files you want it [03:17] to check and it will now run this on [03:19] every single code review going forward. [03:21] Ben's been using this a ton on his [03:23] projects. In particular, he's been using [03:24] it for automatic PR labeling, surfacing [03:26] reviews, correctness checks, and all the [03:28] usual stuff that you would expect. The [03:30] PR labeler in particular is really [03:31] useful. I hadn't seen this till now. [03:33] just showed it to me and I think I'm [03:34] going to go add this to T3 Code. It [03:36] would be super helpful over there. It's [03:37] cool when I figure out my sponsors are [03:39] even better than I thought they were [03:40] when I'm filming the ad because they [03:42] paid me to talk about them. They didn't [03:43] pay me to do this. See why I like them [03:45] so much at soy.cope. [03:47] First, I want to start with Claude Code [03:49] because it's the one that people seem [03:51] the most familiar with nowadays. It's [03:53] what people think of now when they think [03:54] about coding with AI. It has pretty much [03:57] fully taken the mental position in the [04:00] space that cursor used to have. Like I [04:03] remember in the YC batches where 90% of [04:05] the batch was using cursor. Now it's [04:07] like 70%'s using cloud code. The shift [04:09] happened very aggressively. So how [04:12] should we be thinking about cloud code? [04:14] The goal of cloud code was initially [04:16] Boris's attempt to think into the [04:18] future. What could code look like if the [04:21] models were way smarter? How would I [04:23] want to use these things? In a world [04:25] where people are going to claw.ai, [04:26] pasting some code, asking the model for [04:28] thoughts, getting some changes, then [04:30] copy pasting them back into the [04:31] codebase, it was obvious that there was [04:33] room to improve. And cursor had made [04:35] some improvements there, especially with [04:36] like the chat interface in cursor where [04:39] you could talk to the model about the [04:40] code and watch it go make those changes. [04:43] Cloud code was different for a handful [04:45] of reasons. The biggest by far being [04:47] that it was built to work in your [04:49] terminal. Instead of forcing you to [04:51] adopt a whole new workflow, instead of [04:53] forcing you to switch over your IDE to [04:55] some other thing, instead of making you [04:57] install a different app or write code in [04:59] a different way or move everything to [05:00] the cloud, cloud code met developers [05:02] where they were, their terminals, and [05:04] they wanted to make a great experience [05:06] editing code with AI in your terminal. [05:08] This means they have a lot of inherent [05:10] compromises they have to deal with. [05:12] Things like pasting images will never [05:14] quite be elegant. You can't see the [05:16] thing you pasted. things like selecting [05:18] text and all of the weird spacing that [05:20] things have because they kind of have [05:22] to. I'm using the new full screen mode [05:24] to prevent flicker because the flicker [05:25] kills me. But the new full screen mode [05:27] is doing a whole different way of [05:29] rendering to the terminal which means [05:31] they have to fake all of the UI elements [05:33] themselves instead of using the [05:34] traditional scroll buffer behaviors. Has [05:36] it benefits, has it negatives, is what I [05:39] prefer when I use cloud code. They're [05:40] hoping to make this the default in the [05:41] future, but yeah, it's meant to just be [05:43] used in your terminal. I really want to [05:45] emphasize the adoption story that Cloud [05:48] Code is pushing. They want it to be as [05:51] easy as possible to get started using [05:54] Cloud Code. You paste the command to [05:56] install the CLI and now you're using it. [05:58] You do have to go off quick with your [06:00] browser or paste an API key or something [06:02] along those lines. Initially, it was API [06:03] key only, which is still crazy to think [06:05] about, but the whole idea is that it's [06:07] easy to set up and use without having to [06:09] change any of your other tools. You [06:10] would spin up cloud code, make changes, [06:12] go look at them in VS Code, commit them, [06:13] do whatever you want. It would just be [06:15] another tab in your terminal. But over [06:17] time, as you can guess, people wanted [06:20] more. People wanted things like [06:22] automatic git commits and automatic [06:24] pushes to GitHub and noticing when [06:26] changes happen in your PRs. People [06:28] wanted to connect Cloud Code to other [06:30] sources of information through things [06:32] like MCP. People wanted Claude code to [06:34] be able to be triggered remotely in [06:36] order to control it from their phone or [06:38] use it in a better UI and all these [06:39] types of things. People wanted Cloud [06:41] Code to be able to do more work at once [06:42] and work on things in parallel. [06:45] Anthropic tried to not overstep in this [06:48] way initially, but at some point, I [06:51] don't really know what changed. They [06:53] started to embrace this stuff much more. [06:55] They had things that would let you build [06:57] into cloud code like their hook system [07:00] that kind of stopped being iterated on. [07:02] some of my fun demos I built with cloud [07:04] code back when I was using it more like [07:06] the app that would only let you use your [07:08] browser and things like Twitter if you [07:10] had something running and whenever your [07:12] agent finished it would lock you out of [07:13] Twitter until you went and responded to [07:15] get it running again. A lot of those [07:17] things had rough edges because the hook [07:19] system wasn't fully implemented. I would [07:22] say the moment of no return like the oh [07:24] [ __ ] moment for cloud code was [07:26] definitely when Opus 45 came out at the [07:28] end of last year. That jump in model [07:31] capability made it much more compelling [07:34] to give a model access to everything [07:36] through the terminal. The idea that I [07:38] could GP through your codebase to find [07:39] things, that I could run commands to [07:41] deploy things, that it could use MCP to [07:43] get data and do so much more made it way [07:47] more pleasant to use. And I found myself [07:49] leaning into Cloud Code way more heavily [07:52] because I could trust the code more. So [07:53] I didn't need a UI where I was reading [07:55] it actively. I did want a terminal [07:57] because I wanted it to have access to [07:59] all the things you can do in a terminal. [08:01] And the biggest thing you might notice [08:02] at the bottom here, bypass permissions [08:04] on the model got smart enough that I [08:06] could trust it to not run malicious [08:08] commands very often, if at all. And now [08:10] to this day, I run almost all of these [08:12] tools in bypass mode or yolo mode or [08:14] something along those lines. Opus45 was [08:17] good enough to cause a huge industry [08:19] shift where lots of people started [08:20] leaning into cloud code more because the [08:22] model caught up with this style of tool [08:26] and this was a huge moment for anthropic [08:28] especially in places like Twitter. They [08:31] also noticed what types of things would [08:34] perform well on Twitter. People love [08:35] terminals. People love doing cool things [08:38] with agents. People love when their [08:40] tools get better without doing anything. [08:42] and they love this feeling of the stuff [08:44] they rely on and love improving. And I [08:46] am going to drop a somewhat [08:48] controversial take here that I've said [08:49] many a time. Cloud code is as much a [08:52] marketing tool as it is a developer [08:54] tool. Anthropic is largely using Claude [08:56] Code to push the idea that Anthropic is [08:59] the best thing to use for building with [09:01] AI. A lot of the features and the cool [09:04] stuff they add to Cloud Code is really [09:07] optimized for the Twitter screenshot. [09:09] Things like the pet mode that they added [09:11] was definitely so people would [09:12] screenshot their numbers and share them [09:14] on Twitter. Things like the sub agent [09:16] mode burns your tokens super hard, but [09:19] it looks and most importantly feels [09:22] super productive. I remember the first [09:24] time I spun up a bunch of sub aents in a [09:26] team. It felt incredible to have so much [09:29] stuff happening with so little work on [09:31] my part. Cloud code is really optimized [09:33] for that feeling of productivity. It [09:36] really feels almost gified. Little [09:39] things like the cute guy in the corner [09:40] here. The way stuff shows in the UI. The [09:43] way that the teams spin up and check [09:45] things out. I'll test an example here. [09:47] Spin up a sub agent for each example [09:52] project here and audit it for [09:55] opportunities [09:56] to streamline the cloud code experience. [10:00] Even though I'm in the mode that is [10:02] supposed to hide my email address, it [10:04] still docks my email there. Thanks, [10:06] Anthropic. We'll try again. [10:09] See how much is happening in the UI [10:11] here. You see the tokens going up as it [10:14] goes. It has these little updates. It [10:16] has the loading states. It has the dots [10:18] flickering. It feels like it's doing a [10:21] lot. And now it's going to launch the [10:23] audit sub aents that it will spin up for [10:25] these different things. And we can see [10:26] at the bottom here, we can switch to [10:28] those sub aents and see what they're [10:30] doing. It feels really cool and really [10:32] productive. There's a lot going on. [10:35] That's kind of the point. Claude Code [10:37] wants to feel really productive, but it [10:40] also to be frank, they are trying to [10:42] make it better and they're trying to [10:44] make it more capable, but generally [10:46] speaking, Anthropic's philosophy around [10:48] how to make the tool do smarter things [10:51] is to let it burn more tokens. And [10:54] things like all the sub aent stuff, and [10:56] everybody's already saying this in chat, [10:57] five minutes later, you're down $200. [10:59] Token, token, token. You spend two hours [11:01] trying to fix this. Yeah, you guys get [11:03] the idea. It's very willing to burn [11:05] tokens in the interest of doing things [11:09] in a way that looks and feels really [11:12] productive and to be frank often can be. [11:14] A lot of the improvements they're trying [11:16] to make to cla code are finding new ways [11:19] to burn tokens to potentially solve work [11:22] and do more in cooler ways, but also, [11:25] let's be frank, to look really cool for [11:27] screenshots and demos on Twitter. This [11:30] is also why in my opinion, Anthropic is [11:32] much less interested in letting you [11:34] integrate cla [11:39] token maxing so hard that anything [11:42] spinning it up programmatically risks [11:45] absurd compute usage that they don't [11:47] want. Imagine setting up a tool similar [11:48] to what I just did there where I ask it [11:50] to spin up sub agents to check things, [11:52] but you implement that in your CI [11:54] process whenever a pull request is [11:56] formed on your project. Then you're [11:57] going to burn a shitload of tokens. you [11:59] might not mean to. And that's a thing [12:01] Anthropic doesn't want you to do. If [12:03] you're burning tokens with cloud code, [12:05] they want it to look and feel productive [12:08] because that's what they're trying to [12:09] sell. They are eating a bunch of token [12:11] spend to trade off the feeling of being [12:14] really, really productive. And if you're [12:16] not looking at the anthropic cloud code [12:18] UI, when that happens, it feels much [12:20] less productive. They're not getting [12:22] what they're trying to here. This is [12:23] also why things like their desktop app [12:25] are heavily underinvested in. This is [12:27] also why things like T3 Code aren't as [12:30] interesting to them and why they're not [12:32] letting us programmatically call the [12:34] Cloud Code CLI anymore without charging [12:36] you way more money. They want you in [12:38] their CLI using their features, having [12:40] their experience and they also want you [12:42] building integrations into Cloud Code [12:44] itself. Because if a tool like T3 code [12:47] provided other skills or provided other [12:50] resources, MCPS, etc., and then I can [12:52] switch over to codeex and not have those [12:55] things get stuck in cloud code. They [12:57] actually come over when I switch between [12:58] providers. Cloud isn't getting the lock [13:00] in that anthropic wants it to get. So [13:02] they really optimize for that. Cloud [13:04] code is meant to be the world's greatest [13:06] showcase of what you can do with [13:08] anthropic models at a lot of cost to [13:10] anthropic in order to win a bunch of [13:12] sentiment so people feel and arguably [13:14] are more productive using cloud models [13:17] in anthropics tools. And you can bet [13:19] your ass they went hard modifying the UI [13:21] to make it feel this productive. A lot [13:23] of the performance issues that used to [13:24] exist in Claude Code were because they [13:26] were doing all these fancy loading [13:28] spinners and things which resulted in [13:30] the performance being degraded which was [13:32] a hit they were willing to take because [13:34] they were optimizing so hard for the [13:36] feeling. Hey to those in chat saying I'm [13:37] being too nice. I'm trying to be because [13:40] I'm not trying to shame people who like [13:42] Claude Code and are using Cloud Code. [13:44] They engineered it to be like a slot [13:46] machine. They did a great job at it. It [13:48] got me addicted to doing agentic coding. [13:51] I wouldn't have gone as hard as I did at [13:52] the end of last year and the start of [13:54] this year if it wasn't for quad code [13:57] optimizing itself for this type of [13:58] thing. Let's contrast this with codeex. [14:01] I have it on medium fast which is way [14:04] faster than quad code. So I'll actually [14:06] turn off fast mode actually. And now I'm [14:09] going to paste that same prompt. Spin up [14:10] a sub agent for each example project [14:12] here and audit it for opportunities to [14:13] streamline. There is so much less going [14:16] on here. You have a timer. You have the [14:18] working text that's slightly animated [14:21] and nothing else. It did spin up these [14:23] two subprocesses, but I don't see [14:26] anything going on in them. It's very [14:28] minimal. This is way less addicting is [14:31] the way I would put it. And we sit and [14:33] wait and wait. It's not trying to feel [14:37] like a slot machine. It's not trying to [14:39] feel crazy. It's just trying to get work [14:42] done. And when you look at the types of [14:45] features that are being added across [14:46] these tools, you will really quickly see [14:49] this difference. Just as an example of [14:51] one of the recent things they shipped in [14:52] Claude Code, they added SL radio, which [14:56] opens a 247 lowfi Claude music stream. [15:00] Like I'm not going to sit here and say [15:02] this is cringe or cool or whatever. I [15:05] just think it shows the philosophy of [15:08] what and how they are building. like [15:10] they really are optimizing for the [15:13] feeling of productivity and the killer [15:15] thing to post on Twitter. Like you you [15:18] know that in the feature review process [15:20] at the company, they are thinking about [15:22] what does the tweet look like before [15:23] they build the feature. Meanwhile, let's [15:25] compare that to the official OpenAI [15:27] developers Twitter, which is mostly just [15:29] Codex updates. Now, this tweet did way [15:32] fewer numbers. 8.2K likes. Codex [15:34] anywhere and everywhere all the time. [15:36] Now, your Mac doesn't need to be [15:37] unlocked for Codex to use your computer. [15:39] This feature is not very flashy. This [15:41] feature is inside of the settings [15:44] computer use section in codeex. You have [15:47] to go hit this switch in there and then [15:50] nothing cool happens. You literally [15:52] can't screenshot this feature because it [15:53] happens when your Mac is locked. But it [15:55] makes you way more actually productive. [15:58] Let's keep scrolling. Ship paper cut. [16:01] New diff marker settings in appearance. [16:03] If you prefer the classic plus minus, [16:05] you can turn that on. Otherwise, it'll [16:06] just be colorcoded. This is not flashy [16:08] at all. This got 900 likes, but it's [16:11] real and practical. They added a feature [16:14] where Codeex can bind a double command [16:16] hotkey to copy what you're currently [16:19] looking at in your app and throw it over [16:21] to Codeex to populate the context. I [16:24] love this. I'm a big fan of using [16:26] screenshots as context. And having a [16:28] built-in thing like this is great. Like, [16:30] it's practical stuff that doesn't [16:32] demogate because the point of these [16:34] things aren't to be cool demos on [16:36] Twitter. It's to be frank to solve real [16:39] problems that they have as they are [16:41] building software using these things. [16:43] Even computer use itself being such a [16:45] core part of codecs. It didn't make that [16:48] much sense to me. It seemed like it was [16:50] one of those things that sounded really [16:52] good but just wasn't that practical. But [16:54] similar to how cloud code wasn't useful [16:55] until the models got good enough, [16:57] computer use really wasn't useful until [16:59] the models got good enough as well. And [17:00] now that 55 is really smart at these [17:03] things and I also have a dedicated Mac [17:05] Mini in the other room that I use for a [17:08] lot of my code tasks, Codeex being able [17:10] to use computer use to go verify its [17:13] changes is awesome. And it's way more [17:15] likely that by the time Codex tells me [17:17] it's done with a task that it actually [17:19] did the task correctly. This is also [17:21] where another big philosophical [17:22] difference comes in where they want to [17:25] use these tools. The vast majority of [17:28] people at Anthropic using Cloud Code are [17:30] using it in the CLI. The vast majority [17:32] of people using Codeex at OpenAI are [17:35] using it through the app. Funny enough, [17:37] a lot of my friends at OpenAI are [17:39] non-technical. They're not devs. They're [17:41] on marketing and whatnot. They all use [17:43] Codeex, the app, and they use it for all [17:45] sorts of cool things because this [17:47] interface is a big part of how they [17:50] work. And it still is optimized to just [17:53] be a good experience, not to be a flashy [17:57] experience. Like again, I'll do the same [17:59] demo I did before. I'm just going to [18:01] tell it to spin up a sub agent in this [18:03] project to audit all of the examples. [18:06] There is very little going on in this [18:07] UI. There is just the thinking here. [18:10] Now, it's going to do a search. It's [18:11] going to go check things. It's not [18:13] trying to be flashy. It's trying to be [18:15] productive. Let me update to the latest [18:17] cloud app so it's less likely to break. [18:19] Oh, great. I have to sign in again. [18:20] Wonderful. Who would have thought? Why [18:22] is it doing it through [ __ ] Safari? I [18:25] [ __ ] hate Anthropic, man. This is so [18:27] bad. I have to manually enter all this [18:29] [ __ ] cuz I don't have one pass on the [18:31] like inapp safari and it doesn't work [18:33] with my pass key through one pass. This [18:36] is horrible. Holy [ __ ] You can tell [18:39] they don't use it. Like they just [18:40] straight up do not use the desktop app. [18:43] Even better, I'm now in. But it says at [18:45] the top right, failed to log in. It may [18:46] have been cancelled. They they don't use [18:48] this app. I don't know how else to say [18:49] it. They clearly do not use this app. [18:52] I'll update to the latest and hopefully [18:53] the problems will go away, but it's [18:54] probably just going to reveal my email [18:55] again. There we go. We have chat [18:58] co-working code. Also, the first thing I [19:00] noticed is that all the threads I did in [19:02] the CLI aren't here. It doesn't sync [19:04] across. The codeex one does. Just an [19:07] annoying thing. How do I even add a new [19:09] project in here? I don't know how to add [19:11] a new project, guys. Do I need to like [19:14] select here? [19:17] Why does it start in the root, not where [19:19] I already was? So much more is [19:21] happening. You have the fancy animations [19:23] for the text here. You have the token [19:24] number bouncing up all the time. The [19:26] counter, the super flashy different [19:29] shaped star there that stays when it's [19:32] done, by the way, too. So, it's hard to [19:33] know when it's actually completed. It's [19:35] just a lot. And it took so much effort [19:38] to even like get this project added. [19:40] It's They didn't build this app for you [19:42] to use it. They built this app so that [19:44] it would exist if people stop asking for [19:46] it. Personally, I'm not that into the [19:48] slot machine feel that Claude Code seems [19:51] to be going for. I much prefer simple, [19:53] reliable solutions you can really trust, [19:55] like today's sponsor. Got to be so real [19:57] with you guys. Hiring sucks right now. [19:59] The quality of the résumés coming in [20:00] looks like it's gone up, but it's all [20:02] just slop. And the volume of RS coming [20:04] in is absurd. Like 10 to 100 times more [20:07] than I've ever seen. Finding good [20:08] engineers is really hard. And then [20:10] convincing them to join even harder. [20:11] That's why G2I has become such an easy [20:13] recommendation for me. These guys get [20:14] hiring. They already have a network of [20:16] engineers that they know and trust and [20:18] they know them so well. That's why [20:19] companies like Batteround have moved to [20:20] G2I for their hiring. They've already [20:22] hired nine senior engineers and they're [20:24] never going back. The biggest problem [20:25] they had was that the leadership at the [20:27] company had to spend so much time hiring [20:29] because finding good people requires [20:31] leadership, not a bunch of money spent [20:32] on recruiters that don't know what [20:33] they're doing. As they said, [20:34] Batteraround didn't need more resumes. [20:36] They needed fewer, better candidates [20:38] that they could evaluate quickly and [20:39] confidently. If this quote doesn't win [20:41] you over, then I don't think G2I is for [20:42] you. I think the best part is the [20:44] network, the vetting process, rather [20:45] than just the pedalling people, so to [20:47] speak. It's the biggest difference for [20:48] me. Before they use G2I, about 50% of [20:50] their hires were success cases, [20:52] according to them. But since moving to [20:53] G2I, they'd say the numbers are around [20:55] 90%. Stop wasting time and start hiring [20:57] quality at soy. G2I. This isn't just [21:01] about how it looks and feels to use the [21:03] thing. There's also a very practical how [21:06] they're thinking about the models and [21:08] where they're going aspect here. A lot [21:10] of the bets in the direction that [21:12] Anthropic is going in is as the models [21:15] get smarter, they should have the [21:18] ability to do more. Like if the agent is [21:21] smart enough and it can write its own [21:23] prompts for sub agents and just spin up [21:24] a bunch and let more tokens solve the [21:26] problem. Generally speaking, anthropic [21:29] strategy is if more tokens solve the [21:31] problem, use more tokens. And they are [21:33] very quick to look for ways to solve [21:35] problems with more tokens. Cloud code is [21:37] memory leaks on Windows. Go rewrite bun [21:40] and rust with a shitload of tokens. Like [21:43] it's insane how far they push that idea [21:45] that more tokens can solve the problem. [21:48] Open AAI does not go that way at all. [21:50] Okay. Also, like do you see how much [21:51] like the way that this updates is like [21:54] line by line, word by word in a way that [21:56] that feels very like visually engaging. [22:02] That's by design. They do all of this to [22:04] feel as exciting as possible. But the [22:08] again to the philosophy thing here about [22:09] the token usage, Anthropic will gladly [22:13] burn tokens. Whether it's yours or [22:14] theirs or anything else, they are more [22:16] than happy to come up with solutions [22:18] that require you burning way more tokens [22:20] to solve the problem instead of finding [22:22] better ways to solve and verify that the [22:24] problem is solved. OpenAI solution is [22:27] much different in this regard. You can [22:29] tell just from how many tokens they use [22:31] for things like the artificial analysis [22:33] bench. They are trying really really [22:36] hard to make their models more [22:37] efficient. 54 mini not the case. 54 mini [22:41] burns tokens. Sonnet 46 burns a similar [22:44] amount to mini. GBT54x high and opus 47 [22:48] burned a similar amount too, but GBT55 [22:51] used half as many tokens to get a better [22:53] score. OpenAI is trying way harder to be [22:56] token efficient, but they don't want to [22:58] compromise on the accuracy of the [23:00] solution. So, they're trying to find [23:02] ways to know if the code worked or not [23:04] using fewer tokens. And that's where [23:07] stuff like computer use is really [23:09] powerful. If the model can make a change [23:12] and then look at what it changed and [23:13] verify if it succeeded or failed, it [23:16] ends up being a lot less work than [23:18] spinning up 15 agents to go triple check [23:20] every line of code. This also means you [23:22] need to have an environment that works [23:24] well. This is one where the biggest [23:26] differentiators is. Anthropic very [23:29] excitedly sets up tools to let you [23:31] transport your thread from your machine [23:33] to the cloud to finish it up there. But [23:35] good luck getting the cloud environment [23:36] for cloud code to work properly. I tried [23:39] and gave up. And the advice I got from [23:41] my friends at Anthropic was, you don't [23:43] really need the agent to run the code. [23:45] Just throw the tokens at it. It'll [23:47] probably get things done just fine. But [23:49] when it doesn't, it sucks. And I like [23:51] using the cloud runners for big tasks [23:52] that I don't want to run on my machine. [23:54] So the fact that it is not really able [23:57] to verify the results because it doesn't [23:59] have the environment configured [24:00] correctly just kind of sucks. Codeex was [24:02] trying harder to get a good cloud [24:04] environment, but it seems like it's [24:06] become much lower priority. The easiest [24:09] example to see this is in the codeex [24:11] section of the chat GPT mobile app. They [24:14] hid the cloud option under like three [24:16] menus. They're really not optimizing for [24:19] cloud because they know how hard it is [24:20] to get most projects running properly on [24:22] the cloud, but you probably have it [24:23] running fine on your machine. They know [24:25] this because that's their own experience [24:27] building. They struggled to get everyone [24:29] at the company's projects working [24:31] properly in codeex on the cloud. So they [24:33] just made it so you can control your own [24:34] machine with your phone instead. [24:36] Anthropic's bet is the models will get [24:37] smart enough they don't even need to run [24:38] the code. They'll just write it [24:40] correctly. OpenAI's bet is it's so [24:42] annoying to configure things properly [24:45] that we should probably just use the [24:46] configuration you already have on your [24:48] machine. And now we need to talk about [24:49] the third option because their play in [24:52] the cloud is very interesting. It's kind [24:54] of crazy how quickly cursor went from [24:56] far and away first place to third. And I [24:59] honestly think a lot of that's cuz [25:00] people don't know where cursor's real [25:02] power is. You might notice my cursor [25:05] looks different from yours. It's cuz my [25:07] cursor is currently in the browser, not [25:09] the IDE. That's because cursor's cloud [25:12] stuff is so far ahead of any of the [25:15] competition other than maybe Devon. [25:17] Cursor cloud agents aren't just like a [25:20] crappy headless Linux sandbox that the [25:23] agent can use to try and execute your [25:25] code. The cursor sandbox spins up a full [25:28] graphical interface Linux instance that [25:32] it can use to run your full app the way [25:35] you would on a real computer and then [25:37] uses computer use to test the changes. [25:39] So here it ran the T3 code codebase and [25:42] then launched the browser version [25:44] because it's exact same as the version [25:45] that you would run in the electron shell [25:47] in order to test its changes as it made [25:50] them. But Theo, I already have a [25:52] computer. Why would I want to do that? I [25:54] understand. When I'm on my phone, I [25:56] didn't set up a computer to control [25:57] remotely. It's very nice to be able to [25:58] go spin this off. If I want to work on [26:01] two different things that need computer [26:02] use at once, it's incredible to go spin [26:04] this off. There are so many use cases [26:06] where one computer is limiting because [26:08] one computer can only do one thing when [26:11] you're computer using it. And if it's [26:13] not on or not connected to the right [26:15] network or any of those other things and [26:16] you can't use it at all, you're just [26:17] kind of stuck. And there's something [26:19] legitimately magical about being in [26:21] Slack. Someone brings up a problem with [26:23] the product. You at the cursor bot and [26:26] say, "Hey, can you go spin up an agent [26:27] to fix this?" and it responds in the [26:30] thread with a video of the fix it [26:33] applied showing you that it worked. This [26:35] is so far ahead of anything that Cloud [26:38] Code or Codeex can do, it's insane. [26:42] Another way of thinking about this is [26:45] that Codeex is betting really hard on [26:47] where things are today. What is it like [26:50] using agents to code right now? How do [26:53] you make it more likely they succeed? [26:56] Anthropic is betting on where the models [26:58] will be in a few months. Also, where the [27:00] models they're using are because they're [27:01] all using Mythos. They are betting on [27:03] the models getting so smart that these [27:04] types of things matter less. Cursor is [27:08] betting way out in the future where [27:10] we're not running these things on our [27:11] computer at all. We are just triggering [27:13] them through whatever other tool we want [27:15] and then getting back proof that the [27:17] thing worked. That does bring up another [27:19] really important difference and probably [27:21] the most painful philosophical [27:23] difference between all of these things. [27:25] I mentioned this before, but I really [27:26] want to emphasize it. OpenAI uses the [27:29] Codeex app all of the time. There are [27:31] thousands of employees at OpenAI that [27:33] use this app every single day. The cloud [27:35] desktop app does not get anywhere near [27:36] as much love, largely because they're [27:38] all using the CLI instead. But there's a [27:40] problem here. The version and state of [27:43] things that anthropic employees are [27:45] using is very different from what we are [27:48] getting as end users. The model that a [27:50] lot of those employees are using is [27:52] mythos. We don't have that. They have a [27:54] custom build of cloud code with a bunch [27:56] of cool new hidden features in it that [27:58] we don't have access to. This is why we [28:00] end up with really embarrassing things [28:01] like system prompt stuff leaking because [28:04] the system prompt that they use [28:05] internally is different from the one [28:06] that we get in the apps that we use. [28:08] That's why I ran into problems like this [28:10] when I tried out opus 47 in the new [28:13] cloud code desktop app where I asked it [28:15] what are some design improvements I [28:17] could make on this site and it opens [28:18] with heads up the system reminder about [28:21] malware looks like a prompt injection. [28:23] This is clearly your personal site, the [28:24] T3G homepage, not malware. Ignoring it. [28:27] We're using something entirely different [28:29] from what they're using. And I don't [28:30] know how to properly emphasize this [28:32] because people just don't seem to get [28:33] that. You do not get the tool anthropic [28:36] employees get. You get what they feel [28:38] generous enough to give you and they are [28:40] not testing it reliably enough. This [28:42] leaks through the whole clot experience. [28:45] It is clear that this tool works great [28:48] for them and the portions of the thing [28:50] they're using that they cut off and [28:52] throw out to us are not tested well [28:54] enough. And the result is that we get [28:56] weird [ __ ] like this. I guarantee you [28:59] that one of two if not both of these [29:01] things is true. Either this system [29:03] prompt is not the one they were using [29:04] internally, which is very likely the [29:06] case, or this problem that I have here [29:09] just did not happen with Mythos, which [29:11] is what they were all using internally. [29:13] the model we're using, the system prompt [29:15] we're using, the harness we're using, [29:17] the UIs we're using, all of those things [29:20] are not the same thing that they are [29:22] using at Anthropic. Meanwhile, the Codex [29:24] app that we're using, the Codex models [29:26] that we're using, and the Codex plugins [29:28] and features and all of that that we're [29:29] using is the exact same thing that [29:32] they're using at OpenAI. I can't cite my [29:34] sources here, but you need to believe me [29:36] on this. I have friends at all of these [29:37] companies. It is very apparently the [29:39] case, and you can tell externally that [29:41] this is also the case. It's obvious. And [29:43] to their credit, Cursor is very similar [29:45] here. They use the [ __ ] out of the [29:48] things that they are doing. They [29:49] obsessively test every detail before [29:52] taking the exact thing they're using [29:53] internally and throwing it at us [29:55] externally. They even do crazy stuff [29:58] like disabling every model other than [30:00] the new composer model and not telling [30:02] people that they did that. So, everyone [30:04] thinks they're using Opus or GBT55 or [30:07] whatever, but they are dog fooding their [30:08] own thing to see what issues people run [30:10] into. The effort that cursor puts into [30:13] making sure things are good before they [30:15] put them out is insane. OpenAI is close [30:18] to that same level. They just have [30:20] issues. If if anything, the thing I've [30:22] experienced, which is funny, is that [30:24] they have [ __ ] versions internally at [30:26] OpenAI. Like I ran into problems with [30:28] GBD55 during testing because the [30:31] researchers didn't have the search tool [30:33] on because they don't want things [30:35] leaking, which I totally understand. The [30:38] the point being we get more than they [30:41] have. Cursor gives us exactly what they [30:43] have. Enthropic gives you less than they [30:45] have. That said, Cursor is not really [30:48] that focused on integrating with other [30:49] things. They did just throw out the [30:51] cursor agents SDK, which is like cool [30:54] and took them long enough to do it. [30:55] Anthropic is actively trying to push us [30:58] away from using our subs outside of [31:00] their UIs. Open AAI can't stop inventing [31:03] awesome standards we can build on top [31:05] of. Like to be really frank, my agentic [31:08] coding app T3 code that I built with [31:10] Julius, mostly Julius, this would not [31:13] exist if it wasn't for the codeex app [31:15] server, which is part of the open source [31:16] codeex CLI. They give us so much stuff [31:20] to build on top of and around. We are [31:22] building on top of the codec CLI the [31:25] exact same way the Codex app team is. I [31:27] am admittedly disappointed that the [31:29] Codex app itself isn't open source. I [31:31] wish it was. It's another big part of [31:32] why we built T3 codes. It was a good [31:34] open- source option, but we built on top [31:36] of the Codex app server, which was [31:37] awesome to build with. And the Codex [31:39] employees will just openly post on [31:41] Twitter like if you want to use Codex [31:43] for something different, tell your agent [31:44] to go to this repo and look at this [31:46] folder and it'll figure it out. Cursor [31:48] seems interested in building these types [31:50] of things, but historically hasn't done [31:52] that great of a job. When we wanted to [31:54] add cursor to T3 code, we had a lot of [31:56] problems because the recommended path [31:57] was through their agent client protocol [31:59] bindings that they had set up for the [32:01] CLI, but the cursor CLI was super behind [32:05] and the ACP stuff even more so. You [32:08] couldn't even pick modern models. We [32:10] tried setting this up a few months ago, [32:11] not even. And the most modern composer [32:13] model was one when two had already been [32:15] out for a while. They didn't have Opus [32:17] 46 or 47. They only had 45. They didn't [32:20] have any of the new sonets. They didn't [32:22] have any of the new GPT models. it was [32:23] super limited and they were all [32:24] hardcoded in so we couldn't pick newer [32:26] better models. We had to go back and [32:28] forth with the team for a while to get [32:29] them to fix that. They did end up doing [32:31] it and they ended up also putting out [32:32] the SDK. So it seems like they want to [32:33] make more of these integration things [32:35] but it's not a priority or focus for [32:36] them. Open AAI is heavily prioritizing [32:39] and focusing on this. Claude would [32:41] really rather you don't do this. [32:43] Anthropic is trying to keep you from [32:45] building integrations with cloud code [32:47] unless they're deep inside of cloud code [32:49] itself. OpenAI wants you to do whatever [32:50] the [ __ ] you want. They just want to see [32:52] people build the future using whatever, [32:54] especially if they're using their stuff. [32:56] Cursor wants that, but isn't [32:59] prioritizing it properly. One last piece [33:01] that I think is important to understand, [33:03] model improvements. Enthropic has to add [33:06] a bunch of features because their public [33:08] models haven't improved since December. [33:10] I still feel like 46 and especially 47 [33:13] are more so regressions than they are [33:15] improvements. A lot of why Codex has [33:17] improved is because the models got way [33:19] better. 52 to 53 to 54 to 55 were [33:23] massive improvements. In the time we [33:25] went from 52 to 55, we went from Opus 45 [33:28] to 47. So, Opus got worse twice and [33:31] OpenAI models got better three times. [33:33] That compounds massively. If you took [33:36] the same old version of the codec cli [33:39] that was around at the time and switched [33:41] it over to 55, it would feel incredible. [33:43] If you took the old version of Cloud [33:45] Code from the end of last year and tried [33:48] to use Opus 47 in it, it would probably [33:50] crash because Cloud Code was getting so [33:51] buggy, especially then with the [33:52] performance issues. But if you could get [33:54] it working, it would probably still feel [33:55] worse because the model was dumber and [33:57] less willing to do the types of work I [33:58] want to do. So Anthropic has to make up [34:00] for this somehow. And they're doing it [34:02] by doing a shitload of cool looking [34:04] features and trying to make moments [34:06] happen with cloud code. They're trying [34:09] really hard to seem like they're making [34:11] a lot of progress. And to be frank, [34:13] they're getting away with it. It's [34:15] working. People say things like this on [34:18] Twitter. The anthropic team is still [34:19] innovating the most in the harness layer [34:21] and it's not even close. The only reason [34:23] you think this is cuz they do better on [34:26] Twitter and they keep adding things cuz [34:28] they kind of have to. But since their [34:30] actual better model is mythos and [34:33] they're not releasing it for various [34:35] different reasons that we can conspire [34:36] about all day, their tool has to look [34:39] better because it's not able to improve [34:41] just from models getting better. [34:43] Separately, codeex is meaningfully [34:45] improving constantly. 55 itself is [34:48] enough of a reason to make the jump. [34:49] This is definitely very different from [34:51] other videos comparing these tools. I [34:53] know most of them just like send the [34:55] same prompt and compare how good the [34:57] answers are from all of them. Whatever. [34:59] If you like the model, you like the [35:00] model. If you like the tool, you like [35:01] the tool. The things I care about more [35:03] are where is the team going with this? [35:05] What problems are they trying to solve [35:07] with this? And can I trust this thing to [35:09] work well tomorrow like it does today? I [35:11] hope this helps give you a good answer [35:13] to those things. If you're still [35:15] primarily coding using a sidebar in VS [35:17] Code or Copilot or Cursor, please go try [35:20] any of these, especially the desktop [35:21] apps. They've gotten a lot better and [35:23] it's a much nicer way to code using AI. [35:26] I'm so blown away with how much I like [35:28] things like the codeex app or the T3 [35:29] code experience. It's just it's really [35:32] good. The models are just one piece of [35:34] this puzzle. And as great as the models [35:35] for anthropic might be, all these other [35:37] things matter, too. So, give these tools [35:39] a shot. See which ones fit your desires [35:42] and your workflows the best and go with [35:44] that. If you hate coding and you want it [35:47] to feel more fun as you do it, you want [35:49] to feel good and like you're productive [35:51] the whole time, Claude Code's actually [35:53] very good at that. If you need help [35:55] staying motivated, go hop in Cloud Code. [35:57] If coding is still scary to you, go try [35:59] out Cloud Code. It'll probably do a [36:00] great job at that. If you've been an [36:02] engineer for a long time and you want a [36:04] tool that mostly stays out of your way [36:05] and just gets [ __ ] done, Codeex is [36:08] phenomenal. It really feels like it's [36:10] buy and for engineers, and I hope it [36:12] stays that way. Believe me, if Codex [36:14] regresses, you'll hear it first for me. [36:16] And finally, with Cursor, I recommend [36:18] using it through the cloud side. The [36:20] Cursor cloud is incredible. It's so [36:22] powerful. does things I never would have [36:24] predicted that cursor could do or that [36:26] AI could do as a whole. It's also one of [36:28] the best solutions to set up for your [36:29] team so nontechnical people can kick [36:31] things off in Slack. It's really the [36:33] enterprise ready end to end solution. [36:37] Highly recommend trying it if you [36:38] haven't. The cloud stuff is so cool. So [36:40] to simplify, cloud code for unmotivated [36:43] devs or bad devs that want to feel like [36:45] they're productive. Codeex for skeptical [36:48] devs that want to use these tools in a [36:50] way that is productive and leans into [36:52] good workflows that they're already [36:53] probably doing. Cursor for people that [36:55] want to set their teams up for success [36:57] with cloud runners that are able to [36:59] solve real problems in simple ways using [37:01] tools inside of their Slack or whatever. [37:04] And to answer the final question from [37:06] chat, what about anti-gravity? It's a [37:08] great way to secure your future by [37:10] convincing your boss that AI is not [37:12] capable of doing anything at all. And it [37:14] is not useful for anything beyond that. [37:17] And if you're asking about PI, you don't [37:19] need this video in the first place. Go [37:21] play with the cool fun things. [37:23] Hopefully, this helps you understand the [37:24] benefits of all of these different [37:26] solutions, the philosophy of how they [37:28] are building these different things, and [37:30] the reasons why you might pick something [37:31] over another thing. But in the end, you [37:33] got to just try all of them and see what [37:35] maps to your workflow the best. and let [37:37] the tool shape your flow a bit too. When [37:40] I tried to treat Codeex like Cloud Code, [37:42] I didn't like it as much. When I let it [37:43] do its thing more, I ended up really [37:46] liking it. Hopefully, this has been [37:48] helpful. This is a very strange video [37:49] for me to make, but I hope that it is as [37:51] useful as I wanted it to be. Let me know [37:53] what you all think. And until next time, [37:55] he snirts.  ## 📺 Video ![](https://www.youtube.com/watch?v=JMYspR42HFM) ## Highlights - Some characterization of Claude Code as "slot machine" could be seen as dismissive rather than analytical - Note: 🔍 Fallacy: Ad Hominem #fallacy/ad-hominem --- # 📝 Full Notes (Deep-Read Analysis) # 🏷️ Title: Claude Code vs Codex vs Cursor (an honest comparison) ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ## 📝 Summary - Theo Browne analyzes the philosophical differences between three major AI coding tools: Claude Code, OpenAI Codex, and Cursor - Claude Code prioritizes user engagement and "feeling productive" through flashy UI elements and token-intensive features, optimizing for social media shareability - OpenAI Codex focuses on practical functionality and efficiency, prioritizing real productivity over visual appeal - Cursor leads in cloud-based agent development with full graphical Linux environments for testing - Key differentiator: Anthropic employees use internal tools (Mythos) different from public releases, while OpenAI/Cursor dogfood their public products - Bottom line: Choose based on workflow needs - Claude Code for motivation/engagement, Codex for experienced developers wanting efficiency, Cursor for team collaboration and cloud agents ## 📖 Main Content The comparison reveals fundamental philosophical differences in how these companies approach AI-assisted development. **Claude Code Philosophy**: Anthropic designed Claude Code as both a developer tool and marketing vehicle. It prioritizes the "feeling" of productivity through animated UIs, token-burning sub-agents, and features optimized for Twitter screenshots. The terminal-based approach offers easy adoption without changing existing workflows, but recent model improvements (Opus 4.5) enabled more aggressive token usage for potentially better results. **OpenAI Codex Philosophy**: OpenAI focuses on practical efficiency and token conservation. Codex emphasizes real productivity over visual engagement, with features like computer use for verification rather than spinning up multiple agents. The team dogfoods their own public tools, ensuring consistency between internal and external experiences. **Cursor Philosophy**: Cursor bets on cloud-first development with full graphical Linux environments that agents can control via computer use. This enables testing changes in real browser environments and triggering development work from mobile devices or Slack, pointing toward a future where local development environments become optional. ### Model and Integration Differences Anthropic hasn't meaningfully improved public models since December (Opus 4.6-4.7 are arguably regressions), requiring feature additions to maintain competitive positioning. Meanwhile, OpenAI's progression from GPT-5.2 to 5.5 provided substantial capability improvements. Integration approaches differ dramatically: Anthropic discourages external integrations to maintain platform lock-in, OpenAI actively supports building on their tools (like the open-source Codex CLI), and Cursor shows interest but historically under-prioritizes developer APIs. ## 🗒️ Notes #### ⏱️ [00:00:00](https://www.youtube.com/watch?v=JMYspR42HFM?t=0) Introduction - Philosophy over capabilities - Wants to break down philosophical differences, not just model intelligence comparisons - Personal experience switching from Claude Code to Codex changed development philosophy - Goals: explain how tools differ in core approach, not convince people to switch #### ⏱️ [00:03:12](https://www.youtube.com/watch?v=JMYspR42HFM?t=192) Claude Code origins and adoption - Boris's vision: what if models were way smarter? How would coding look? - Built for terminal use - meets developers where they are - Easy adoption story: paste command, install CLI, start using without changing other tools - Shift from 90% of YC batch using Cursor to 70% using Claude Code #### ⏱️ [00:06:45](https://www.youtube.com/watch?v=JMYspR42HFM?t=405) The Opus 4.5 turning point - Model capability jump made terminal access more compelling - Could trust model enough to run in "bypass mode" - Industry shift as model caught up to this style of tool - Anthropic noticed what performs well on Twitter #### ⏱️ [00:09:18](https://www.youtube.com/watch?v=JMYspR42HFM?t=558) Claude Code as marketing tool - "As much a marketing tool as it is a developer tool" - Features optimized for Twitter screenshots (pet mode, sub-agents) - Sub-agent teams feel incredibly productive but burn tokens aggressively - UI optimized for feeling of productivity - loading states, animations, token counters #### ⏱️ [00:13:30](https://www.youtube.com/watch?v=JMYspR42HFM?t=810) Codex philosophy contrast - Much less visual stimulation - timer and minimal animation - Not trying to feel like "slot machine" - just trying to get work done - Feature focus on practical improvements, not flashy additions - Examples: Mac unlock-free computer use, diff marker settings #### ⏱️ [00:18:45](https://www.youtube.com/watch?v=JMYspR42HFM?t=1125) Token usage philosophies - Anthropic: if more tokens solve the problem, use more tokens - OpenAI: trying to be more token efficient while maintaining accuracy - Computer use for verification vs spinning up 15 checking agents - GPT-5.5 used half the tokens of previous models for better results #### ⏱️ [00:22:15](https://www.youtube.com/watch?v=JMYspR42HFM?t=1335) Cloud environment approaches - Claude Code cloud runners often don't work properly - Anthropic advice: "don't really need agent to run code, just throw tokens at it" - Codex hides cloud option, focuses on controlling local machine - Different bets: models vs environment configuration #### ⏱️ [00:25:40](https://www.youtube.com/watch?v=JMYspR42HFM?t=1540) Cursor's cloud advantage - Full graphical Linux instances with computer use testing - Can work on multiple things requiring computer use simultaneously - Slack integration: mention bot, get video of fix being applied - Far ahead of competition in cloud agent capabilities #### ⏱️ [00:30:22](https://www.youtube.com/watch?v=JMYspR42HFM?t=1822) Internal vs external tools - Critical difference: what employees actually use vs what customers get - Anthropic employees use Mythos model and custom Claude Code builds - OpenAI employees use same Codex app customers get - Cursor team dogfoods their public tools extensively - System prompt leaks reveal internal/external inconsistencies #### ⏱️ [00:36:50](https://www.youtube.com/watch?v=JMYspR42HFM?t=2210) Integration and building ecosystem - OpenAI actively encourages building on their tools (open source CLI) - Anthropic pushes away from external integrations, wants MCP lock-in - Cursor interested but historically under-prioritized developer APIs - T3 Code built successfully on Codex app server #### ⏱️ [00:42:10](https://www.youtube.com/watch?v=JMYspR42HFM?t=2530) Model improvement trajectories - Anthropic models haven't meaningfully improved since December - Opus 4.6-4.7 feel like regressions vs improvements - OpenAI: GPT 5.2 → 5.5 massive improvements while Opus got worse twice - Anthropic compensates with features since they can't release better public models #### ⏱️ [00:45:30](https://www.youtube.com/watch?v=JMYspR42HFM?t=2730) Final recommendations - Claude Code: for unmotivated devs or those wanting to feel productive - Codex: for skeptical engineers wanting actual productivity and good workflows - Cursor: for teams wanting cloud runners and Slack integration - All better than sidebar coding in VS Code - try the desktop apps ## 📚 References - [Claude Code CLI](https://claude.ai) - [OpenAI Codex](https://openai.com/codex) - [Cursor IDE](https://cursor.sh) - [T3 Code](https://t3.gg) - Theo's agentic coding app built on Codex - Macroscope AI code review tool - G2I engineering hiring platform ## 🗣️ Paraphrase Theo argues that the real differences between major AI coding tools lie not in their underlying models, but in their fundamental philosophies about developer experience and productivity. Claude Code operates as much as a marketing vehicle as a developer tool, prioritizing engagement and social media shareability through flashy animations and token-intensive features that create a "slot machine" feeling of productivity. OpenAI's Codex takes the opposite approach, focusing on practical functionality and token efficiency while maintaining the same experience for both internal employees and external users. Cursor stands apart by betting on cloud-first development with full graphical environments that enable sophisticated testing and team collaboration workflows. The most concerning revelation is that Anthropic employees use significantly different internal tools (including the unreleased Mythos model) compared to what customers receive, while OpenAI and Cursor teams dogfood their public products. This creates a disconnect between development priorities and user needs at Anthropic that manifests in reliability issues and feature misalignment. ## 📰 Newsletter **AI Coding Tools: Beyond the Model Wars** 🤖 This week, Theo Browne dropped a fascinating analysis that cuts through the typical "which model is smarter" comparisons to reveal the philosophical differences driving Claude Code, OpenAI Codex, and Cursor. The key insight? Your choice shouldn't be based on model capabilities alone, but on how these tools approach developer experience and productivity. **The Big Three Philosophies:** - **Claude Code**: Optimized for engagement and "feeling productive" - great if you need motivation or find coding intimidating - **Codex**: Built for efficiency and real productivity - perfect for experienced developers who want tools that stay out of their way - **Cursor**: Leading the cloud-first future with full graphical Linux environments for testing **WordPress Developer Takeaway**: If you're building WordPress plugins or themes, consider how these tools handle environment setup and testing. Cursor's cloud runners could be game-changing for testing across different WordPress configurations, while Codex's local-first approach might better match your existing workflow. **Worth Exploring**: [Macroscope's AI code review](https://soy.cope) for automated WordPress coding standards checks, and [G2I's vetted developer network](https://soy.g2i) for WordPress specialist hiring. The future of coding with AI isn't just about smarter models - it's about tools that understand how developers actually work. Choose accordingly! 🚀 ## ✅ Action Items #### DevRel - Research integration opportunities between WordPress development workflows and AI coding tools - Create content comparing AI coding tools for WordPress developers specifically - Develop workshops on incorporating AI agents into WordPress plugin development cycles #### WordPress - **Core**: Evaluate how AI coding tools can improve WordPress core contribution workflows - **Plugins**: Test AI tools for automated WordPress coding standards compliance checking - **Themes**: Explore AI-assisted responsive design testing across different environments - **Community**: Create guidelines for AI tool usage in WordPress development best practices ## 🧪 Hypotheses 1. **Tool philosophy predicts long-term adoption**: Developers will gravitate toward tools that match their experience level and productivity preferences, regardless of underlying model capabilities 2. **Internal/external tool parity drives quality**: Products where employees use the same tools as customers will have better reliability and feature alignment 3. **Token efficiency becomes competitive advantage**: As AI coding becomes mainstream, tools that achieve results with fewer tokens will have better unit economics and adoption 4. **Cloud-first development will dominate team workflows**: Remote development environments will become standard for collaborative coding projects 5. **Integration ecosystem determines platform lock-in**: Tools that encourage building on top of them will capture more developer mindshare than closed platforms ### 📊 Methodology - **Comparative user studies**: Test developer productivity and satisfaction across different AI coding tools with controlled tasks - **Token usage analysis**: Measure token consumption for equivalent coding tasks across platforms - **Integration ecosystem mapping**: Analyze third-party tool development and adoption rates around each platform - **Long-term adoption tracking**: Survey developer tool preferences over 6-12 month periods to identify switching patterns ### ❓ Questions - How do token costs impact developer tool selection as AI coding becomes more mainstream? - What role does visual feedback play in developer motivation and learning when using AI tools? - How will cloud-based development environments affect security and IP protection concerns? - Can token efficiency improvements offset the need for flashy engagement features? ### 🔮 Future Research - Impact of AI coding tools on junior developer skill acquisition and learning curves - Enterprise adoption patterns for different AI coding philosophies - Integration between AI coding tools and existing DevOps/CI-CD pipelines - Economic models for AI-assisted development at scale ### 💡 Implications - **Practice**: Developers should choose AI tools based on workflow compatibility, not just model performance - **Education**: Training programs need to consider how different AI tools affect learning and skill development - **Enterprise**: Companies should evaluate AI coding tools based on team collaboration needs and integration requirements - **Industry**: The AI coding tool market will likely fragment along philosophical lines rather than converging on a single approach ## 🧠 Learning Styles Assessment **Reading level estimate**: Grade 12 (Flesch-Kincaid) - technical content with clear explanations and concrete examples #### 👀 Visual learners - **Present**: Screenshots of different tool interfaces, token usage comparisons, feature demonstrations - **Improve**: Side-by-side workflow diagrams, decision tree for tool selection, visual token burn rate comparisons #### 🔊 Aural learners - **Present**: Video format with detailed narration and explanation - **Improve**: Audio-only version focusing on philosophical differences, podcast-style discussion format #### 🗣️ Verbal learners - **Present**: Clear definitions of tool philosophies, analogies (slot machine vs efficiency), terminology explanations - **Improve**: Glossary of AI coding terms, comparison tables with plain language descriptions #### 🧩 Kinesthetic learners - **Present**: Hands-on tool demonstrations, step-by-step usage examples - **Improve**: Interactive tool comparison checklist, downloadable trial workflows for each platform #### 🧠 Logical learners - **Present**: Clear categorization of tool philosophies, systematic feature comparisons, decision frameworks - **Improve**: Flowchart for tool selection, cost-benefit analysis template, integration compatibility matrix #### 🧑‍🤝‍🧑 Social learners - **Present**: Discussion of team workflows, collaboration features, community adoption patterns - **Improve**: Team evaluation worksheet, discussion prompts for developer teams, peer review guidelines #### 🧘‍♀️ Solitary learners - **Present**: Self-contained analysis, personal workflow considerations, individual decision framework - **Improve**: Personal tool evaluation worksheet, reflection prompts for workflow analysis #### 🌿 Naturalistic learners - **Present**: Tool ecosystem thinking, organic adoption patterns, natural workflow integration - **Improve**: Ecosystem impact analysis, sustainable development practice connections ## 📊 Accessibility Assessment #### Screen reader semantics - **Present**: Video has clear verbal descriptions of UI elements and workflows - **Improve**: Full transcript with image descriptions, heading structure for navigation, alt text for tool screenshots #### Keyboard navigation - **Present**: Tools discussed generally support keyboard navigation - **Improve**: Specific accessibility comparison between AI coding tools, keyboard shortcut guides #### Contrast and readability - **Present**: Video content clearly visible - **Improve**: High contrast screenshots in documentation, text size guidance for tool interfaces #### Media and captions - **Present**: Full transcript available, clear audio narration - **Improve**: Time-stamped captions, downloadable transcript with section breaks #### Standards reference - **Gaps**: WCAG 2.2 AA compliance assessment needed for each tool's interface ## 🌍 DEIB Assessment #### Cultural breadth - **Present**: Focuses on developer workflows across different experience levels - **Improve**: Examples from different types of development (mobile, web, enterprise), global developer perspective #### Inclusive language - **Present**: Generally uses accessible technical language with explanations - **Improve**: Avoid terms like "bad devs," provide more welcoming language for beginners #### Neurodiversity support - **Present**: Structured comparison format, clear categorization - **Improve**: Consider how different AI tool interfaces support various cognitive styles and attention patterns #### Representation - **Present**: Focuses on tool capabilities rather than user demographics - **Improve**: Include perspectives from developers with different backgrounds and accessibility needs #### Psychological safety - **Present**: Respectful discussion of tool trade-offs without shaming user preferences - **Improve**: Emphasize that tool choice should match individual workflow needs without judgment ## ✅ Logical Validity #### Strong reasoning - **Deductive strength**: Clear categorization of tool philosophies based on observable features and company behavior - **Inductive evidence**: Multiple examples support claims about each tool's priorities (UI choices, feature development, token usage) - **Causal reasoning**: Links model improvement trajectories to tool development strategies effectively #### Fallacies - **Ad hominem tendency**: Some characterization of Claude Code as "slot machine" could be seen as dismissive rather than analytical - **Survivorship bias**: Focus on successful tools may miss lessons from failed AI coding experiments - **Confirmation bias risk**: Author's preference for Codex may color interpretation of comparative evidence #### Tone of voice - **Analytical but opinionated**: Technical expertise combined with clear preferences, maintains educational focus while expressing strong views about tool design philosophy ## 🛡️ DARVO Analysis No DARVO patterns detected. The analysis maintains focus on tool comparison without deflecting criticism or reversing accountability relationships. ## 🎯 Conclusion The choice between AI coding tools ultimately comes down to workflow philosophy rather than raw model capabilities. Claude Code excels at engagement and motivation through visually rich interfaces, making it ideal for developers who benefit from active feedback and gamification. Codex prioritizes practical efficiency and real productivity, better suited for experienced developers who want tools that enhance rather than distract from their existing workflows. Cursor leads in cloud-based collaboration and testing capabilities, pointing toward a future of distributed development environments. The most significant concern raised is the gap between internal and external tooling at Anthropic, which may explain reliability issues and feature misalignment in Claude Code. Organizations evaluating AI coding tools should prioritize platforms where the development team actively uses the same tools they're selling, ensuring better alignment between features and user needs. For WordPress developers specifically, consider how these tools integrate with your existing development environment and testing workflows. The future of AI-assisted development will likely involve multiple specialized tools rather than one-size-fits-all solutions. --- # 📄 Full Transcript *Auto-generated from YouTube captions · timestamps roughly every 30 seconds · [watch on YouTube](https://www.youtube.com/watch?v=JMYspR42HFM)* **[00:00]** This is not going to be my usual video. I want to try and break down the real differences between things like cloud code, codecs, and cursor. Not in the like how smart are they sense or what tasks are they capable of sense. I want to break down the philosophy differences between these solutions because I find that they are way more different than people seem to think. I know that we've all used cloud code and codecs and maybe you've even tried out the cursor CLI, maybe you use their IDE, maybe you use their cloud environment. Whatever it is, many of you guys have tried all of these tools. Many of you haven't tried some of them for a while. Many of you have one **[00:31]** that you really like and you don't bother with the others. And if that's the case, I get it. If you're already using Claude Code and you're happy, I'm not here to try and change your mind. I want to try and explain philosophically what all of these things are trying to do and how they differ. My main reason for doing this is my own philosophy has changed around doing agent development since I moved from Claude over to Codeex. Obviously, it also changed when I moved from cursor to cla code, but it's changed in a way that I like a lot more this time. And I find that when **[01:01]** people are talking about these things about cloud code versus codecs, they're often just talking about the model or how the UI looks and not about how different the core of these things are and how differently the teams building them are thinking about how we make software. To be more direct, this video is happening because this reply on Twitter got way more attention than I expected as I broke down some of the philosophical differences between how Anthropic and OpenAI are thinking about their coding tools. But I wanted to go way further than I did here. I want to **[01:32]** really break down how these tools differ, how they can be applied effectively in your work, and where I think they might be going long term. I'm going to do my absolute best to present as unbiased as possible because again, my goal here isn't to try and convince you to switch to a different tool. It's to try and help you understand what the different tools are meant to be built for and who they might be best used by. I don't want to sell you anything, okay? I do want to sell you one thing. Today's sponsor. Today's sponsor is an AI code review app. Wait, no, don't go. Trust me, this one's actually different. **[02:03]** Macroscope's been blowing me and my team away. It's quickly become Julius's favorite tool that I've added to our code bases. It's what we run on T3 Code and Julius loves it there. But that's not my favorite part. My favorite part is all the cool status stuff they do. Keeping track of what my team is doing is hard as small as the team is because Julius just ships so much. Not only does it estimate how much time people are spending coding, which gets broken by Julius's absurd output. 413 hours sounds insane, but when you see his commits, you understand what it means there. The thing that's way cooler that it gives me is the status updates that show what my **[02:34]** team's been up to. Over the last week, Julius has added multi-provider source control for T3 Code, PI extensions, and VS Code themes, T3 chat, model routing, billing, and UX, desktop effect framework rewrite. All of these things that just I wouldn't know about because it's hard keeping track of everything moving on my team that it gives me as the lead. It's super useful. And being fully transparent, I've made hard decisions about team structure stuff around the results I got from this cuz it gave me so much better insight on what's going on. The review side's even cooler, though. The run agents are genuinely awesome. You can **[03:05]** programmatically set up specific like lint rule style things you want in your codebase as a directory and then it just runs with macroscope. Just create the file in macroscope, describe what you want it to do and what files you want it to check and it will now run this on every single code review going forward. Ben's been using this a ton on his projects. In particular, he's been using it for automatic PR labeling, surfacing reviews, correctness checks, and all the usual stuff that you would expect. The PR labeler in particular is really useful. I hadn't seen this till now. just showed it to me and I think I'm going to go add this to T3 Code. It **[03:36]** would be super helpful over there. It's cool when I figure out my sponsors are even better than I thought they were when I'm filming the ad because they paid me to talk about them. They didn't pay me to do this. See why I like them so much at soy.cope. First, I want to start with Claude Code because it's the one that people seem the most familiar with nowadays. It's what people think of now when they think about coding with AI. It has pretty much fully taken the mental position in the space that cursor used to have. Like I remember in the YC batches where 90% of the batch was using cursor. Now it's **[04:07]** like 70%'s using cloud code. The shift happened very aggressively. So how should we be thinking about cloud code? The goal of cloud code was initially Boris's attempt to think into the future. What could code look like if the models were way smarter? How would I want to use these things? In a world where people are going to claw.ai, pasting some code, asking the model for thoughts, getting some changes, then copy pasting them back into the codebase, it was obvious that there was room to improve. And cursor had made some improvements there, especially with like the chat interface in cursor where **[04:39]** you could talk to the model about the code and watch it go make those changes. Cloud code was different for a handful of reasons. The biggest by far being that it was built to work in your terminal. Instead of forcing you to adopt a whole new workflow, instead of forcing you to switch over your IDE to some other thing, instead of making you install a different app or write code in a different way or move everything to the cloud, cloud code met developers where they were, their terminals, and they wanted to make a great experience editing code with AI in your terminal. This means they have a lot of inherent **[05:10]** compromises they have to deal with. Things like pasting images will never quite be elegant. You can't see the thing you pasted. things like selecting text and all of the weird spacing that things have because they kind of have to. I'm using the new full screen mode to prevent flicker because the flicker kills me. But the new full screen mode is doing a whole different way of rendering to the terminal which means they have to fake all of the UI elements themselves instead of using the traditional scroll buffer behaviors. Has it benefits, has it negatives, is what I prefer when I use cloud code. They're hoping to make this the default in the **[05:41]** future, but yeah, it's meant to just be used in your terminal. I really want to emphasize the adoption story that Cloud Code is pushing. They want it to be as easy as possible to get started using Cloud Code. You paste the command to install the CLI and now you're using it. You do have to go off quick with your browser or paste an API key or something along those lines. Initially, it was API key only, which is still crazy to think about, but the whole idea is that it's easy to set up and use without having to change any of your other tools. You would spin up cloud code, make changes, **[06:12]** go look at them in VS Code, commit them, do whatever you want. It would just be another tab in your terminal. But over time, as you can guess, people wanted more. People wanted things like automatic git commits and automatic pushes to GitHub and noticing when changes happen in your PRs. People wanted to connect Cloud Code to other sources of information through things like MCP. People wanted Claude code to be able to be triggered remotely in order to control it from their phone or use it in a better UI and all these types of things. People wanted Cloud Code to be able to do more work at once **[06:42]** and work on things in parallel. Anthropic tried to not overstep in this way initially, but at some point, I don't really know what changed. They started to embrace this stuff much more. They had things that would let you build into cloud code like their hook system that kind of stopped being iterated on. some of my fun demos I built with cloud code back when I was using it more like the app that would only let you use your browser and things like Twitter if you had something running and whenever your agent finished it would lock you out of **[07:13]** Twitter until you went and responded to get it running again. A lot of those things had rough edges because the hook system wasn't fully implemented. I would say the moment of no return like the oh [ __ ] moment for cloud code was definitely when Opus 45 came out at the end of last year. That jump in model capability made it much more compelling to give a model access to everything through the terminal. The idea that I could GP through your codebase to find things, that I could run commands to deploy things, that it could use MCP to get data and do so much more made it way **[07:47]** more pleasant to use. And I found myself leaning into Cloud Code way more heavily because I could trust the code more. So I didn't need a UI where I was reading it actively. I did want a terminal because I wanted it to have access to all the things you can do in a terminal. And the biggest thing you might notice at the bottom here, bypass permissions on the model got smart enough that I could trust it to not run malicious commands very often, if at all. And now to this day, I run almost all of these tools in bypass mode or yolo mode or something along those lines. Opus45 was **[08:17]** good enough to cause a huge industry shift where lots of people started leaning into cloud code more because the model caught up with this style of tool and this was a huge moment for anthropic especially in places like Twitter. They also noticed what types of things would perform well on Twitter. People love terminals. People love doing cool things with agents. People love when their tools get better without doing anything. and they love this feeling of the stuff they rely on and love improving. And I am going to drop a somewhat **[08:48]** controversial take here that I've said many a time. Cloud code is as much a marketing tool as it is a developer tool. Anthropic is largely using Claude Code to push the idea that Anthropic is the best thing to use for building with AI. A lot of the features and the cool stuff they add to Cloud Code is really optimized for the Twitter screenshot. Things like the pet mode that they added was definitely so people would screenshot their numbers and share them on Twitter. Things like the sub agent mode burns your tokens super hard, but **[09:19]** it looks and most importantly feels super productive. I remember the first time I spun up a bunch of sub aents in a team. It felt incredible to have so much stuff happening with so little work on my part. Cloud code is really optimized for that feeling of productivity. It really feels almost gified. Little things like the cute guy in the corner here. The way stuff shows in the UI. The way that the teams spin up and check things out. I'll test an example here. Spin up a sub agent for each example **[09:52]** project here and audit it for opportunities to streamline the cloud code experience. Even though I'm in the mode that is supposed to hide my email address, it still docks my email there. Thanks, Anthropic. We'll try again. See how much is happening in the UI here. You see the tokens going up as it goes. It has these little updates. It has the loading states. It has the dots flickering. It feels like it's doing a lot. And now it's going to launch the **[10:23]** audit sub aents that it will spin up for these different things. And we can see at the bottom here, we can switch to those sub aents and see what they're doing. It feels really cool and really productive. There's a lot going on. That's kind of the point. Claude Code wants to feel really productive, but it also to be frank, they are trying to make it better and they're trying to make it more capable, but generally speaking, Anthropic's philosophy around how to make the tool do smarter things is to let it burn more tokens. And **[10:54]** things like all the sub aent stuff, and everybody's already saying this in chat, five minutes later, you're down $200. Token, token, token. You spend two hours trying to fix this. Yeah, you guys get the idea. It's very willing to burn tokens in the interest of doing things in a way that looks and feels really productive and to be frank often can be. A lot of the improvements they're trying to make to cla code are finding new ways to burn tokens to potentially solve work and do more in cooler ways, but also, **[11:25]** let's be frank, to look really cool for screenshots and demos on Twitter. This is also why in my opinion, Anthropic is much less interested in letting you integrate cla token maxing so hard that anything spinning it up programmatically risks absurd compute usage that they don't want. Imagine setting up a tool similar to what I just did there where I ask it to spin up sub agents to check things, but you implement that in your CI process whenever a pull request is **[11:56]** formed on your project. Then you're going to burn a shitload of tokens. you might not mean to. And that's a thing Anthropic doesn't want you to do. If you're burning tokens with cloud code, they want it to look and feel productive because that's what they're trying to sell. They are eating a bunch of token spend to trade off the feeling of being really, really productive. And if you're not looking at the anthropic cloud code UI, when that happens, it feels much less productive. They're not getting what they're trying to here. This is also why things like their desktop app are heavily underinvested in. This is **[12:27]** also why things like T3 Code aren't as interesting to them and why they're not letting us programmatically call the Cloud Code CLI anymore without charging you way more money. They want you in their CLI using their features, having their experience and they also want you building integrations into Cloud Code itself. Because if a tool like T3 code provided other skills or provided other resources, MCPS, etc., and then I can switch over to codeex and not have those things get stuck in cloud code. They actually come over when I switch between **[12:58]** providers. Cloud isn't getting the lock in that anthropic wants it to get. So they really optimize for that. Cloud code is meant to be the world's greatest showcase of what you can do with anthropic models at a lot of cost to anthropic in order to win a bunch of sentiment so people feel and arguably are more productive using cloud models in anthropics tools. And you can bet your ass they went hard modifying the UI to make it feel this productive. A lot of the performance issues that used to exist in Claude Code were because they were doing all these fancy loading spinners and things which resulted in **[13:30]** the performance being degraded which was a hit they were willing to take because they were optimizing so hard for the feeling. Hey to those in chat saying I'm being too nice. I'm trying to be because I'm not trying to shame people who like Claude Code and are using Cloud Code. They engineered it to be like a slot machine. They did a great job at it. It got me addicted to doing agentic coding. I wouldn't have gone as hard as I did at the end of last year and the start of this year if it wasn't for quad code optimizing itself for this type of thing. Let's contrast this with codeex. **[14:01]** I have it on medium fast which is way faster than quad code. So I'll actually turn off fast mode actually. And now I'm going to paste that same prompt. Spin up a sub agent for each example project here and audit it for opportunities to streamline. There is so much less going on here. You have a timer. You have the working text that's slightly animated and nothing else. It did spin up these two subprocesses, but I don't see anything going on in them. It's very minimal. This is way less addicting is the way I would put it. And we sit and **[14:33]** wait and wait. It's not trying to feel like a slot machine. It's not trying to feel crazy. It's just trying to get work done. And when you look at the types of features that are being added across these tools, you will really quickly see this difference. Just as an example of one of the recent things they shipped in Claude Code, they added SL radio, which opens a 247 lowfi Claude music stream. Like I'm not going to sit here and say this is cringe or cool or whatever. I **[15:05]** just think it shows the philosophy of what and how they are building. like they really are optimizing for the feeling of productivity and the killer thing to post on Twitter. Like you you know that in the feature review process at the company, they are thinking about what does the tweet look like before they build the feature. Meanwhile, let's compare that to the official OpenAI developers Twitter, which is mostly just Codex updates. Now, this tweet did way fewer numbers. 8.2K likes. Codex anywhere and everywhere all the time. **[15:36]** Now, your Mac doesn't need to be unlocked for Codex to use your computer. This feature is not very flashy. This feature is inside of the settings computer use section in codeex. You have to go hit this switch in there and then nothing cool happens. You literally can't screenshot this feature because it happens when your Mac is locked. But it makes you way more actually productive. Let's keep scrolling. Ship paper cut. New diff marker settings in appearance. If you prefer the classic plus minus, you can turn that on. Otherwise, it'll **[16:06]** just be colorcoded. This is not flashy at all. This got 900 likes, but it's real and practical. They added a feature where Codeex can bind a double command hotkey to copy what you're currently looking at in your app and throw it over to Codeex to populate the context. I love this. I'm a big fan of using screenshots as context. And having a built-in thing like this is great. Like, it's practical stuff that doesn't demogate because the point of these things aren't to be cool demos on Twitter. It's to be frank to solve real **[16:39]** problems that they have as they are building software using these things. Even computer use itself being such a core part of codecs. It didn't make that much sense to me. It seemed like it was one of those things that sounded really good but just wasn't that practical. But similar to how cloud code wasn't useful until the models got good enough, computer use really wasn't useful until the models got good enough as well. And now that 55 is really smart at these things and I also have a dedicated Mac Mini in the other room that I use for a lot of my code tasks, Codeex being able **[17:10]** to use computer use to go verify its changes is awesome. And it's way more likely that by the time Codex tells me it's done with a task that it actually did the task correctly. This is also where another big philosophical difference comes in where they want to use these tools. The vast majority of people at Anthropic using Cloud Code are using it in the CLI. The vast majority of people using Codeex at OpenAI are using it through the app. Funny enough, a lot of my friends at OpenAI are non-technical. They're not devs. They're **[17:41]** on marketing and whatnot. They all use Codeex, the app, and they use it for all sorts of cool things because this interface is a big part of how they work. And it still is optimized to just be a good experience, not to be a flashy experience. Like again, I'll do the same demo I did before. I'm just going to tell it to spin up a sub agent in this project to audit all of the examples. There is very little going on in this UI. There is just the thinking here. Now, it's going to do a search. It's **[18:11]** going to go check things. It's not trying to be flashy. It's trying to be productive. Let me update to the latest cloud app so it's less likely to break. Oh, great. I have to sign in again. Wonderful. Who would have thought? Why is it doing it through [ __ ] Safari? I [ __ ] hate Anthropic, man. This is so bad. I have to manually enter all this [ __ ] cuz I don't have one pass on the like inapp safari and it doesn't work with my pass key through one pass. This is horrible. Holy [ __ ] You can tell they don't use it. Like they just straight up do not use the desktop app. **[18:43]** Even better, I'm now in. But it says at the top right, failed to log in. It may have been cancelled. They they don't use this app. I don't know how else to say it. They clearly do not use this app. I'll update to the latest and hopefully the problems will go away, but it's probably just going to reveal my email again. There we go. We have chat co-working code. Also, the first thing I noticed is that all the threads I did in the CLI aren't here. It doesn't sync across. The codeex one does. Just an annoying thing. How do I even add a new project in here? I don't know how to add a new project, guys. Do I need to like **[19:14]** select here? Why does it start in the root, not where I already was? So much more is happening. You have the fancy animations for the text here. You have the token number bouncing up all the time. The counter, the super flashy different shaped star there that stays when it's done, by the way, too. So, it's hard to know when it's actually completed. It's just a lot. And it took so much effort to even like get this project added. It's They didn't build this app for you to use it. They built this app so that **[19:44]** it would exist if people stop asking for it. Personally, I'm not that into the slot machine feel that Claude Code seems to be going for. I much prefer simple, reliable solutions you can really trust, like today's sponsor. Got to be so real with you guys. Hiring sucks right now. The quality of the résumés coming in looks like it's gone up, but it's all just slop. And the volume of RS coming in is absurd. Like 10 to 100 times more than I've ever seen. Finding good engineers is really hard. And then convincing them to join even harder. That's why G2I has become such an easy recommendation for me. These guys get **[20:14]** hiring. They already have a network of engineers that they know and trust and they know them so well. That's why companies like Batteround have moved to G2I for their hiring. They've already hired nine senior engineers and they're never going back. The biggest problem they had was that the leadership at the company had to spend so much time hiring because finding good people requires leadership, not a bunch of money spent on recruiters that don't know what they're doing. As they said, Batteraround didn't need more resumes. They needed fewer, better candidates that they could evaluate quickly and confidently. If this quote doesn't win you over, then I don't think G2I is for you. I think the best part is the network, the vetting process, rather **[20:45]** than just the pedalling people, so to speak. It's the biggest difference for me. Before they use G2I, about 50% of their hires were success cases, according to them. But since moving to G2I, they'd say the numbers are around 90%. Stop wasting time and start hiring quality at soy. G2I. This isn't just about how it looks and feels to use the thing. There's also a very practical how they're thinking about the models and where they're going aspect here. A lot of the bets in the direction that Anthropic is going in is as the models **[21:15]** get smarter, they should have the ability to do more. Like if the agent is smart enough and it can write its own prompts for sub agents and just spin up a bunch and let more tokens solve the problem. Generally speaking, anthropic strategy is if more tokens solve the problem, use more tokens. And they are very quick to look for ways to solve problems with more tokens. Cloud code is memory leaks on Windows. Go rewrite bun and rust with a shitload of tokens. Like it's insane how far they push that idea **[21:45]** that more tokens can solve the problem. Open AAI does not go that way at all. Okay. Also, like do you see how much like the way that this updates is like line by line, word by word in a way that that feels very like visually engaging. That's by design. They do all of this to feel as exciting as possible. But the again to the philosophy thing here about the token usage, Anthropic will gladly burn tokens. Whether it's yours or theirs or anything else, they are more **[22:16]** than happy to come up with solutions that require you burning way more tokens to solve the problem instead of finding better ways to solve and verify that the problem is solved. OpenAI solution is much different in this regard. You can tell just from how many tokens they use for things like the artificial analysis bench. They are trying really really hard to make their models more efficient. 54 mini not the case. 54 mini burns tokens. Sonnet 46 burns a similar amount to mini. GBT54x high and opus 47 **[22:48]** burned a similar amount too, but GBT55 used half as many tokens to get a better score. OpenAI is trying way harder to be token efficient, but they don't want to compromise on the accuracy of the solution. So, they're trying to find ways to know if the code worked or not using fewer tokens. And that's where stuff like computer use is really powerful. If the model can make a change and then look at what it changed and verify if it succeeded or failed, it ends up being a lot less work than **[23:18]** spinning up 15 agents to go triple check every line of code. This also means you need to have an environment that works well. This is one where the biggest differentiators is. Anthropic very excitedly sets up tools to let you transport your thread from your machine to the cloud to finish it up there. But good luck getting the cloud environment for cloud code to work properly. I tried and gave up. And the advice I got from my friends at Anthropic was, you don't really need the agent to run the code. Just throw the tokens at it. It'll probably get things done just fine. But **[23:49]** when it doesn't, it sucks. And I like using the cloud runners for big tasks that I don't want to run on my machine. So the fact that it is not really able to verify the results because it doesn't have the environment configured correctly just kind of sucks. Codeex was trying harder to get a good cloud environment, but it seems like it's become much lower priority. The easiest example to see this is in the codeex section of the chat GPT mobile app. They hid the cloud option under like three menus. They're really not optimizing for cloud because they know how hard it is **[24:20]** to get most projects running properly on the cloud, but you probably have it running fine on your machine. They know this because that's their own experience building. They struggled to get everyone at the company's projects working properly in codeex on the cloud. So they just made it so you can control your own machine with your phone instead. Anthropic's bet is the models will get smart enough they don't even need to run the code. They'll just write it correctly. OpenAI's bet is it's so annoying to configure things properly that we should probably just use the configuration you already have on your machine. And now we need to talk about the third option because their play in **[24:52]** the cloud is very interesting. It's kind of crazy how quickly cursor went from far and away first place to third. And I honestly think a lot of that's cuz people don't know where cursor's real power is. You might notice my cursor looks different from yours. It's cuz my cursor is currently in the browser, not the IDE. That's because cursor's cloud stuff is so far ahead of any of the competition other than maybe Devon. Cursor cloud agents aren't just like a crappy headless Linux sandbox that the **[25:23]** agent can use to try and execute your code. The cursor sandbox spins up a full graphical interface Linux instance that it can use to run your full app the way you would on a real computer and then uses computer use to test the changes. So here it ran the T3 code codebase and then launched the browser version because it's exact same as the version that you would run in the electron shell in order to test its changes as it made them. But Theo, I already have a computer. Why would I want to do that? I **[25:54]** understand. When I'm on my phone, I didn't set up a computer to control remotely. It's very nice to be able to go spin this off. If I want to work on two different things that need computer use at once, it's incredible to go spin this off. There are so many use cases where one computer is limiting because one computer can only do one thing when you're computer using it. And if it's not on or not connected to the right network or any of those other things and you can't use it at all, you're just kind of stuck. And there's something legitimately magical about being in Slack. Someone brings up a problem with the product. You at the cursor bot and **[26:26]** say, "Hey, can you go spin up an agent to fix this?" and it responds in the thread with a video of the fix it applied showing you that it worked. This is so far ahead of anything that Cloud Code or Codeex can do, it's insane. Another way of thinking about this is that Codeex is betting really hard on where things are today. What is it like using agents to code right now? How do you make it more likely they succeed? Anthropic is betting on where the models **[26:58]** will be in a few months. Also, where the models they're using are because they're all using Mythos. They are betting on the models getting so smart that these types of things matter less. Cursor is betting way out in the future where we're not running these things on our computer at all. We are just triggering them through whatever other tool we want and then getting back proof that the thing worked. That does bring up another really important difference and probably the most painful philosophical difference between all of these things. I mentioned this before, but I really want to emphasize it. OpenAI uses the **[27:29]** Codeex app all of the time. There are thousands of employees at OpenAI that use this app every single day. The cloud desktop app does not get anywhere near as much love, largely because they're all using the CLI instead. But there's a problem here. The version and state of things that anthropic employees are using is very different from what we are getting as end users. The model that a lot of those employees are using is mythos. We don't have that. They have a custom build of cloud code with a bunch of cool new hidden features in it that we don't have access to. This is why we **[28:00]** end up with really embarrassing things like system prompt stuff leaking because the system prompt that they use internally is different from the one that we get in the apps that we use. That's why I ran into problems like this when I tried out opus 47 in the new cloud code desktop app where I asked it what are some design improvements I could make on this site and it opens with heads up the system reminder about malware looks like a prompt injection. This is clearly your personal site, the T3G homepage, not malware. Ignoring it. We're using something entirely different from what they're using. And I don't **[28:30]** know how to properly emphasize this because people just don't seem to get that. You do not get the tool anthropic employees get. You [snorts] get what they feel generous enough to give you and they are not testing it reliably enough. This leaks through the whole clot experience. It is clear that this tool works great for them and the portions of the thing they're using that they cut off and throw out to us are not tested well enough. And the result is that we get weird [ __ ] like this. I guarantee you that one of two if not both of these things is true. Either **[29:02]** this system prompt is not the one they were using internally, which is very likely the case, or this problem that I have here just did not happen with Mythos, which is what they were all using internally. the model we're using, the system prompt we're using, the harness we're using, the UIs we're using, all of those things are not the same thing that they are using at Anthropic. Meanwhile, the Codex app that we're using, the Codex models that we're using, and the Codex plugins and features and all of that that we're using is the exact same thing that they're using at OpenAI. I can't cite my **[29:34]** sources here, but you need to believe me on this. I have friends at all of these companies. It is very apparently the case, and you can tell externally that this is also the case. It's obvious. And to their credit, Cursor is very similar here. They use the [ __ ] out of the things that they are doing. They obsessively test every detail before taking the exact thing they're using internally and throwing it at us externally. They even do crazy stuff like disabling every model other than the new composer model and not telling people that they did that. So, everyone **[30:04]** thinks they're using Opus or GBT55 or whatever, but they are dog fooding their own thing to see what issues people run into. The effort that cursor puts into making sure things are good before they put them out is insane. OpenAI is close to that same level. They just have issues. If if anything, the thing I've experienced, which is funny, is that they have [ __ ] versions internally at OpenAI. Like I ran into problems with GBD55 during testing because the researchers didn't have the search tool on because they don't want things **[30:35]** leaking, which I totally understand. The the point being we get more than they have. Cursor gives us exactly what they have. Enthropic gives you less than they have. That said, Cursor is not really that focused on integrating with other things. They did just throw out the cursor agents SDK, which is like cool and took them long enough to do it. Anthropic is actively trying to push us away from using our subs outside of their UIs. Open AAI can't stop inventing awesome standards we can build on top of. Like to be really frank, my agentic **[31:08]** coding app T3 code that I built with Julius, mostly Julius, this would not exist if it wasn't for the codeex app server, which is part of the open source codeex CLI. They give us so much stuff to build on top of and around. We are building on top of the codec CLI the exact same way the Codex app team is. I am admittedly disappointed that the Codex app itself isn't open source. I wish it was. It's another big part of why we built T3 codes. It was a good open- source option, but we built on top of the Codex app server, which was awesome to build with. And the Codex **[31:39]** employees will just openly post on Twitter like if you want to use Codex for something different, tell your agent to go to this repo and look at this folder and it'll figure it out. Cursor seems interested in building these types of things, but historically hasn't done that great of a job. When we wanted to add cursor to T3 code, we had a lot of problems because the recommended path was through their agent client protocol bindings that they had set up for the CLI, but the cursor CLI was super behind and the ACP stuff even more so. You couldn't even pick modern models. We **[32:10]** tried setting this up a few months ago, not even. And the most modern composer model was one when two had already been out for a while. They didn't have Opus 46 or 47. They only had 45. They didn't have any of the new sonets. They didn't have any of the new GPT models. it was super limited and they were all hardcoded in so we couldn't pick newer better models. We had to go back and forth with the team for a while to get them to fix that. They did end up doing it and they ended up also putting out the SDK. So it seems like they want to make more of these integration things but it's not a priority or focus for them. Open AAI is heavily prioritizing and focusing on this. Claude would **[32:41]** really rather you don't do this. Anthropic is trying to keep you from building integrations with cloud code unless they're deep inside of cloud code itself. OpenAI wants you to do whatever the [ __ ] you want. They just want to see people build the future using whatever, especially if they're using their stuff. Cursor wants that, but isn't prioritizing it properly. One last piece that I think is important to understand, model improvements. Enthropic has to add a bunch of features because their public models haven't improved since December. I still feel like 46 and especially 47 **[33:13]** are more so regressions than they are improvements. A lot of why Codex has improved is because the models got way better. 52 to 53 to 54 to 55 were massive improvements. In the time we went from 52 to 55, we went from Opus 45 to 47. So, Opus got worse twice and OpenAI models got better three times. That compounds massively. If you took the same old version of the codec cli that was around at the time and switched it over to 55, it would feel incredible. **[33:43]** If you took the old version of Cloud Code from the end of last year and tried to use Opus 47 in it, it would probably crash because Cloud Code was getting so buggy, especially then with the performance issues. But if you could get it working, it would probably still feel worse because the model was dumber and less willing to do the types of work I want to do. So Anthropic has to make up for this somehow. And they're doing it by doing a shitload of cool looking features and trying to make moments happen with cloud code. They're trying really hard to seem like they're making a lot of progress. And to be frank, they're getting away with it. It's **[34:15]** working. People say things like this on Twitter. The anthropic team is still innovating the most in the harness layer and it's not even close. The only reason you think this is cuz they do better on Twitter and they keep adding things cuz they kind of have to. But since their actual better model is mythos and they're not releasing it for various different reasons that we can conspire about all day, their tool has to look better because it's not able to improve just from models getting better. Separately, codeex is meaningfully **[34:45]** improving constantly. 55 itself is enough of a reason to make the jump. This is definitely very different from other videos comparing these tools. I know most of them just like send the same prompt and compare how good the answers are from all of them. Whatever. If you like the model, you like the model. If you like the tool, you like the tool. The things I care about more are where is the team going with this? What problems are they trying to solve with this? And can I trust this thing to work well tomorrow like it does today? I hope this helps give you a good answer to those things. If you're still primarily coding using a sidebar in VS **[35:17]** Code or Copilot or Cursor, please go try any of these, especially the desktop apps. They've gotten a lot better and it's a much nicer way to code using AI. I'm so blown away with how much I like things like the codeex app or the T3 code experience. It's just it's really good. The models are just one piece of this puzzle. And as great as the models for anthropic might be, all these other things matter, too. So, give these tools a shot. See which ones fit your desires and your workflows the best and go with that. If you hate coding and you want it **[35:47]** to feel more fun as you do it, you want to feel good and like you're productive the whole time, Claude Code's actually very good at that. If you need help staying motivated, go hop in Cloud Code. If coding is still scary to you, go try out Cloud Code. It'll probably do a great job at that. If you've been an engineer for a long time and you want a tool that mostly stays out of your way and just gets [ __ ] done, Codeex is phenomenal. It really feels like it's buy and for engineers, and I hope it stays that way. Believe me, if Codex regresses, you'll hear it first for me. And finally, with Cursor, I recommend **[36:18]** using it through the cloud side. The Cursor cloud is incredible. It's so powerful. does things I never would have predicted that cursor could do or that AI could do as a whole. It's also one of the best solutions to set up for your team so nontechnical people can kick things off in Slack. It's really the enterprise ready end to end solution. Highly recommend trying it if you haven't. The cloud stuff is so cool. So to simplify, cloud code for unmotivated devs or bad devs that want to feel like they're productive. Codeex for skeptical devs that want to use these tools in a **[36:50]** way that is productive and leans into good workflows that they're already probably doing. Cursor for people that want to set their teams up for success with cloud runners that are able to solve real problems in simple ways using tools inside of their Slack or whatever. And to answer the final question from chat, what about anti-gravity? It's a great way to secure your future by convincing your boss that AI is not capable of doing anything at all. And it is not useful for anything beyond that. And if you're asking about PI, you don't need this video in the first place. Go **[37:21]** play with the cool fun things. Hopefully, this helps you understand the benefits of all of these different solutions, the philosophy of how they are building these different things, and the reasons why you might pick something over another thing. But in the end, you got to just try all of them and see what maps to your workflow the best. and let the tool shape your flow a bit too. When I tried to treat Codeex like Cloud Code, I didn't like it as much. When I let it do its thing more, I ended up really liking it. Hopefully, this has been helpful. This is a very strange video for me to make, but I hope that it is as useful as I wanted it to be. Let me know **[37:53]** what you all think. And until next time, he snirts.