Comment by blibble
5 hours ago
> We build Claude with Claude. Our engineers write code with Claude Code every day
well that explains quite a bit
5 hours ago
> We build Claude with Claude. Our engineers write code with Claude Code every day
well that explains quite a bit
CC has >6000 open issues, despite their bot auto-culling them after 60 days of inactivity. It was ~5800 when I looked just a few days ago so they seem to be accelerating towards some kind of bug singularity.
Just anecdotally, each release seems to be buggier than the last.
To me, their claim that they are vibe coding Claude code isn’t the flex they think it is.
I find it harder and harder to trust anthropic for business related use and not just hobby tinkering. Between buggy releases, opaque and often seemingly glitches rate limits and usage limits, and the model quality inconsistency, it’s just not something I’d want to bet a business on.
I think I would be much more frightened if it were working well.
1 reply →
plot twist, it's all claude code instances submitting bug reports on behalf of end users.
It's Claude, all the way down.
Insane to think that a relatively simple CLI tool has so many open issues...
It's not really a simple CLI tool though it's really interactive.
What’s so simple about it?
6 replies →
sips coffee… ahh yes, let me find that classic Dropbox rsync comment
Half of them were probably opened yesterday during the Claude outage.
Nah, it was at like 5500 before.
It explains how important dogfooding is if you want to make an extremely successful product.
It’s extremely successful, not sure what it explains other than your biases
Microsoft's products are also extremely successful
they're also total garbage
but they have the advantage of already being a big company. Anthropic is new and there's no reason for people to use it
2 replies →
Claude is by far the most popular and best assistant currently available for a developer.
4 replies →
Something being successful and something being a high quality product with good engineering are two completely different questions.
Anthropic has perhaps the most embarrassing status page history I have ever seen. They are famous for downtime.
https://status.claude.com/
As opposed to other companies which are smart enough not to report outages.
2 replies →
The best way to use Claude's models seems to be some other inference provider (either OpenRouter or directly)
The competition doesn't currently have all 99's - https://status.openai.com/
And yet people still use them.
The sandboxing in CC is an absolute joke, it's no wonder there's an explosion of sandbox wrappers at the moment. There's going to be a security catastrophe at some point, no doubt about it.
What does it explain, oh snark master supreme?
Also explains why Claude Code is a React app outputting to a Terminal. (Seriously.)
I did some debugging on this today. The results are... sobering.
Memory comparison of AI coding CLIs (single session, idle):
That's a 24x to 50x difference for tools that do the same thing: send text to an API.
vmmap shows Claude Code reserves 32.8 GB virtual memory just for the V8 heap, has 45% malloc fragmentation, and a peak footprint of 746 MB that never gets released, classic leak pattern.
On my 16 GB Mac, a "normal" workload (2 Claude sessions + browser + terminal) pushes me into 9.5 GB swap within hours. My laptop genuinely runs slower with Claude Code than when I'm running local LLMs.
I get that shipping fast matters, but building a CLI with React and a full Node.js runtime is an architectural choice with consequences. Codex proves this can be done in 15 MB. Every Claude Code session costs me 360+ MB, and with MCP servers spawning per session, it multiplies fast.
Jarred Sumner (bun creator, bun was recently acquired by Anthropic) has been working exclusively on bringing down memory leaks and improving performance in CC the last couple weeks. He's been tweeting his progress.
This is just regular tech debt that happens from building something to $1bn in revenue as fast as you possibly can, optimize later.
They're optimizing now. I'm sure they'll have it under control in no time.
CC is an incredible product (so is codex but I use CC more). Yes, lately it's gotten bloated, but the value it provides makes it bearable until they fix it in short time.
1 reply →
I believe they use https://bun.com/ Not Node.js
why do you care about uncommitted virtual memory? that's practically infinite
There’s nothing wrong with that, except it lets ai skeptics feel superior
https://www.youtube.com/watch?v=LvW1HTSLPEk
I thought this was a solid take
1 reply →
I haven't looked at it directly, so I can speak on quality, but it's a pretty weird way to write a terminal app
Oh come on. It's massively wrong. It is always wrong. It's not always wrong enough to be important, but it doesn't stop being wrong
1 reply →
I use AI and I can call AI slop shit if it smells like shit.
Sounds like a web developer defined the solution a year before they knew what the problem was.
React's core is agnostic when it comes to the actual rendering interface. It's just all the fancy algos for diffing and updating the underlying tree. Using it for rendering a TUI is a very reasonable application of the technology.
The terminal UI is not a tree structure that you can diff. It’s a 2D cells of characters, where every manipulation is a stream of texts. Refreshing or diffing that makes no sense.
6 replies →
Same with opencode and gemini, it's disgusting
Codex (by openai ironically) seems to be the fastest/most-responsive, opens instantly and is written in rust but doesn't contain that many features
Claude opens in around 3-4 seconds
Opencode opens in 2 seconds
Gemini-cli is an abomination which opens in around 16 second for me right now, and in 8 seconds on a fresh install
Codex takes 50ms for reference...
--
If their models are so good, why are they not rewriting their own react in cli bs to c++ or rust for 100x performance improvement (not kidding, it really is that much)
Great question, and my guess:
If you build React in C++ and Rust, even if the framework is there, you'll likely need to write your components in C++/Rust. That is a difficult problem. There are actually libraries out there that allow you to build web UI with Rust, although they are for web (+ HTML/CSS) and not specifically CLI stuff.
So someone needs to create such a library that is properly maintained and such. And you'll likely develop slower in Rust compared to JS.
These companies don't see a point in doing that. So they just use whatever already exists.
7 replies →
Why does it matter if Claude Code opens in 3-4 seconds if everything you do with it can take many seconds to minutes? Seems irrelevant to me.
4 replies →
codex cli is missing a bunch of ux features like resizing on terminal size change.
Opencode's core is actually written in zig, only ui orchestration is in solidjs. It's only slightly slower to load than neo-vim on my system.
https://github.com/anomalyco/opentui
50ms to open and then 2hrs to solve a simple problem vs 4s to open and then 5m to solve a problem, eh?
Codex team made the right call to rewrite its TypeScript to Rust early on
Is this a react feature or did they build something to translate react to text for display in the terminal?
React, the framework, is separate from react-dom, the browser rendering library. Most people think of those two as one thing because they're the most popular combo.
But there are many different rendering libraries you can use with React, including Ink, which is designed for building CLI TUIs..
2 replies →
They used Ink: https://github.com/vadimdemedes/ink
I've used it myself. It has some rough edges in terms of rendering performance but it's nice overall.
1 reply →
Not a built-in React feature. The idea been around for quite some time, I came across it initially with https://github.com/vadimdemedes/ink back in 2022 sometime.
i had claude make a snake clone and fix all the flickering in like 20 minutes with the library mentioned lol
It’s really not that crazy.
React itself is a frontend-agnostic library. People primarily use it for writing websites but web support is actually a layer on top of base react and can be swapped out for whatever.
So they’re really just using react as a way to organize their terminal UI into components. For the same reason it’s handy to organize web ui into components.
And some companies use it to write start menus.
Also explains why Claude Code is a React app outputting to a Terminal. (Seriously.)
Who cares, and why?
All of the major providers' CLI harnesses use Ink: https://github.com/vadimdemedes/ink
Ah yes, explains why it takes 3 seconds for a new chat to load after I click new chat in the macOS app.
Can Claude fix the flicker in Claude yet?
[flagged]
Oh, is that what the issue is? I've seen the "flicker" thing as a meme, but as someone who uses Claude Code I've never noticed. I use ghostty mostly, so maybe it's not an issue with ghostty? Or maybe I just haven't noticed it.
3 replies →
Blaming the terminal seems a little backwards. Perhaps the application could take responsibility for being compatible with common terminals?