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.
Since version 2.1.9, performance has degraded significantly after extended use. After 30-40 prompts with substantial responses, memory usage climbs above 25GB, making the tool nearly unusable. I'm updating again to see if it improves.
Unlike what another commenter suggested, this is a complex tool. I'm curious whether the codebase might eventually reach a point where it becomes unfixable; even with human assistance. That would be an interesting development. We'll see.
Doesn’t this just exacerbate the “black box” conundrum if they just keep piling on more and more features without fully comprehending what’s being implemented
I literally hit a claude code bug today, tried to use claude desktop to debug it which didn't help and it offered to open a bug report for me. So yes 100%. Some of the titles also make it pretty clear they are auto submitted. This is my favorite which was around the top when I was creating my bug report 3 hours ago and is now 3 pages back lol.
> Unable to process - no bug report provided. Please share the issue details you'd like me to convert into a GitHub issue title
If I would get a dollar each time a developer (or CTO!) told me "this is (relatively) simple, it will take 2 days/weeks", but then it actually took 2 years+ to fully build and release a product that has more useful features than bugs...
I am not protecting anthropic[0], but how come in this forum every day I still see these "it's simple" takes from experienced people - I have no idea. There are who knows how many terminal emulators out there, with who knows how many different configurations. There are plugins for VSCode and various other editors (so it's not only TUI).
Looking at issue tracker ~1/3 of issues are seemingly feature requests[1].
Do not forget we are dealing with LLMs and it's a tool, which purpose and selling point that it codes on ANY computer in ANY language for ANY system. It's very popular tool run each day by who knows how many people - I could easily see, how such "relatively simple" tool would rack up thousands of issues, because "CC won't do weird thing X, for programming language Y, while I run from my terminal Z". And because it's LLM - theres whole can of non deterministic worms.
Have you created an LLM agent, especially with moderately complex tool usage? If yes and it worked flawlessly - tell your secrets (and get hired by Anthropic/ChatGPT/etc). Probably 80% of my evergrowing code was trying to just deal with unknown unknowns - what if LLM invokes tool wrong? How to guide LLM back on track? How to protect ourselves and keep LLM on track if prompts are getting out of hand or user tries to do something weird? The problems were endless...
Yes the core is "simple", but it's extremely deep can of worms, for such successful tool - I easily could see how there are many issues.
Also super funny, that first issue for me at the moment is how user cannot paste images when it has Korean language input (also issue description is in Korean) and second issue is about input problems in Windows Powershell and CMD, which is obviously total different world compared to POSIX (???) terminal emulators.
[0] I have very adverse feelings for mega ultra wealthy VC moneys...
Although I understand your frustration (and have certainly been at the other side of this as well!), I think its very valuable to always verbalize your intuition of scope of work and be critical if your intuition is in conflict with reality.
Its the best way to find out if there's a mismatch between value and effort, and its the best way to learn and discuss the fundamental nature of complexity.
Similar to your argument, I can name countless of situations where developers absolutely adamantly insisted that something was very hard to do, only for another developer to say "no you can actually do that like this* and fix it in hours instead of weeks.
Yes, making a TUI from scratch is hard, no that should not affect Claude code because they aren't actually making the TUI library (I hope). It should be the case that most complexity is in the model, and the client is just using a text-based interface.
There seems to be a mismatch of what you're describing would be issues (for instance about the quality of the agent) and what people are describing as the actual issues (terminal commands don't work, or input is lost arbitrarily).
That's why verbalizing is important, because you are thinking about other complexities than the people you reply to.
As another example `opencode`[0] has number issues on the same order of magnitude, with similar problems.
> There seems to be a mismatch of what you're describing would be issues (for instance about the quality of the agent) and what people are describing as the actual issues (terminal commands don't work, or input is lost arbitrarily).
I just named couple examples I've seen in issue tracker and `opencode` on quick skim has many similar issues about inputs and rendering issues in terminals too.
> Similar to your argument, I can name countless of situations where developers absolutely adamantly insisted that something was very hard to do, only for another developer to say "no you can actually do that like this* and fix it in hours instead of weeks.
Good example, as I have seen this too, but for this case, let's first see `opencode`/`claude` equivalent written in "two weeks" and that has no issues (or issues are fixed so fast, they don't accumulate into thousands) and supports any user on any platform. People building stuff for only themselves (N=1) and claiming the problem is simple do not count.
---------
Like the guy two days ago claiming that "the most basic feature"[1] in an IDE is a _terminal_. But then we see threads in HN popping up about Ghostty or Kitty or whatever and how those terminals are god-send, everything else is crap. They may be right, but that software took years (and probably tens of man-years) to write.
What I am saying is that just throwing out phrases that something is "simple" or "basic" needs proof, but at the time of writing I don't see examples.
> What I am saying is that just throwing out phrases that something is "simple" or "basic" needs proof, but at the time of writing I don't see examples.
I have given the “never trust the judgment of someone who says it should be a one-line fix” so many times I am basically doxxing myself with this comment.
With extensibility via plugins, MCP (stdio and http), UI to prompt the user for choices and redirection, tools to manage and view context, and on and on.
It is not at all a small app, at least as far as UX surface area. There are, what, 40ish slash commands? Each one is an opportunity for bugs and feature gaps.
I would still call that small, maybe medium. emacs is huge as far as CLI tools go, awk is large because it implements its own language (apparently capable of writing Doom in). `top` probably has a similar number of interaction points, something like `lftp` might have more between local and remote state.
The complex and magic parts are around finding contextual things to include, and I'd be curious how many are that vs "forgot to call clear() in the TUI framework before redirecting to another page".
Also it's highly multithreaded / multiprocess - you can run subagents that can communicate with each other, you can interrupt it while it's in the middle of thinking and it handles it gracefully without forgetting what it was doing
I’m going to buck the trend and say it’s really not that complex. AFAIK they are using Ink, which is React with a TUI renderer.
Cue I could build it in a weekend vibes, I built my own agent TUI using the OpenAI agent SDK and Ink. Of course it’s not as fleshed out as Claude, but it supports git work trees for multi agent, slash commands, human in the loop prompts and etc. If I point it at the Anthropic models it more or less produces results as m good as the real Claude TUI.
I actually “decompiled” the Claude tools and prompts and recreated them. As of 6 months ago Claude was 15 tools, mostly pretty basic (list for, read file, wrote file, bash, etc) with some very clever prompts, especially the task tool it uses to do the quasi planning mode task bullets (even when not in planning mode).
Honestly the idea of bringing this all together with an affordable monthly service and obviously some seriously creative “prompt engineers” is the magic/hard part (and making the model itself, obviously).
Just because Antropic made you think they are doing very complex thing with this tool, doesn't mean it is true. Claude Code is not even comparable to massive software which is probably an order of magnitudes more complex, such as IntelliJ stuff as an example.
Tools like https://github.com/badlogic/pi-mono implement most of the functionality Claude Code has, even adding loads of stuff Claude doesn't have and can actually scroll without flickering inside terminal, all built by a single guy as a side project. I guess we can't ask that much from a 250B USD company.
The rate of Issues opened on a popular repo is at least one order of magnitude beyond the number of Issues whoever is able to deal with them can handle.
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.
Bold of you to assume this is a quick fix. How many software projects have you worked on that went from a buggy poorly optimized mess into a streamlined efficient system? I can think of exactly 0 from personal experience, all the ones I’ve worked on that were performant at the end had that in mind from their inception.
I’ve had good success with Claude building snappy TUIs in Rust with Ratatui.
It’s not obvious to me that there’d be any benefit of using TypeScript and React instead, especially none that makes up for the huge downsides compared to Rust in a terminal environment.
Seems to me the problem is more likely the skills of the engineers, not Claude’s capabilities.
We would all be enlightened if you grounded this blind belief of yours and told us why these design decisions make sense, rather than appealing to authority or power or whatever this is…
It's a popular myth, but not really true anymore with the latest and greatest. I'm currently using both Claude and Codex to work on a Haskell codebase, and it works wonderfully. More so than JS actually, since the type system provides extensive guardrails (you can get types with TS, but it's not sound, and it's very easy to write code that violates type constraints at runtime without even deliberately trying to do so).
There are absolutely things wrong with that, because React was designed to solve problems that don't exist in a TUI.
React fixes issues with the DOM being too slow to fully re-render the entire webpage every time a piece of state changes. That doesn't apply in a TUI, you can re-render TUIs faster than the monitor can refresh. There's no need to selectively re-render parts of the UI, you can just re-render the entire thing every time something changes without even stressing out the CPU.
It brings in a bunch of complexity that doesn't solve any real issues beyond the devs being more familiar with React than a TUI library.
It’s fine in the sense that it works, it’s just a really bad look for a company building a tool that’s supposed to write good code because it balloons the resources consumed up to an absurd level.
300MB of RAM for a CLI app that reads files and makes HTTP calls is crazy. A new emacs GUI instance is like 70MB and that’s for an entire text editor with a GUI.
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)
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.
I am referring to your comment that the reason they use js is because of a lack of tui libraries in lower level languages, yet opencode chose to develop their own in zig and then make binding for solidjs.
Looking at their examples, I imagine people who have written HTML and React before can't possibly use these libraries without losing their sanity.
That's not a criticism of these frameworks -- there are constraints coming from Rust and from the scope of the frameworks. They just can't offer a React like experience.
But I am sure that companies like Anthropic or OpenAI aren't going to build their application using these libraries, even with AI.
That's actually relatively understandable. The React model (not necessarily React itself) of compositional reactive one-way data binding has become dominant in UI development over the last decade because it's easy to work with and does not require you to keep track of the state of a retained UI.
Most modern UI systems are inspired by React or a variant of its model.
Is this accurate? I've been coding UIs since the early 2000s and one-way data binding has always been a thing, especially in the web world. Even in the heyday of jQuery, there were still good (but much less popular) libraries for doing it. The idea behind it isn't very revolutionary and has existed for a long time. React is a paradigm shift because of differential rendering of the DOM which enabled big performance gains for very interactive SPAs, not because of data binding necessarily.
So it doesn’t matter at all except to your sensibilities. Sounds to me that they simply are much better at prioritisation than your average HN user, who’d have taken forever to release it but at least the terminal interface would be snappy…
Aside from startup time, as a tool Claude Code is tremendous. By far the most useful tool I’ve encountered yet. This seems to be very nit picky compared to the total value provided. I think y'all are missing the forrest for the trees.
Most of the value of Claude Code comes from the model, and that's not running on your device.
The Claude Code TUI itself is a front end, and should not be taking 3-4 seconds to load. That kind of loading time is around what VSCode takes on my machine, and VSCode is a full blown editor.
The humans in the company (correctly) realised that a few seconds to open basically the most powerful productivity agent ever made so they can focus on fast iteration of features is a totally acceptable trade off priority wise. Who would think differently???
lol right? I feel like I’m taking crazy pills here. Why do people here want to prioritise the most pointless things? Oh right it’s because they’re bitter and their reaction is mostly emotional…
The "50ms" number was measured by me and you can literally try it on your system as well. it will likely be faster than 50ms
Do you have a proof that gpt-5.2 or 5.3 codex takes 2 hours for the same problem that sonnet/opus4.5/4.6 take 5 minutes to solve? (I use both anthropic and openai models daily almost equally, and i'm not relating to what you said)
Sure codex-cli lacks way-too many features compared to claude-code (I use opencode), but your statement implies that openai models are absolute garbage (2h vs 5m to solve a problem)
I am really flabbergasted. How are they thinking using React for a TUI is a flex? Having 5 sessions open - and all idea - is taking up 98% of CPU. Is this another case of - "When all you is hammer, everything looks like nails"?
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.
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..
Anyone that knows a bit about terminals would already know that using React is not a good solution for TUI. Terminal rendering is done as a stream of characters which includes both the text and how it displays, which can also alter previously rendered texts. Diffing that is nonsense.
You’re not diffing that, though. The app keeps a virtual representation of the UI state in a tree structure that it diffs on, then serializes that into a formatted string to draw to the out put stream. It’s not about limiting the amount of characters redrawn (that would indeed be nonsense), but handling separate output regions effectively.
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.
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.
When doing advanced terminal UI, you might at some point have to layout content inside the terminal. At some point, you might need to update the content of those boxes because the state of the underlying app has changed. At that point, refreshing and diffing can make sense. For some, the way React organizes logic to render and update an UI is nice and can be used in other contexts.
How big is the UI state that it makes sense to bring in React and the related accidental complexity? I’m ready to bet that no TUI have that big of a state.
IMO diffing might have made sense to do here, but that's not what they chose to do.
What's apparently happening is that React tells Ink to update (re-render) the UI "scene graph", and Ink then generates a new full-screen image of how the terminal should look, then passes this screen image to another library, log-update, to draw to the terminal. log-update draws these screen images by a flicker-inducing clear-then-redraw, which it has now fixed by using escape codes to have the terminal buffer and combine these clear-then-redraw commands, thereby hiding the clear.
An alternative solution, rather than using the flicker-inducing clear-then-redraw in the first place, would have been just to do terminal screen image diffs and draw the changes (which is something I did back in the day for fun, sending full-screen ASCII digital clock diffs over a slow 9600baud serial link to a real terminal).
Any diff would require to have a Before and an After. Whatever was done for the After can be done to directly render the changes. No need for the additional compute of a diff.
Sure, you could just draw the full new screen image (albeit a bit inefficient if only one character changed), and no need for the flicker-inducing clear before draw either.
I'm not sure what the history of log-output has been or why it does the clear-before-draw. Another simple alternative to pre-clear would have been just to clear to end of line (ESC[0K) after each partial line drawn.
Only in the same way that the pixels displayed in a browser are not a tree structure that you can diff - the diffing happens at a higher level of abstraction than what's rendered.
Diffing and only updating the parts of the TUI which have changed does make sense if you consider the alternative is to rewrite the entire screen every "frame". There are other ways to abstract this, e.g. a library like tqmd for python may well have a significantly more simple abstraction than a tree for storing what it's going to update next for the progress bar widget than claude, but it also provides a much more simple interface.
To me it seems more fair game to attack it for being written in JS than for using a particular "rendering" technique to minimise updates sent to the terminal.
Most UI library store states in tree of components. And if you’re creating a custom widget, they will give you a 2D context for the drawing operations. Using react makes sense in those cases because what you’re diffing is state, then the UI library will render as usual, which will usually be done via compositing.
The terminal does not have a render phase (or an update state phase). You either refresh the whole screen (flickering) or control where to update manually (custom engine, may flicker locally). But any updates are sequential (moving the cursor and then sending what to be displayed), not at once like 2D pixel rendering does.
So most TUI only updates when there’s an event to do so or at a frequency much lower than 60fps. This is why top and htop have a setting for that. And why other TUI software propose a keybind to refresh and reset their rendering engines.
The "UI" is indeed represented in memory in tree-like structure for which positioning is calculated according to a flexbox-like layout algo. React then handles the diffing of this structure, and the terminal UI is updated according to only what has changed by manually overwriting sections of the buffer. The CLI library is called Ink and I forget the name of the flexbox layout algo implementation, but you can read about the internals if you look at the Ink repo.
The tool is absolutely fantastic coding assistant. That's why I use it.
The amount of non-critical bugs all over the place is at least a magnitude larger than of any software I was using daily ever.
Plenty of built in /commands don't work.
Sometimes it accepts keystrokes with 1 second delays.
It often scrolls hundreds of lines in console after each key stroke
Every now and then it crashes completely and is unrecoverable (I once have up and installed a fresh wls)
When you ask it question in plan mode it is somewhat of an art to find the answer because after answering the question it will dump the whole current plan (free screens of text)
And just in general the technical feeling of the TUI is that of a vibe coded project that got too big to control.
Well there you have it, proof you’re not being reasonable. Microsoft’s products annoy HN users but they are absolutely not total garbage. They’re highly functional and valuable and if they weren’t they truely wouldn’t be used, they’re just flawed.
I have. I use it mostly for gaming, and prefer MacOS after 15+ years on Linux. I have not noticed any delays opening file explorer. It opens instantaneously for me. In fact, I feel like Windows 11 on my main gaming system to be very snappy.
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.
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.
Happens with Konsole sometimes on an 8th gen i7. This cpu can run many instances of intellij just fine, but somehow this TUI manages to be slow sometimes. Codex is fine, so no good argument exists really.
underpowered machines? the only reason it needs "powerful machines" is because it's a shitty react app in the terminal. I've never seen anything else flicker like that. it's not like it's running the llm on the "underpowered machine".
kilocode runs fine. opencode runs fine. qwen code runs fine. what exactly is Claude code doing that requires so much power? I'm sorry but it sounds like you're speaking from the wrong end.
well that explains quite a bit