Transcription
Hello. Today we have, well, such a deep dive into the world of developer tools that, you know, work right from the command line. And on the agenda today, we have two, well, you could say, heavyweights. Cloud CД from Entropic and code CLI from Open AI. We will be analyzing them in detail, relying on a very, you know, detailed video review by user Matt Maher. He directly pitted them against each other, tested them in real tasks. Yes. Hello. The topic is indeed interesting because, well, at first glance, it seems like, well, just another tool, but in reality, there are so many nuances. And this review by Maher, it is valuable because it focuses not just on checkboxes in a feature list, but on what he calls ergonomics. That is, how, well, humanly convenient it is to use it every day. Ergonomics for the command line sounds curious. So, our task today is not just to compare, but to dig deeper, yes, to understand how they feel in practice. Specifically, we will go through, well, literally the entire developer's journey, starting with installation. How to install it at all, how difficult it is. Then we will look at the interface, what you see on the screen, whether it is easy to read. Then commands, how to interact with them. Memory, how they remember context, model configuration, whether you can tweak something for yourself, and even such, well, advanced things as planning and agents. Wow, a serious plan. Yes. The goal is not just to understand what they do, but most importantly, how. And what this difference in how means for, well, the daily routine of a programmer, because in the end, it is this that determines whether you will use the tool with pleasure or, well, as if through force. Excellent. Then let's start from the very beginning, from the basics. How to get them? Installation, you said, seemed simple. Well, with installation, yes, everything is more or less standard here. If on MAC, then through brew or through npm. This is a package manager for Node GS. So, for most developers, these are familiar commands. A couple of minutes and it's ready. Here, you could say, it's a tie. Okay, installed. And then access to the models themselves, to the intelligence. This is where you said the differences begin. Yes. And this is precisely where, according to Maher, one of the key differences that can influence the choice lies. Look, code CLI is a product of Open AI, and it is, so to speak, integrated into their ecosystem. If you already have a Chat GPT Plus subscription, well, the one that costs about $20 a month, which many developers already have, yes, which is important, for GPT5 for coding tasks. So, you are already paying for Chat GPT, and code CLI comes as a bonus, as it were. Maher directly emphasizes how attractive this is from a financial point of view. The tool is essentially already paid for. And Open AI does not limit its use in any way, well, like some draconian limits. Maher notes that with the limits, not everything is entirely clear, there is little precise information, but in his opinion, Open AI is quite generous. It seems to be their strategy to lure users with the availability of a powerful model within an existing subscription. It competes with Entropic. Obviously, understood. And what about Cloud Code from Entropic? How is their access and pricing? Well, with Entropic, the situation is different. They also have a basic subscription, also around $20. But an important point, this basic subscription does not give access to their coolest model, OPUS. Seriously? So, for $20, you don't get the top-tier model? Yes. For OPUS, you need a higher-level subscription. In the review, Maher mentions a figure of around $100 per month. Wow, $20 versus $100, that's already, well, a significant difference. Very significant. True, here Maher makes an important reservation. In his experience, GPT5 in code CLI, especially if you enable the High Effort mode, meaning you ask the model to think harder, is quite comparable in performance to OPUS. He says that GPT5 is an excellent model for coding. So, if you don't absolutely need OPUS for some specific tasks, then the economical code CLI looks much more attractive, of course. If you already have Chat GPT+, it's just waiting for you to start using it. Okay, the picture with access and pricing is becoming clearer. Code is potentially cheaper, Cloud Code is more expensive, but possibly with a more powerful model at the top, although GPT5 is also not lagging behind. But we've launched both tools. What do we see? You said Maher paid a lot of attention to the interface and readability. Why is this so important for the command line? Oh, this, according to him, is simply critically important. And here the difference between Cloud COL and code CLI is, well, simply a chasm. Cloud COL, as he shows, is designed with the user in mind. It knows how to hide its internal thoughts. You know, when a model generates a response, it goes through different stages. Well, Cloud Code can collapse them into neat blocks. You see the result immediately, but if you're interested, you can expand and see the thought process. Convenient. It doesn't clutter the output. So, exactly. Plus, it works great with Markdown. Lists, text highlighting, code blocks. Everything is displayed beautifully, structured, easy to read, easy to understand where the code is, where the explanation is. The output is clean. It sounds like a good GUI, but in the console. And what about code CLI? Is everything bad there? Well, compared to Cloud, yes, it's night and day. Maher shows examples. Code CLI dumps everything into the console: its entire thought process, all intermediate steps, all debug output, and only then the answer itself. This creates incredible noise. Maher says that sometimes you just get lost, is the model still thinking or is this already the answer? He even interrupted the execution, thinking the model had gone crazy or frozen, but it was just, well, thinking aloud very loudly. Ha, I can imagine. So, you have to be constantly on alert and filter this stream, right? And this takes mental effort. And here's something else that's killer, according to Maher, is working with Markdown, or rather, the lack thereof. He shows how code CLI simply outputs the markup as text. For example, bold font will look like this. Lists with raw markers like or UD. When there's a lot of text, especially with code snippets, reading it is, well, simply torture. That's harsh. So, formatting that helps structure information is simply ignored completely. And Maher constantly uses the term cognitive load. That is, your brain has to do extra work just to decipher what the tool gave you. And this load, he says, is the price you pay for code CLI being free every time you use it. Even if the model itself is smart, communicating with it is difficult. Yeah, the prospects are not rosy for daily use. This brings us to the next point, commands. How do we interact with these tools? Slash commands like init or edit. Do they exist? Yes, of course, this is now the de facto standard for such tools. But even here, the implementation, according to Maher, differs greatly. In Cloud CД, this is one of its strongest points. It has a good set of built-in commands for various tasks. But the most important thing is the ability to create your own custom commands. Oh, that's interesting. So, you can customize the tool for yourself? Exactly. And you can create two types of commands. Local. They are stored directly in your project folder, for example, in a Git repository. And if someone else from the team clones the project and runs cloud code, they will also have these commands. This is super convenient for teamwork for common project tasks. Cool. And the second type? And the second type is global commands. They are stored in your home directory and are available in all projects where you run Cloud Code. This is for your personal, frequently used shortcuts or complex prompts. Maher says that this flexibility, the ability to extend the tool with your own commands, makes cloud code a truly powerful assistant that adapts to your workflow. Sounds very thoughtful. And what about code CLI with commands? Can you create your own too? Well, not here. And this, according to Maher, is a huge drawback. Code CLI has its own set of built-in slash commands. It is much more limited than CLE. And most importantly, there is no possibility to add your own custom commands at all. So, only what the developers provided, right? The concepts of some commands are similar. For example, both have something like init to start working on a project, but the lack of extensibility is a step back. Maher mentions that theoretically, you can somehow simulate your own commands by creating files with pre-written prompts and then feeding them to the model through the file command. But this is, obviously, a, you know, a crutch. Far less convenient than the built-in custom command mechanism in cloud code. Understood. So, code CLI is more like a platform that can be configured, and code CLI is more like just an interface to the model. Yes, that's exactly the impression from Maher's review. Cloud code tries to become part of your workflow, and code CLI so far just provides access to GPT5 from the console, but without much convenience around it. Okay, commands are clear. What about interaction dynamics? I give a command to the model, it starts doing something, generating code, analyzing a file. Can I, while waiting for it to finish, give it the next command or maybe clarify something? In Cloud Code? Yes, you can. And this is another feature that Maher praises highly for its convenience. He shows: "You enter a command, cloud starts working, but the console is not blocked. You can immediately type the next command or question. And what will happen? Will it interrupt the first one?" No. No. The new command will simply go into the queue. Cloud will remember it, buffer it, and execute it as soon as it finishes with the previous one. This is super convenient because, well, thoughts don't wait. Often, in the process of executing one task, an idea for the next one comes, and you want to capture it immediately, not keep it in your head or write it down somewhere else. Logical, right? It allows you not to lose context and flow of thought. And what about code CLI with this? And with code CLI, according to Maher, there is no such possibility. While it is executing a command, you cannot type anything. You either have to patiently wait for it to finish. Which can be long if the task is complex? Exactly. Or you have the option to interrupt the current task, for example, by pressing escape, then give a new command, and then, if you needed to complete the interrupted one, you'll have to somehow ask it: "Now continue what you were doing before." Maher says that this is, of course, possible, but terribly inconvenient. It breaks the entire workflow. He returns to his idea of ergonomics, saying that the feeling of working is completely different. With Cloud, you are, as it were, having a dialogue, smoothly transitioning from task to task. But with code CLI, you are constantly fighting with the tool, as if manually fixing the interaction process. Yes, the difference in feeling seems colossal. Moving on. Memory is a very important aspect for AI assistants. How do they remember project information, some long-term instructions? For example, I want it to always use a specific code formatting style or always run a linter before suggesting a commit. And again, according to Maher, the approaches differ greatly. In Cloud Code, there is a very clear and well-thought-out mechanism for this. There is a special command, Memorize. You use it to give Cloud some instruction or fact that it should remember. And where does it remember it? Well, this is interesting. Cloud will ask itself: "Where exactly do you want to remember this?" The options are: one: in the current session's memory, meaning it will be forgotten after exiting. Two, in a local file, cloud.md, at the project level. This is for instructions specific to this repository. This file can be committed to Git, and it will be available to everyone. Three, in a global file, cloud.md, in your home directory. This is for general instructions that should work in all projects. Plus, Cloud even has a special shortcut, the hashtag symbol. If you start a line with a hashtag, it automatically adds that line to the project's memory in the local cloud.md. Super fast and convenient for adding small facts on the go. Wow, it sounds very flexible and transparent. You always know where your instructions are stored and how to manage them. And what about code CLI? Does it have any analogue to cloud.md or the Memorize command? There was a funny detail in the review. Initially, he thought that code CLI had no long-term memory mechanism at all, except through editing global configs. But then he accidentally discovered an interesting behavior. What? He tried to directly ask code CLI: "Please remember that I always use tabs instead of spaces." And to his surprise, code CLI responded something like "Okay, remembered." And, as Maher later found out, it actually updated one of its internal files, Agents MD. This file apparently plays a role similar to Cloud MD. So, the ability to influence memory somehow still exists. It turns out, yes, but Maher emphasizes several "buts." First, there is no explicit command like Memorize. You have to guess, ask it in free form, and hope it understands you correctly. Second, there are no guarantees that it will save your instruction verbatim. It might rephrase it in its own way, which reduces predictability. Third, there is no convenient way to see what exactly it has remembered or to easily edit this memory, other than digging into this very agents.m file manually. And there is no convenient shortcut like #Cloud. Yes, it sounds like another area where cloud code is much more thoughtful and user-oriented. Okay, what about choosing the models themselves and their settings? Can I, for example, switch to a simpler and faster model for a simple task, and for a complex one, enable the most powerful one or somehow influence how hard the model will think? In CLC code, yes, easily and simply. Directly from the command line interface, Maher shows, there is a status command. It displays information about the current session, including the model being used. And the model command allows you to select another model from those available under your subscription. For example, switch from the expensive and powerful OPUS to the faster and cheaper Sonet, or vice versa. You can also set a default model for new sessions. Everything is done with a couple of commands, without leaving the tool. Very convenient. No need to go anywhere, everything is at hand. And in code CLI, let me guess, it's more complicated. Much more complicated. And this is another point that Maher criticizes. In code CLI, all settings related to the model and its behavior are set globally. Globally, what does that mean? It means they are written in configuration files. Usually, these are YAML files that are located in the hidden .codex folder in your home directory. There, you specify which model to use, for example, GPT4 or GPT5, what parameters to pass to it. For example, this reasoning effort High, which Maher mentioned, to make the model think better. Wait. So, if I just want to try a different model or enable this High Effort for a specific task, I need to find this YAML file, open it in an editor, make changes, save it. That's terribly inconvenient. Exactly. Maher emphasizes this, it's a completely different level of interaction. Instead of a simple command in the console, manual editing of configuration files. And what's also important, these settings are global. You can't easily set one set of settings for one project and another for a different one. You'll have to change the global config every time. And if I don't want to change it globally, maybe there are some workarounds? Maher mentions one such way, using profiles. In these YAML configs, you can define several named profiles with different sets of settings. For example, create a default profile and a High Effort profile, and then when launching code CLI, specify which profile to use with a flag, for example, -p. Code -p high effort. Well, that's something, but it still requires pre-configuration in files. Yes. Yes, you still need to go into YAML first and define these profiles and then restart the tool with the correct flag. Compared to how it's done in Cloud Code with Status and Model commands directly in the dialogue, it's, well, as Maher says, simply night and day in terms of convenience. He reasonably notes that most users simply won't bother with it. They will either use the default settings or configure it once and forget about it. It doesn't add flexibility. Yeah, the barrier to experimentation and fine-tuning is quite high. Okay, let's move on. Another super important thing for any long-term work, especially with AI where context is everything, what if I need to take a break, close the terminal, go for lunch, and then return to where I left off? Is the dialogue, the context saved? And here, according to Maher, we come to one of the most, well, I would say, shocking differences. This is really intriguing, what's there. Cloud Code handles session resumption excellently. Everything is thought out. If you simply launch with the --continue flag, it will automatically resume your last session. And if you want to choose from several recent dialogues, there is the Resume command. It shows a list of your recent sessions with previews, and you can choose which one to continue. Everything is simple, intuitive, and incredibly useful. Sounds like an absolutely basic, necessary feature for such a tool. I can't imagine working without it. And what about code CLI? Really? And code CLI, according to Maher, completely loses all context upon exit. The session simply dies. Irrevocably. Like completely? So, if I close the terminal, everything starts from scratch. Yes, exactly. And here's the paradox that Maher just can't understand. Code CLI saves the history of all your sessions. It writes dialogue logs as text files in the /codexhistory folder. So, it has data about what you were doing. Wait. It saves history, but doesn't allow you to load it and continue? How is that even possible? Well, Maher asks himself the same question. He says: "This is absolutely wild. Why save history if there's no built-in mechanism to use it? This is one of the key features of the GPT5 web interface. The ability to return to an old dialogue. And its complete absence in the official CLI tool from Open AI seems like an inexplicable oversight." Maher even mentioned that he had to write a small script himself just to browse these history files more conveniently, because the code CLI utility itself doesn't allow it. Yes, this is a really serious blow to usability. Losing all context every time means constantly repeating the same things, re-explaining to the model what you're doing, it's just awful. Exactly. This is not just an inconvenience, it's a fundamental flaw that significantly reduces work efficiency, especially on complex tasks that cannot be done in one sitting. Understood. It seems Maher's list of complaints about code CLI is only growing. He also mentioned some interesting thing in Cloud Code. Planning mode. What is it? Why is it needed? Yes, it's a rather curious feature. In Cloud Code, you can switch to a special planning mode. This is done with a keyboard shortcut, I think it's Shift P. When you are in this mode, Cloud Code behaves differently. It will analyze your task, suggest a plan of action, break it down into steps, but it will not make any changes to your files or execute any code itself. Ah, so it's a safe mode to think first, then act. Exactly. It will even warn you if, in planning mode, you ask it to, for example, write something to a file. It will say: "Hey, I'm in planning mode right now. I can't modify files. Do you want to switch to normal mode?" This is very convenient when you are working on something complex or potentially dangerous. You can first think through the strategy with the AI, make sure the plan is correct, and only then give it the command to act. It helps avoid accidental errors. Sounds useful. And does code CLI have anything similar, some way to safely plan actions without risking it immediately starting to edit code? There is no direct equivalent as a separate mode that you can turn on and off in code CLI. Maher suggests several workarounds, but they are all less convenient. First, you can use the Chat GPT web interface for planning. Since it's available under the same subscription, you can discuss the plan there first, and then go to code CLI and implement it. But this is switching between tools. Not very convenient, right? Second, you can try to directly ask code CLI: "Please create a plan of action, but don't do anything with the code yet." But, as Maher says, there's no guarantee it will obey. It might start generating a plan, and then suddenly switch to writing code, and you'll have to urgently interrupt it. Third, you can ask it to write the plan to a separate file, for example, plan.md, and then work with that file, giving commands to execute individual steps. This is more reliable, but again, requires additional actions. Understood? So, it can be done, but it's not as elegant and safe as a dedicated mode in CL Code. Absolutely correct. Another point in favor of CL's thoughtfulness. Okay. And now we've come to the last major comparison point from Maher's review – agents. What are they in CLD Code and is there anything similar in code CLI? Well, the answer here will be short and disappointing for code CLI. There is no analogue to Cloud Code agents in it at all. And what are these agents in Cloud? Explain in more detail, please. Agents in Cloud Code are essentially a way to run predefined, often quite complex multi-step tasks in a kind of isolated environment, their own memory sandbox. Imagine you have a routine task: run tests, then run a linter, then automatically create a commit with a correct message. Instead of giving Cloud a series of commands in the main dialogue each time, you can create an agent that encapsulates all this logic. And what's the main advantage? Just automation. Not only. The main value, as Maher emphasizes, is context isolation. When you run an agent, it works with its own temporary memory. Its execution, all intermediate steps, command output, everything doesn't clutter your main dialogue with Cloud. You just say: "Agent run tests and commit." It performs the entire sequence of actions, and only the final result or a success/error message returns to the main dialogue. This allows you to keep the main conversation context clean and focused on your main task, without being distracted by routine. Ah, now I understand. So, it's like calling subroutines with their own environment, useful for dialogue cleanliness. And does code CLI have anything similar? No, such a concept is not implemented there. Everything is executed in one common stream. Maher also seems to have briefly mentioned subtasks in Cloud Code, for which there are also no analogues. Yes, he mentioned that there are other advanced features in Cloud, like the ability to break down a large task into subtasks and manage them. But he didn't even go into detail, because comparing them with code CLI is pointless. There are simply no analogues, no parity, so a deep comparison loses its meaning. Okay, it seems we've really gone through all the key differences that Matt Maher highlighted in his review. The picture is becoming quite clear. Let's try to summarize. What is the final verdict of the author? Is it worth the effort? Can CL code CLI really be replaced, especially if you want to save money? Maher's verdict, well, let's say it's quite unambiguous and not in favor of code CLI, if we're talking about convenience. He admits that yes, code CLI is very attractive with this access to the powerful GPT5 model within the GPT Plus subscription. This is a strong trump card. And he says that yes, code CLI can be used for everyday work. Technically, it works, it generates code, it answers questions, but there's a big, but, a huge, but. In his opinion, using code CLI involves constant struggle, the need to compromise, and to put up with a lot of inconveniences. Can you briefly summarize again what exactly you'll have to struggle with? Key pain points. Yes, let's go point by point, the ones he highlights as most critical. One. Readability. Terrible console output. Lack of proper Markdown rendering. This leads to high cognitive load. It's simply hard to read and understand the answers. Two. Configuration. Inconvenient setup through global YAML files. No flexibility for different projects. High entry barrier for customization. Three. Lack of key features. This is a real pain. No session resumption, he considers this the main failure. No custom commands, no convenient planning mode, no agents for context isolation. Four. Overall ergonomics. The tool simply doesn't feel as smooth, responsive, and intuitive as Cloud Code. Interacting with it requires more effort, more steps, more workarounds. So, even if code CLI has the most powerful GPT5 engine under the hood, the machine itself, the interface for interacting with this engine, is so inconvenient that it negates many of the advantages. This is exactly the point Maher makes throughout his review. He never tires of repeating that for productive and, importantly, enjoyable work, ease of interaction, low cognitive load, and attention to detail are critically important. If a person has tried Cloud Code, appreciated its convenience, then switching to code CLI will feel like a serious downgrade, precisely in terms of user experience. He honestly says himself, he would really like to find a free equivalent to Cloud Code, but code CLI hasn't become it, and he's not willing to sacrifice his comfort and efficiency for savings. So, the choice is very clear. Either you pay less, possibly even nothing extra if you have Chat GPT Plus, and get access to GPT5 through code CLI. But you must be prepared to put up with all these inconveniences, lack of features, and use workarounds. Yes, this is the path of compromise and patience. Or you pay more, possibly significantly more for Cloud Code, especially if you need OPUS, but in return, you get a much more polished, thoughtful, convenient, and functional tool that, according to Maher, is simply more pleasant to use every day. Absolutely. This is the classic choice between price and quality of user experience, convenience, ergonomics. And for Maher, as someone who spends a lot of time in the command line, this choice is obvious in favor of Cloud CД. Daily convenience outweighs it. Yes, this detailed breakdown clearly shows that in the world of modern AI tools, it's not just the neural network itself that matters. How this power is packaged, how it's presented to the user, how thoughtful the interface is, even if it's text-based. All these details can be no less, and perhaps even more important for real daily productivity. Absolutely. And you know, this leads us to a more global question worth considering after this comparison. We see a trend, and models are becoming more powerful, more accessible. Open AI is even integrating GPT5 into its existing subscription. It seems that soon, powerful AI will be almost everyone's. Yes, it seems so. And the question is. In such a world, where a powerful model itself ceases to be an exclusive advantage, what will come to the forefront? How much will we, as users, as developers, be willing to sacrifice our comfort, speed, convenience, and simply the pleasure of work for access to the very latest version of AI. Or will the tools that offer not just the smartest AI, but the best, most convenient, most ergonomic, to use Maher's term, the most thoughtful wrapper for it win in this race. And what will ultimately be more important for the mass user. The brains or the convenient body? Hmm, indeed, an interesting question for future reflection. Will the focus shift from pure power to the quality of integration and user experience? Thank you so much for helping to dig so deeply into this comparison and highlight all these nuances. It was very informative. Yes, always welcome. The topic is indeed important. Well, that's all for today. See you next time. M.