Hacker News Reader

Comment by jmmv | Hacker News Reader

> and (partly as a result) it's fairly resource inefficient (often uses 1GB of RAM or more. For a TUI).

That's (one of the reasons) why I'm favoring Codex over Claude Code.

Claude Code is an... Electron app (for a TUI? WTH?) and Codex is Rust. The difference is tangible: the former feels sluggish and does some odd redrawing when the terminal size changes, while the latter definitely feels more snappy to me (leaving aside that GPT's responses also seem more concise). At some point, I had both chewing concurrently on the same machine and same project, and Claude Code was using multiple GBs of RAM and 100% CPU whereas Codex was happy with 80 MB and 6%.

Performance _is_ a feature and I'm afraid the amounts of code AI produces without supervision lead to an amount of bloat we haven't seen before...

View on HN

I think you’re confusing capital c Claude Code, the desktop Electron app, and lowercase c `claude`, the command line tool with an interactive TUI. They’re both TypeScript under the hood, but the latter is React + Ink rendered into the terminal.

The redraw glitches you’re referring to are actually signs of what I consider to be a pretty major feature, a reason to use `claude` instead of `codex` or `opencode`: `claude` doesn’t use the alternate screen, whereas the other two do. Meaning that it uses the standard screen buffer, meaning that your chat history is in the terminal (or multiplexer) scrollback. I much prefer that, and I totally get why they’ve put so much effort into getting it to work well.

In that context handling SIGWINCH has some issues and trickiness. Well worth the tradeoff, imo.

not sure if same reason but window resize feels better in claude than codex.

on my m1, claude is noticeably slower when starting, but it feels ok after that.

I had a nasty slow claude code startup time at one point something like 8s, a clean install sorts it all out. Back up your mcp config and skills and you're good.

That sounds like poor engineering on Anthropic's part. Good software doesn't slow down over time like that.

Codex is using its app server protocol to build a nice client/server separation that I enjoy on top of the predictable Rust performance.

You can run a codex instance on machine A and connect the TUI to it from machine B. The same open source core and protocol is shared between the Codex app, VS Code and Xcode.

OpenCode works this way too

That's the same reason I don't like Opencode, but Codex doesn't use the alternate screen. I remember it did when it was very very new, but now it doesn't.

Ah nice, good to know. I hadn’t used codex in a while. I actually really like opencode and its ui, just wish it didn’t clear the screen on exit. It could at least redraw whatever was last in the chat, that would be better than nothing.

well it still does something weird which breaks scrollback in zellij, it's a known issue, but who knows when it's getting fixed

Anthropic needs to spend some tokens rewriting Claude Code in Rust (yes, really).

The difference in feel between Codex and Claude Code is obvious.

The whole thing is vibed anyway, I'm sure they could get it done in a week or two for their quality standards.

I'd suggest Go ahead of Rust. It's more accessible to contributors.

> It's more accessible to contributors.

What would make go more "accessible to contributors" than Rust?

Go is a language one can learn and become functional in an afternoon. Rust is way more involved.

To vibe coders it doesn't matter, right?

Even then, you still need to read that code and Rust is way less read friendly than Go.

I have the impression that most vibe coders don't read code. I guess they would probably use something accessible to them, just in case.

Successful vibe coders read code.

I'm looking forward to watching Gas Town catch fire, if and when it does.

If you already know some php python javascript and/or c, you can pretty much just wing with Claude code.

Frankly I don't think one even needs to learn it, if you know a bunch of other languages and the codebase is good. I was able to just make a useful change to an open source project by just doing it, without having written any lines of Go before. Granted the MR needed some revisions.

Rust is my favorite, though. There are values beyond ease of contribution. I can't replicate the experience with a Rust project anymore, but I suspect it would have been tougher.

Mature tui packages like bubbletea, lipgloss. Besides TS resemblance to go could push the movement of rewrite, not necessarily easier though.

CC isn't foss in the first place, so the previous comment falls short.

> TS resemblance to go

This is the second time I've seen claims like this in the last 24 hours and I'm afraid I might have lost contact with reality.

My personal opinion is that I like Rust much more than Go, but I can’t deny that Rust is a big, and more dauntingly to newcomers, pretty unopinionated language compared to Go.

There are more syntax features, more and more complex semantics, and while rustc and clippy do a great job of explaining like 90% of errors, the remaining 10% suuuuuck.

There’s also some choices imposed by the build system (like cargo allowing multiple versions of the same dep in a workspace) and by the macro system (axum has some unintuitive extractor ordering needs that you won’t find unless you know to look for them), and those things and the hurdles they present become intuitive after a time but just while getting started? Oof

agents don't really care and they're doing anywhere between 90-100% of the work on CC. if anything, rust is better as it has more built-in verification out of the box.

Claude Code is closed source so this isn’t a concern they should have as Opus is great at Rust.

I think Go might be a better choice but not for that reason at all.

Go could implement something like this with no dependencies outside the standard library. It would make sense to take on a few, but a comparable Rust project would have at least several dozens.

Also, Go can deliver a single binary that works on every Linux distribution right out of the box. In Rust, its possible but you have to static compile with muslc and that is a far less well-trodden path with some significant differences to the glibc that most Rust libraries have been tested with.

Because of all these obvious Go benefits, wonder why they are instead always doing these tools in typescript? Must be some reason?

Most developers find it more pleasant.

Because is all the current generation of devs know unfortunately.

I don't get it either.

Most of, if not every commit of claude code is now written by claude code itself without any human writing code, only promoting.

This is a terrible suggestion.

Rust is accessible to everyone now that Claude Code and Opus can emit it at a high proficiency level.

Rust is designed so the error handling is ergonomic and fits into the flow of the language and the type system. Rust code will be lower defect rate by default.

Plus it's faster and doesn't have a GC.

You can use Rust now even if you don't know the language. It's the best way to start learning Rust.

The learning curve is not as bad as people say. It's really gentle.

Rust is the best AI language. Bar none.

I think go will make it easier for more developers to contribute, bit rust would probably attract higher quality contributions.

If anything, the stricter the compiler the better for vibe coding the language

already done, this is what I use now: https://github.com/leonardcser/agent

Claude Code is a Rust app now.

It still has bun inside with minified JavaScript.

Java (incl. Scala, Closure, Groovy, Jython, etc.) is better suited to running as a server. Let agents write clean readable code and leave performance concerns to the JIT compiler. If you really want you can let agents rewrite components at runtime without losing context.

Erlang would offer similar benefits, because what we're doing with these things is more message passing than processing.

Rust is what I'd want agents writing for edge devices, things I don't want to have to monitor. Granted, our devices are edge devices to Anthropic, but they're more tightly coupled to their services.

There is literally no reason to write it in a JVM language in 2026 when better options exists. Either Go for simplicity and maintaininability or Rust to get the most out of the machine works.

Also, it'll be hard for them to lure good people to work on that thing. Absolutely no one is getting excited to write, vibe, or maintain Java.

I am not thrilled to use java, but it really does what it says on the tin. A customer copied the jar file I sent them to their as400 and it just worked. There is nothing quite like it.

Go binary says hello. No VM overhead. Everything is statically linked.

Hi go binary, unfortunately you don't exist, because there is no cross compiler for that platform. Also please don't crash if you ever do get cross compiled, since the target system doesn't understand your utf8 strings.

I run many instances of Claude Code simultaneously and have not experienced what you are seeing. It sounds like you have a bias of Rust over Typescript.

No, they are describing a typical experience with the two apps. Just open both apps, run a few queries, and take a look at the difference in resource management yourself. It sounds like you have a bias of Claude Code over Codex.

Uh, it sounds like you're having trouble understanding that people in this thread are talking about two wildly different "claude code" applications. Those who are claiming the resources issues don't apply to them are referring to the cli application, ie: `claude` and those are saying things like "Just open both apps..." are surely referring to their GUI versions.

No, I've never used the GUI version. I literally just had to close and reopen the terminal running the Claude Code CLI on my Mac yesterday because it was taking too many resources. It generally happens when I ask Claude to use multiple sub agents. It's an obvious memory leak.

No, I _never_ referred to the GUI versions.

Totally agree. I'm baffled by those who don't clearly see that Codex works better than C.C. in many ways.

Codex being faster is not at all equivalent to working better. Claude Code does what I need from it most of the time.

I said better, not faster. Primarily, it writes better code, works more smoothly, is better at describing what it's doing and what it's done.

Well, yes, but it was in response to a post mostly waxing lyrical about using rust instead of typescript, so forgive me if I got the wrong impression.

Also, that is so far outside my experience that I can’t tell if you are joking.

Codex seems to always do exactly what I ask of it, nothing more, and nothing less, and with as many shortcuts as possible.

Claude Code is not an electron app.

It does use React for rendering the terminal UI.

Did not realize this. That's bizarre!

On the 100% cpu issue, I’m curious to know, what is the processor and was it performing any other cpu intensive work?

I’m not sure why any of this matters? I was looking at top, and the only two non-idle processes were claude and codex.

Could it be, that one source of the memory usage is the built-in language server?

Reply on news.ycombinator.com